Ошибка ldap при смене пароля

I currently try to change passwords in our Active Directory Envoirenment via LDAP on Linux since the users in question do not have access to a windows-machine and we want to keep it that way.
In order to change the password I am currently stuck figuring out how to use ldapmodify to do so. After a lot of reading on different sites/forums/newsgroups I am much more confused than before

However:
I try the following command to do so:

ldapmodify -f ldif.example -H ldaps://lab01-dc01.example.com -D 'CN=test,CN=users,DC=lab01,DC=example,DC=com' -x -W

The contents of the ldif.example:

dn: CN=test,CN=Users,DC=lab01,DC=example,DC=com
changetype: modify
delete: unicodePwd
unicodePwd:: V3VQdXV1STEyLg==
-
add: unicodePwd
unicodePwd:: QmxhVVVraTEyLg==
-

(Don’t worry — those passwords are not used anywhere and it is not a production envoirenment)

Now — every time I execute the command I get the following error:

modifying entry CN=test,CN=Users,DC=lab01,DC=example,DC=com"
ldapmodify: Constraint violation (19)
 additional info: 0000216C: AtrErr: DSID-03190EB0, #1:
 0: 0000216C: DSID-03190EB0, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 9005a (unicodePwd)

Now, after what I read the reason for this error is either that the password is badly formatted or that the password policy doesn’t allow the password I used. I checked the policy — multiple times now — and the new password definetly complies to the policy by all the criteria. If I set the password using a Windows-machine it also works well (of course I changed the «oldpassword» and «newpassword» afterwards since I am not allowed by the policy to change to an earlier password). The password I enter after passing the «-W» option to ldapmodify is also definetly right, otherwise the error spit out by ldapmodify is that I used invalid credentials instead of a constraint violation.
So — the sole reason I can think of is indeed a bad formatted password — but I can’t figure out where the bad formatting should come from since I use the normal base64 algorythm to encode the password.

Has anyone an idea what is going on?
Can anyone push me in the right direction?

Help is very appreciated and I thank you in advance.

Edit:
Something which bugs me:
When I run the base encoded strings through base64 it keeps telling me «Invalid Input». Now — I went ahead and just re-coded the passwords with the use of base64 on the linux machine — but when I run the generated string through the decode function again, base64 keeps telling me «Invalid Input»… The strings however slightly changed between the windows-base64 encoded string and the linux encoded string. But base64 just says «Invalid input» no matter what I put in there.

Edit2:
Nevermind — reading the purpose of the function I gather that it throws this error because of the dots and the exclamation mark in the password.

Ситуация:

Есть Samba3 PDC, в него входят пользователи. Когда время пароля истекает -> они меняют его средствами win.

Задача:

Сделать синхронизацию паролей samba3<->posix account

Для чего был поставлен скрипт ldapsync.pl. Теперь, когда клиент

меняет свой пароль, у него ошибка, но пароль _успешно_ меняется!

Вопрос:

как сделать так чтобы клиент не получал ошибки на своей стороне.

Вот лог файл:

[2004/08/04 11:46:52, 3] smbd/chgpasswd.c:chat_with_program(424)

chat_with_program: Dochild for user g-marchenko (uid=0,gid=0) (as_root = Yes)

[2004/08/04 11:46:52, 10] smbd/chgpasswd.c :Dochild(217)

Invoking ‘/usr/local/bin/ldapsync.pl -o g-marchenko’ as password change program.

[2004/08/04 11:46:52, 10] lib/util_sock.c:read_socket_with_timeout(263)

read_socket_with_timeout: timeout read. select timed out.

[2004/08/04 11:46:52, 100] smbd/chgpasswd.c:expect(274)

expect: expected [*New*Password*] received [New password for user g-marchenko: ] match yes

[2004/08/04 11:46:52, 10] smbd/chgpasswd.c:expect(285)

expect: returning True

[2004/08/04 11:46:52, 100] smbd/chgpasswd.c:expect(237)

expect: sending [test2

]

[2004/08/04 11:46:52, 10] lib/util_sock.c:read_socket_with_timeout(263)

read_socket_with_timeout: timeout read. select timed out.

[2004/08/04 11:46:52, 100] smbd/chgpasswd.c:expect(274)

expect: expected [*Retype*new*password*] received [

Retype new password for user g-marchenko: ] match yes

[2004/08/04 11:46:52, 10] smbd/chgpasswd.c:expect(285)

expect: returning True

[2004/08/04 11:46:52, 100] smbd/chgpasswd.c:expect(237)

expect: sending [test2

]

[2004/08/04 11:46:52, 0] lib/util_sock.c:read_socket_with_timeout(279)

read_socket_with_timeout: timeout read. read error = Input/output error.

[2004/08/04 11:46:52, 100] smbd/chgpasswd.c:expect(274)

expect: expected [*modifying*] received [

modifying entry «uid=g-marchenko,ou=People,o=office,dc=test,dc=ru»

] match yes

[2004/08/04 11:46:52, 10] smbd/chgpasswd.c:expect(285)

expect: returning True

[2004/08/04 11:46:52, 3] smbd/chgpasswd.c:chat_with_program(440)

chat_with_program: Password change successful for user g-marchenko

…

[2004/08/04 11:46:52, 2] passdb/pdb_ldap.c:init_ldap_from_sam(769)

init_ldap_from_sam: Setting entry for user: g-marchenko

[2004/08/04 11:46:52, 11] passdb/pdb_get_set.c :pdb_get_init_flags(189)

…

[2004/08/04 11:46:52, 5] lib/smbldap.c:smbldap_modify(976)

smbldap_modify: dn => [uid=g-marchenko,ou=People,o=office,dc=test,dc=ru]

[2004/08/04 11:46:52, 11] lib/smbldap.c:smbldap_open(828)

smbldap_open: already connected to the LDAP server

[2004/08/04 11:46:52, 1] passdb/pdb_ldap.c:ldapsam_modify_entry(1217)

ldapsam_modify_entry: Failed to modify user dn= uid=g-marchenko,ou=People,o=office,dc=test,dc=ru with: No such attribute

modify/delete: sambaLMPassword: no such value

[2004/08/04 11:46:52, 0] passdb/pdb_ldap.c:ldapsam_update_sam_account(1417)

ldapsam_update_sam_account: failed to modify user with uid = g-marchenko, error: modify/delete: sambaLMPassword: no such value (Success)

[2004/08/04 11:46:52, 3] smbd/sec_ctx.c :pop_sec_ctx(386)

pop_sec_ctx (65534, 65534) — sec_ctx_stack_ndx = 1

[2004/08/04 11:46:52, 5] rpc_parse/parse_samr.c:init_samr_r_chgpasswd_user(7120)

init_r_chgpasswd_user

[2004/08/04 11:46:52, 5] rpc_server/srv_samr_nt.c:_samr_chgpasswd_user(1469)

_samr_chgpasswd_user: 1469

[2004/08/04 11:46:52, 5] rpc_parse/parse_prs.c :prs_debug(82)

000000 samr_io_r_chgpasswd_user

[2004/08/04 11:46:52, 5] rpc_parse/parse_prs.c :prs_ntstatus(665)

0000 status: NT_STATUS_ACCESS_DENIED

Исходя из него мне показалось что samba3 пытается изменить пароль пользователя 2 раза, один раз — с помощью скрипта ldapsync.pl, а второй раз встроенными средствами samba3.

В поиске и мейл листе samba я не нашел подобной ошибки.

Если убрать настройку внешнего скрипта — то все нормально, пароли успешно меняются клиентами, только синхронизации их с паролями linux не происходит.

#ldap #opendj

Вопрос:

Я реализую функцию LDAP принудительной смены пароля при первом входе в систему, когда добавляется пользователь или когда администратор меняет пароль пользователя. Я установил ds-cfg-принудительное изменение при добавлении и ds-cfg-принудительное изменение при сбросе в значение true и в соответствии со спецификацией, которая определяет:

1. Изменение пароля После сброса Эта политика заставляет пользователя выбирать новый пароль при первой привязке или после сброса пароля. После успешной операции привязки с аутентификацией сервер должен проверить, включена ли политика изменения пароля после сброса, и это первый вход в систему. Если это так, сервер должен отправить bindResponse с кодом результата: LDAP_SUCCESS и должен включить элемент управления с истекшим сроком действия пароля в поле элементы управления сообщения bindResponse:

   Тип управления: 2.16.840.1.113730.3.4.4,

   Значение управления: строка октета: «0»,

   критичность: ложная

Действительно, когда я вызываю Client.bind, я получаю возвращаемое значение LDAP_SUCCESS и поле элементов управления, как определено в спецификации.

но —

когда я вызываю Client.bind, когда пользователь находится в пределах интервала предупреждения об истечении срока действия пароля, я получаю поле управления только с типом управления Срок действия пароля (2.16.840.1.113730.3.4.5). Я бы ожидал получить оба элемента ControlType (элементы управления-это массив), но 2.16.840.1.113730.3.4.4 там нет.

Это является серьезной проблемой, потому что, если тип управления 2.16.840.1.113730.3.4.4 отсутствует, пользователь сможет войти в систему, хотя он должен был этого не делать.

Что я здесь упускаю?

Спасибо.

Комментарии:

1. Какой сервер LDAP вы используете? Открывается? ОпенДЖ?

2. Сервер LDAP, который я использую, — это OpenDJ

3. Я думаю, что это правильное поведение: когда пользователь находится в пределах интервала предупреждения об истечении срока действия пароля, его пароль считается установленным, и он еще не истек, поэтому нет LDAP_INVALID_CREDENTIALS, и контроль истечения срока действия пароля 2.16.840.1.113730.3.4.5 указывает время до истечения срока действия пароля. 2.16.840.1.113730.3.4.4 возвращается, когда пользователю должно быть предложено немедленно изменить пароль (это означает, что он уже истек или должен быть установлен пользователем после сброса/1-й привязки).

4. Спасибо, Эриклаво. Я понимаю ваш ответ, но это только усиливает вопрос. Если 2.16.840.1.113730.3.4.5 означает предупреждение о скором изменении пароля, а 2.16.840.1.113730.3.4.4 означает немедленное изменение пароля, то я ожидаю, что в случае, если оба они действительны, — 2.16.840.1.113730.3.4.4 будет возвращено, так как это более сильное уведомление. Но вместо этого сервер возвращает уведомление с предупреждением. 2.16.840.1.113730.3.4.5 выводит предупреждение пользователю, в то время как 2.16.840.1.113730.3.4.4 блокирует вход пользователя, пока он не изменит свой пароль. Не так ли?

Ответ №1:

Элементы управления Netscape очень старые и появились еще до разработки политики паролей OpenDJ. Они существуют только для того, чтобы обеспечить некоторую совместимость с очень старыми приложениями. Новые приложения должны отправить Управление запросом политики паролей (1.3.6.1.4.1.42.2.27.8.5.1) и получат соответствующий ответ управления PwdPolicy.

Долго бился над проблемой корректного обновления паролей для авторизуемых через LDAP пользователей.

Настройки умолчанию позволяли корректно логинится и изменять себе пароль без проблем, но в случае истекания срока действия пароля начинались странности —
все необходимые атрибуты проверялись успешно и при логине система корректно рапортовала о необходимости обновления пароля:

You are required to change you LDAP password immediately.

,но после столь обнадеживающей фразы процесс смены пароля заканчивался печально

Authentication failed.

Поиск ничего путного не выдавал по данной проблеме, пришлось дебажить и исправлять самостоятельно.

Ищем проблему

Сначала подозрение пало на некорректно настроенные права доступа в OpenLDAP. Включил полный доступ на запись всем, ситуация не изменилась. При таком поведении, подозрения с LDAP’а были сняты, оставался PAM.

PAM

Просмотрев бегло исходники модуля pam_ldap, и не обнаружив ничего подозрительного начал экспериментировать с общими настройками в /etc/pam.d/common-*
В качестве средства дебага, я воспользовался модулем pam_echo для вывода трейсовых сообщений.

В результате проблема локализовалась в account части, ответственной за проверку «протухания» пароля. После того как она отрабатывала для ldap аккаунтов, передача управления в password не происходило.

Решение

Исходный конфиг для common-account при работе unix и ldap аккаунтов в Ubuntu Server выглядит так:

account [success=2 new_authtok_reqd=done default=ignore] pam_unix.so
account [success=1 default=die] pam_ldap.so
account requisite pam_deny.so
account required pam_permit.so

В результате экспериментов оказалось, что некорректо были настроены секция контрольных флагов (contol-flags) для модуля pam_ldap. Для правильной обработки истекшего пароля необходимо, как и в секции pam_unix, добавить указание для обработки new_authtok_reqd

account [success=1 new_authtok_reqd=done default=die] pam_ldap.so

При внесении данной правки, при попытке залогиниться пользователем с истекшим паролем, форма логина будет радовать нас предложением ввести новый пароль.
Стоит отметить что использование стандартной директивы sufficient вместо детального указания отдельных флагов тоже исправляет проблему с передачей управления дальше.

Проблема и её решение работают и в других дистрибутивах. Так в ALT Легкий и в ПСПО настройки по умолчанию также не позволяют менять пароль при его «протухании» и исправляются аналогичным образом.