1
Environment info:

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

everything is in the same vlan

I have an LDAP / SSSD solution in use on our Ubuntu servers. The auth process works correctly - ie users can log in fine and do whatever they need.

when anyone tries to change their password they see this:

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

The new password meets all of the AD requirements.

I see this in /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)

I have tried using a few different settings in sssd.conf for ldap_default_bind_dn, all of which allow users to auth, but not change their password. No idea what's stopping it - feels like it should just be a config change and it will all be fine, but not sure what i need to change.

config files:

/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
2
  • I'm not sure if you are supposed to change your password on the client in that way. I would expect that you have to do this on the AD directly. There is also ldappasswd, did you try that?
    – noleti
    Aug 18, 2014 at 6:59
  • yeah it should work in theory, that's how we had it working at my old job. I was not part of that project though, so not sure of exactly how it was setup there.
    – floodpants
    Aug 19, 2014 at 3:09

3 Answers 3

1

After much research and testing. Here is the answer to allowing users to use passwd function to change their password when they are using SSSD with ldap backend. If they can indeed authenticate with their password via ssh to the SSSD client, then the problem of changing their password which produces the following: "passwd: Authentication token manipulation error" comes from the LDAP ACL. Need self write access to userPassword Attribute

Add the following to your ldap config file when using olc. Edit 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

Make sure you add some more to allow reads and writes for any other attributes you want.

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

You just have to do it once for all users. {0}to attrs=userPassword... just as I listed above is applied as an ACL to the ldap server and applied globally. If you edit the olcDatabase={2}bdb.ldif olcAccess manually you have to change the CRC, but thats easy as there are many readmes on that.

The other user posted changing bind credentials on the clients /etc/sssd/sssd.conf like this:

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

Modifying in /etc/sssd/sssd.conf bind credentials didn't work for me, but allowing users to selfwrite their userPassword attribute did... You may not always want this, but for using the passwd function on linux clients with SSSD and LDAP backend you need it.

1
  • so you have to make that change for every user you want to be able to change their password, or just once to cover all? Also, ldap_default_bind_dn is what I changed.
    – floodpants
    Apr 29, 2015 at 5:45
0

fixed.

It was to do with the bind to ldap in sssd.conf. As a temp work around I have used the administrator user/pass in there and I can change password using passwd. I know nothing about AD, so I'll play around with it more, but at least i know the issue lies in the permissions of the bind user.

0

Add the following to your /etc/sssd/sssd.conf:

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .