web-dev-qa-db-fra.com

Le changement de mot de passe SSSD ne fonctionne pas avec le backend LDAP

Environment info:

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

everything is in the same vlan

J'ai une solution LDAP/SSSD utilisée sur nos serveurs Ubuntu. Le processus d’authentification fonctionne correctement - c’est-à-dire que les utilisateurs peuvent se connecter et faire ce qu’ils souhaitent.

quand quelqu'un essaie de changer son mot de passe, il voit ceci:

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

Le nouveau mot de passe répond à toutes les exigences d'AD.

Je vois ceci dans /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)

J'ai essayé d'utiliser quelques paramètres différents dans sssd.conf pour ldap_default_bind_dn, qui permettent tous aux utilisateurs d'authentifier mais pas de changer leur mot de passe. Aucune idée de ce qui l'arrête - sent que cela devrait être juste un changement de configuration et tout ira bien, mais je ne suis pas sûr de ce que j'ai besoin de changer.

fichiers de configuration:

/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
authenticationldapkerberos
1
drinxy

Après de nombreuses recherches et tests. Voici la réponse pour permettre aux utilisateurs d’utiliser la fonction passwd pour modifier leur mot de passe lorsqu’ils utilisent SSSD avec ldap backend. S'ils peuvent effectivement s'authentifier avec leur mot de passe via ssh auprès du client SSSD, le problème de modification de leur mot de passe, qui génère le message suivant: "passwd: erreur de manipulation du jeton d'authentification" provient de la liste de contrôle d'accès LDAP. Besoin d'un accès en écriture à l'attribut userPassword

Ajoutez ce qui suit à votre fichier de configuration LDAP lorsque vous utilisez OLC. Éditer 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

Assurez-vous d'en ajouter d'autres pour autoriser les lectures et les écritures pour tout autre attribut souhaité.

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

Vous devez juste le faire une fois pour tous les utilisateurs. {0}to attrs=userPassword... comme je l'ai indiqué ci-dessus est appliqué en tant qu'ACL au serveur LDAP et appliqué globalement. Si vous éditez le olcDatabase={2}bdb.ldif olcAccess manuellement, vous devez changer le CRC, mais c'est facile car il y a beaucoup de readmes à ce sujet.

L'autre utilisateur a posté des informations d'identification de liaison modifiées sur les clients /etc/sssd/sssd.conf comme ceci:

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

Modifier les informations de connexion dans /etc/sssd/sssd.conf ne fonctionnait pas pour moi, mais autoriser les utilisateurs à auto-écrire leur attribut userPassword suffisait ... Vous ne le souhaitiez peut-être pas toujours, mais pour utiliser la fonction passwd sur les clients Linux avec les systèmes SSSD et LDAP besoin de ça.

1
user402350

Ajoutez ce qui suit à votre /etc/sssd/sssd.conf:

[domain/LDAP]
...
# changing passwords not working otherwise
# see https://fedorahosted.org/sssd/ticket/2204
krb5_use_enterprise_principal = false
0
Ilya Semenov

fixé.

Il s'agissait de la liaison à ldap dans sssd.conf. En tant que travail temporaire, j’ai utilisé l’utilisateur administrateur/pass-it et je peux changer le mot de passe avec passwd. Je ne connais rien à AD, je vais donc en jouer plus, mais au moins, je sais que le problème réside dans les autorisations de l'utilisateur lié.

0
drinxy