Изменение пароля SSSD, не работающее с бэкендом LDAP

Environment info:

AD on win 2k8r2  
Ubuntu 12.04.5 LTS  
SSSD v1.8.6  

everything is in the same vlan

У меня есть LDAP / решение SSSD, используемое на наших серверах Ubuntu. Подлинный процесс работает правильно - т.е. пользователи могут войти в систему прекрасные и сделать то, в чем они нуждаются.

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

user@host:~$ passwd
Current Password: 
New Password: 
Reenter new Password: 
Password change failed. 
passwd: Authentication token manipulation error
passwd: password unchanged

Новый пароль отвечает всем AD требованиям.

Я вижу это в /var/log/auth.log:

Aug 18 15:22:12 hostname passwd[7544]: pam_unix(passwd:chauthtok): user "user" does not exist in /etc/passwd
Aug 18 15:22:16 hostname passwd[7544]: pam_unix(passwd:chauthtok): user "user" does not exist in /etc/passwd
Aug 18 15:22:21 hostname passwd[7544]: pam_sss(passwd:chauthtok): system info: [Generic error (see e-text)]
Aug 18 15:22:21 hostname passwd[7544]: pam_sss(passwd:chauthtok): User info message: Password change failed. 
Aug 18 15:22:21 hostname passwd[7544]: pam_sss(passwd:chauthtok): Password change failed for user user: 20 (Authentication token manipulation error)

Я попытался использовать несколько различных настроек в sssd.conf для ldap_default_bind_dn, все из которых разрешают пользователей автору, но не изменяют их пароль. Никакая идея, что останавливает его - не чувствует, что это должно просто быть изменение конфигурации, и, но не уверено все будет хорошо, что я должен изменить.

файлы конфигурации:

/etc/sssd/sssd.conf

[sssd]  
config_file_version = 2  
domains = LDAP  
services = nss, pam  
debug_level = 10  

[nss] 

[pam]

[domain/LDAP]
enumerate = false
id_provider = ldap
#ldap_access_filter = memberOf=cn=XXXX,cn=XXXX,dc=XXXX,dc=XXXX
ldap_uri = ldap://xxx.xxx.xxx.xxx # AD server ip
ldap_search_base = ou=XXXX,dc=XXXX,dc=XXXX
ldap_tls_reqcert = demand
ldap_id_use_start_tls = false
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt
ldap_schema = rfc2307bis
ldap_user_object_class = person
ldap_group_object_class = group
ldap_default_bind_dn = cn=XXXX,cn=XXXX,dc=XXXX,dc=XXXX
ldap_default_authtok_type = password
ldap_default_authtok = *********
ldap_user_gecos = displayName
ldap_user_home_directory = unixHomeDirectory
min_id = 10000
ldap_user_principal = userPrincipalName
ldap_force_upper_case_realm = True

auth_provider = krb5
chpass_provider = krb5
krb5_server = xxx.xxx.xxx.xxx # AD server ip
krb5_kpasswd = xxx.xxx.xxx.xxx # AD Server ip
krb5_realm = XXXX.XXXX #Upper caseof the domain
krb5_changepw_principle = kadmin/changepw
krb5_auth_timeout = 15
krb5_store_password_if_offline = true
krb5_renewable_lifetime = 14d
krb5_renew_interval = 60
debug_level = 9

/etc/krb5.conf

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = XXXX.XXXX # capitalised domain
realm = XXXX.XXXX # capitalised domain
dns_lookup_realm = true
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
default_etypes = arcfour-hmac-md5
default_etypes_des = des-cbc-crc
default_tkt_enctypes = arcfour-hmac-md5
default_tgs_enctypes = arcfour-hmac-md5

[realms]
XXXX.XXXX= {
kdc = xxx.xxx.xxx.xxx:88 # AD Server IP
kpasswd_server = xxx.xxx.xxx.xxx:464 #AD server IP
default_domain = XXXX.XXXX # Capitalised domain
}

[domain_realm]
.xxxx.xxxx = XXXX.XXXX # lower = CAP domain
xxxx.xxxx = XXXX.XXXX

/etc/pam.d/common-password:

password    [success=2 default=ignore]  pam_unix.so obscure sha512
password    sufficient                  pam_sss.so
password    requisite           pam_deny.so
password    required            pam_permit.so
1
задан 18 August 2014 в 09:48

3 ответа

После большого исследования и тестирования. Вот ответ на разрешение пользователям использовать passwd функция для изменения их пароля, когда они используют SSSD с ldap бэкендом. Если они могут действительно аутентифицировать с их паролем через ssh клиенту SSSD, то проблема изменения их пароля, который производит следующее: "passwd: ошибка управления Аутентификационным маркером" прибывает из ACL LDAP. Потребность сам доступ для записи к Атрибуту userPassword

Добавляет следующее к Вашему ldap файлу конфигурации при использовании olc. Редактирование olcDatabase={2}bdb.ldif olcAccess:

{0}to attrs=userPassword,shadowLastChange by self write by anonymous 
            auth by dn="cn=Manager,dc=domain.com" write by * none

Удостоверяются, что Вы добавляете еще немного для разрешения чтений и записей для любых других атрибутов, которые Вы хотите.

olcAccess: {2}to * by * read by users read by anonymous auth

просто необходимо сделать это однажды для всех пользователей. {0}to attrs=userPassword... так же, как я упомянул выше, применяется как ACL к ldap серверу и применяется глобально. Если Вы редактируете olcDatabase={2}bdb.ldif olcAccess вручную, необходимо изменить CRC, но это легко, поскольку существует много readmes на этом.

отправленное изменение другого пользователя связывают учетные данные на клиентах /etc/sssd/sssd.conf как это:

ldap_default_bind_dn = cn=Manager,dc=mydomain,dc=fqdn.com ldap_default_authtok_type = password ldap_default_auttok = secret

Изменение в /etc/sssd/sssd.conf связывает учетные данные, не работал на меня, но пользователей разрешения, чтобы самозаписать, что их атрибут userPassword сделал... Вы не можете всегда хотеть это, но для использования функции passwd на клиентах Linux с SSSD и бэкендом LDAP, Вам нужен он.

1
ответ дан 11 November 2019 в 12:37

фиксированный.

Это относилось к связыванию с ldap в sssd.conf. Как временная работа вокруг я использовал пользователя/передачу администратора там, и я могу изменить пароль с помощью passwd. Я ничего не знаю о AD, таким образом, я буду играть вокруг с ним больше, но по крайней мере я знаю, что проблема находится в полномочиях связывать пользователя.

0
ответ дан 11 November 2019 в 12:37

Добавьте следующее к своему/etc/sssd/sssd.conf:

[domain/LDAP]
...
# changing passwords not working otherwise
# see https://fedorahosted.org/sssd/ticket/2204
krb5_use_enterprise_principal = false
0
ответ дан 11 November 2019 в 12:37

Другие вопросы по тегам:

Похожие вопросы: