Lukas
You're the best.
So I removed the existing account used for binds and added it back with this entry:
pwdPolicySubentry: cn=CustomBindAccountPolicy,ou=Policies,DN
The custom policy:
dn: cn=CustomBindAccountPolicy,ou=Policies,DN objectClass: pwdPolicy objectClass: person objectClass: top cn: passwordDefault sn: passwordDefault pwdAttribute: userPassword pwdMinAge: 0 pwdMaxAge: 0 pwdLockout: FALSE
Moreover, I am now using the following settings in /etc/sysconfig/ldap:
SLAPD_LDAP=yes <-- previously disabled so no Start TLS via TCP 389 was allowed. SLAPD_LDAPI=yes SLAPD_LDAPS=yes
sssd.conf:
ldap_uri = ldap://provider ldap_backup_uri = ldap://consumer ldap_default_bind_dn = uid=woohoo,ou=topsecret,DN ldap_default_authtok_type = password ldap_default_authtok = toolongtocrack ldap_search_base = DN ldap_tls_reqcert = demand ldap_tls_cacert = /etc/pki/tls/certs/sha2bundle.cer
client sssd log:
(Tue Dec 13 12:20:39 2016) [sssd[be[LDAP]]] [simple_bind_send] (0x0100): Executing simple bind as: uid=woohoo,ou=topsecret,DN (Tue Dec 13 12:20:39 2016) [sssd[be[LDAP]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'provider' as 'working' (Tue Dec 13 12:20:39 2016) [sssd[be[LDAP]]] [set_server_common_status] (0x0100): Marking server 'provider' as 'working'
provider /var/log/ldap:
Dec 13 12:25:58 suntzu slapd[2614]: => bdb_entry_get: found entry: "uid=woohoo,ou=topsecret,DN" Dec 13 12:25:58 suntzu slapd[2614]: => bdb_entry_get: found entry: ""cn=custombindaccountpolicy,ou=policies,DN" Dec 13 12:25:58 suntzu slapd[2614]: => access_allowed: auth access to "uid=woohoo,ou=topsecret,DN" "userPassword" requested Dec 13 12:25:58 suntzu slapd[2614]: => acl_mask: access to entry ""uid=woohoo,ou=topsecret,DN, attr "userPassword" requested Dec 13 12:25:58 suntzu slapd[2614]: conn=1004 op=1 BIND dn="uid=woohoo,ou=topsecret,DN" mech=SIMPLE ssf=0
I then did several ldapsearches with the account used for binding. The account's not locked out even though I supplied the wrong password each time.
I have halted both LDAP servers and it seems sssd cache with both autofs and my user / group attributes are working! However, I would like to be notified interactively that the LDAP servers are down. Can I have PAM let the user know upon login that the SSSD cache happens to be "active?"
Thanks,
Douglas Duckworth, MSc, LFCS HPC System Administrator Scientific Computing Unit Physiology and Biophysics Weill Cornell Medicine E: doug@med.cornell.edu O: 212-746-6305 F: 212-746-8690
On Mon, Dec 12, 2016 at 4:18 PM, Lukas Slebodnik lslebodn@redhat.com wrote:
On (12/12/16 15:38), Douglas Duckworth wrote:
Hello
I am nearly finished building new LDAP cluster using SSSD for clients.
I have a password policy set which will lock out accounts upon bind
failure:
dn: ou=Policies,dc=blah ou: Policies objectClass: organizationalUnit
dn: cn=passwordDefault,ou=Policies,dc=blah objectClass: pwdPolicy objectClass: person objectClass: top cn: passwordDefault sn: passwordDefault pwdAttribute: userPassword pwdCheckQuality: 0 pwdMinAge: 0 pwdMaxAge: 365 pwdMinLength: 15 pwdInHistory: 5 pwdMaxFailure: 3 pwdFailureCountInterval: 0 pwdLockout: TRUE pwdLockoutDuration: 0 pwdAllowUserChange: TRUE pwdExpireWarning: 320 pwdGraceAuthNLimit: 0 pwdMustChange: TRUE pwdSafeModify: FALSE
I am using an account for binding with LDAP since my OpenLDAP ACLs
disallow
anon binds. My concern about this is that if a malicious user was to
start
attempting binds with the bind account, then they could lock out this important user thus bring down SSSD binding for all of my clients. I do not want.
sssd.conf:
ldap_uri = ldaps://provider ldap_backup_uri = ldaps://consumer ldap_default_bind_dn = uid=user,ou=sysadmin,dc=blah ldap_default_authtok_type = password ldap_default_authtok = longpass ldap_search_base = dc=blah ldap_tls_reqcert = demand ldap_tls_cacert = /etc/pki/tls/certs/sha2bundle.cer
This should probably be sent to another list though anyone know if its possible to exempt a single user from the above password policy so that pwdLockout would not apply?
I assume that other users are in different tree and not in ou=sysadmin,dc=blah. They would need to guess default bind DN because only root can raed sssd.conf otherwisee sssd would not start.
And if you are really worry about password policy for bind account then you can use custom policy for this account.
dn: uid=user,ou=sysadmin,dc=blah objectClass: account objectClass: posixAccount cn: user uidNumber: 12345 gidNumber: 12345 userPassword: {SSHA}aaaaaaaaaaaaaaaaaaaaaaaaaa objectClass: pwdPolicy pwdAttribute: userPassword pwdPolicySubentry: cn=customBindAccoundPolicy,ou=policies,$DS_BASE_DN
I didn't test that.
BTW you needn't use ldaps in ldap_uri because sssd would use start_tls anyway for bind and there are known issues with ldaps and failover.
LS
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users@lists.fedorahosted.org