Howard,
Am I (we?) missing something? Or is this how ppolicy works in a master/slave scenario?
Thanks,
- chris
From: openldap-technical-bounces+chris.jacobs=apollogrp.edu@OpenLDAP.org [mailto:openldap-technical-bounces+chris.jacobs=apollogrp.edu@OpenLDAP.org]
On Behalf Of Chris Jacobs
Sent: Wednesday, May 26, 2010 8:29 AM
To: 'sjain@silverspringnet.com'; 'openldap-technical@openldap.org'
Subject: Re: ppolicy master/slave issue (currently "forward ppolicy updates" OR "authenticate")
Whew! And I thought I was really off my rocker for a bit there - it made no sense to me (still doesn't, really).
One of the reasons for our LDAP upgrade was the pwdpolicy (and less out-of-sync slaves; an issue with our 2.3 boxes) - going to have to re-think our implementation - I really preferred the 'slave servers in remote locations' model, but if the ppolicy overlay
works best in a multi master model (replicating pwdfailures and authenticate - for real), I'll have to convince mgmt of the new model.
Thanks for checking Sidhartha!
- chris
Chris Jacobs, Systems Administrator
Apollo Group | Apollo Marketing | Aptimus
2001 6th Ave Ste 3200 | Seattle, WA 98121
phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661
email: chris.jacobs@apollogrp.edu
From: openldap-technical-bounces+chris.jacobs=apollogrp.edu@OpenLDAP.org
To: openldap-technical@openldap.org
Sent: Tue May 25 17:16:00 2010
Subject: RE: ppolicy master/slave issue (currently "forward ppolicy updates" OR "authenticate")
I replicated the setup and issues with slapd.d configuration.
Running OpenLDAP 2.4.21 on CentOS x64.
1.
Master and slave setup with ppolicy overlay.
2.
When client points to master, pwdFailures are duly recorded and respected. Password auth works as expected.
3.
When clients points to slave with chaining disabled, password auth and changes work fine but obviously pwdFailures are not recorded anywhere - neither on slave or master.
4.
When client points to slave with chaining enabled, password auth breaks meaning user can type any string and still get a successful auth. Interestingly, in this case, pwdFailures get recorded on slave and master.
Why or how a bind succeeds with a wrong password is weird. With slapd.d type config, the chain directives go under "frontendconfig" so I suspect the solution must lie there.
As a sidenote, I am thinking of doing without slaves and just creating more primaries in multi-mode replication. Seems less complicated in terms of configuration and maintenance.
Thanks,
- Siddhartha
> -----Original Message-----
> From: openldap-technical-bounces+sjain=silverspringnet.com@openldap.org
> [mailto:openldap-technical-
> bounces+sjain=silverspringnet.com@openldap.org] On Behalf Of Chris
> Jacobs
> Sent: Tuesday, May 25, 2010 9:16 AM
> To: openldap-technical@openldap.org
> Subject: RE: ppolicy master/slave issue (currently "forward ppolicy
> updates" OR "authenticate")
>
> Haven't heard anything on this yet...
>
> If someone could point me to some documentation, or better, graphic
> illustration, of how OpenLDAP 'works', perhaps I can figure this out on
> my own.
>
> Thanks,
> - chris
>
> -----Original Message-----
> From: openldap-technical-
> bounces+chris.jacobs=apollogrp.edu@OpenLDAP.org [mailto:openldap-
> technical-bounces+chris.jacobs=apollogrp.edu@OpenLDAP.org] On Behalf Of
> Chris Jacobs
> Sent: Thursday, May 06, 2010 11:45 AM
> To: openldap-technical@openldap.org
> Subject: RE: ppolicy master/slave issue (currently "forward ppolicy
> updates" OR "authenticate")
>
> Anyone?
>
> I can't be the only person trying to implement ppolicy_forward_updates
> and have user's actually authenticate...
>
> I've been poring over the documentation:
>
> http://www.openldap.org/doc/admin24/overlays.html#Password%20Policies
> http://www.symas.com/blog/?page_id=66
> http://www.openldap.org/software/man.cgi?query=slapo-
> ppolicy&sektion=5&apropos=0&manpath=OpenLDAP+2.4-Release
> Which indicates: "This setting is only useful on a replication
> consumer, and also requires the updateref setting and chain overlay to
> be appropriately configured."
>
> I tried "chain-rebind-as-user" and that didn't seem to help (you can
> see it in the configs below) - at least, how I tried it. Perhaps I
> misunderstand something (I'm hoping at least)
>
> I'm totally at a loss here...
>
> - chris
>
> -----Original Message-----
> From: openldap-technical-
> bounces+chris.jacobs=apollogrp.edu@OpenLDAP.org [mailto:openldap-
> technical-bounces+chris.jacobs=apollogrp.edu@OpenLDAP.org] On Behalf Of
> Chris Jacobs
> Sent: Monday, May 03, 2010 9:07 AM
> To: openldap-technical@openldap.org
> Subject: RE: ppolicy master/slave issue
>
> Really, I think this comes down to how to:
> * ppolicy_forward_updates requiring priviledges
> * authentication NOT requiring priviledges
>
> How do I split the two? Let ppolicy forward updates, which requires
> priviledges, and NOT specify any authentication while user's are
> authenticating?
>
> Thanks,
> - chris
>
> -----Original Message-----
> From: openldap-technical-
> bounces+chris.jacobs=apollogrp.edu@OpenLDAP.org [mailto:openldap-
> technical-bounces+chris.jacobs=apollogrp.edu@OpenLDAP.org] On Behalf Of
> Chris Jacobs
> Sent: Thursday, April 29, 2010 2:55 PM
> To: openldap-technical@openldap.org
> Subject: ppolicy master/slave issue
>
> Hello again,
>
> I'm having an odd issue with ppolicy and my master/slave config.
>
> First, my goals
> General use:
> Slave handles all reads locally.
> Writes get forwarded to the master by the slave.
>
> Password policy:
> When password failures happen on clients using slave ldap servers,
> the failures, etc, get passed to the master to get replicated to the
> slaves.
> I understand this would be done using the ppolicy option:
> ppolicy_forward_updates
>
> Authentication:
> Actually authenticate (more later).
>
> To the problem:
> ---------------
> When I leave the section in the chain bit of SLAVE slapd.conf below
> marked by lines intact (which bind as root):
> * ppolicy_forward_updates seems to work great - the master shows
> matching "pwdFailureTime" attributes.
> * Regardless of password entered, you get a shell. User/bad password =
> get a shell! This being a problem should be obvious.
> I suspect that's due to the chain overlay section...
>
> If I comment out the lines in the SLAVE slapd.conf:
> * authentication actually requires authentication (bad password = no
> authentication)
> * ppolicy_forward_updates don't work (no updates to master)
>
> It's possible that from my description some may already know my issue -
> however, just to be sure, I've pasted below 'bare' versions of the:
> * a master slapd.conf (sans schema includes)
> * a slave slapd.conf (sans schema includes)
> * /etc/ldap.conf (using slave)
> * /etc/openldap/ldap.conf (same on all ldap servers) (thanks Howard -
> they are NOT the same)
> * /etc/pam.d/system-auth-ac (CentOS 5.4; ssh refers to system-auth-ac
> for all types).
>
> Thanks for any help (and, likely, pointing out any 'stupids' below),
> - chris
>
> PS: Feel free to critique - you won't hurt my feelings.
>
> MASTER slapd.conf: (one of a pair, mirrored, active/passive fail over)
> ----------------------------------------------------------------------
> serverID 1
> loglevel 0
> pidfile /usr/local/var/openldap-data/run/slapd.pid
> argsfile /usr/local/var/openldap-data/run/slapd.args
> TLSCipherSuite HIGH:MEDIUM:+SSLv2
> TLSCACertificateFile /etc/openldap/cacerts/cacert.pem
> TLSCertificateFile /etc/openldap/cacerts/servercrt.pem
> TLSCertificateKeyFile /etc/openldap/cacerts/serverkey.pem
> TLSVerifyClient never
> password-hash {MD5}
> sizelimit size.soft=500 size.hard=unlimited
> timelimit time.soft=3600 time.soft=unlimited
> database bdb
> suffix "dc=example,dc=net"
> rootdn "cn=root,dc=example,dc=net"
> rootpw "secret"
> directory "/usr/local/var/openldap-data"
> include /etc/openldap/slapd.access.conf
> index uid,cn,gidNumber,uidNumber,memberUid eq
> index objectClass pres,eq
> index operatingSystem pres,eq
> index host pres,eq
> index rack eq
> index entryUUID eq
> index uniqueMember eq
> index entryCSN eq
> index site eq
> overlay ppolicy
> ppolicy_hash_cleartext
> ppolicy_use_lockout
> overlay syncprov
> syncprov-checkpoint 100 10
> syncprov-sessionlog 10
> syncrepl rid=2
> provider=ldaps://ldapmaster2.corp.example.net
> type=refreshAndPersist
> interval=00:00:10:00
> searchbase="dc=example,dc=net"
> bindmethod=simple
> binddn="cn=root,dc=example,dc=net"
> credentials="secret"
> retry="15 20 60 +"
> mirrormode on
> database monitor
>
> SLAVE slapd.conf:
> -----------------
> serverID 13
> loglevel 0
> pidfile /usr/local/var/openldap-data/run/slapd.pid
> argsfile /usr/local/var/openldap-data/run/slapd.args
> TLSCipherSuite HIGH:MEDIUM:+SSLv2
> TLSCACertificateFile /etc/openldap/cacerts/cacert.pem
> TLSCertificateFile /etc/openldap/cacerts/servercrt.pem
> TLSCertificateKeyFile /etc/openldap/cacerts/serverkey.pem
> TLSVerifyClient never
> password-hash {MD5}
> sizelimit size.soft=500 size.hard=unlimited
> timelimit time.soft=3600 time.soft=unlimited
> overlay chain
> chain-uri ldaps://ldap-vip.corp.example.net/
> chain-rebind-as-user TRUE
> vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
> vvvvvv
> chain-idassert-bind bindmethod="simple"
> binddn="cn=root,dc=example,dc=net"
> credentials="secret"
> mode="self"
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ^^^^^^
> chain-tls ldaps
> chain-return-error TRUE
> database bdb
> suffix "dc=example,dc=net"
> rootdn "cn=root,dc=example,dc=net"
> rootpw "secret"
> directory "/usr/local/var/openldap-data"
> include /etc/openldap/slapd.access.conf
> index uid,cn,gidNumber,uidNumber,memberUid eq
> index objectClass pres,eq
> index operatingSystem pres,eq
> index host pres,eq
> index rack eq
> index entryUUID eq
> index uniqueMember eq
> index entryCSN eq
> index site eq
> overlay ppolicy
> ppolicy_hash_cleartext
> ppolicy_use_lockout
> ppolicy_forward_updates
> syncrepl rid=1
> provider=ldaps://ldap-vip.corp.example.net
> type=refreshAndPersist
> interval=00:00:10:00
> searchbase="dc=example,dc=net"
> bindmethod=simple
> binddn="cn=root,dc=example,dc=net"
> credentials="secret"
> retry="15 20 60 +"
> updateref "ldaps://ldap-vip.corp.example.net"
> database monitor
>
> /etc/openldap/ldap.conf: (same on all LDAP servers)
> ---------------------------------------------------
> uri ldaps://localhost
> base dc=example,dc=net
> network_timeout 0
> sizelimit 0
> timelimit 0
> tls_cacert /etc/openldap/cacerts/cacert.pem
> tls_reqcert demand
>
> /etc/ldap.conf: (on client using slave)
> ---------------------------------------
> uri ldaps://ldap-vip.dc1.example.net
> timelimit 10
> bind_timelimit 10
> bind_policy soft
> base dc=example,dc=net
> scope sub
> ssl on
> tls_checkpeer no
> tls_cacertfile /etc/openldap/cacert.pem (contents same as
> /etc/openldap/cacerts/cacert.pem)
> pam_login_attribute uid
> pam_lookup_policy yes
> pam_password exop
>
> /etc/pam.d/system-auth-ac:
> --------------------------
> auth required pam_env.so
> auth sufficient pam_unix.so nullok try_first_pass
> auth requisite pam_succeed_if.so uid >= 500 quiet
> auth sufficient pam_ldap.so use_first_pass
> auth required pam_deny.so
>
> account required pam_unix.so broken_shadow
> account sufficient pam_localuser.so
> account sufficient pam_succeed_if.so uid < 500 quiet
> account [default=bad success=ok user_unknown=ignore] pam_ldap.so
> account required pam_permit.so
>
> password requisite pam_cracklib.so try_first_pass retry=3
> password sufficient pam_unix.so sha256 shadow nullok
> try_first_pass use_authtok
> password sufficient pam_ldap.so use_authtok
> password required pam_deny.so
>
> session optional pam_keyinit.so revoke
> session required pam_limits.so
> session optional pam_mkhomedir.so
> session [success=1 default=ignore] pam_succeed_if.so service in
> crond quiet use_uid
> session required pam_unix.so
> session optional pam_ldap.so
>
>
>
>
> This message is private and confidential. If you have received it in
> error, please notify the sender and remove it from your system.
>
>
>
>
> This message is private and confidential. If you have received it in
> error, please notify the sender and remove it from your system.
>
>
>
>
> This message is private and confidential. If you have received it in
> error, please notify the sender and remove it from your system.
>
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.