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