[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: ppolicy master/slave issue (currently "forward ppolicy updates" OR "authenticate")



One more observation:

1.       When changing password on the client, with client pointing at slave (with chaining enabled), the password change only goes through when the right password is supplied.

2.       But, entering a wrong password won’t give you a password fail message.

 

 

Look at this transaction, where I enter a wrong password for password change:

 

$ passwd

Changing password for user joe.

Enter login(LDAP) password:

New UNIX password:

Retype new UNIX password:

LDAP password information update failed: Strong(er) authentication required

only authenticated users may change passwords

passwd: Permission denied

 

 

 

From: Siddhartha Jain
Sent: Tuesday, May 25, 2010 5:16 PM
To: openldap-technical@openldap.org
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.

>