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.

________________________________ This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

Spent a few hours debugging this issue and while it is still work-in-progress, I thought I should share my findings.

So with chaining enabled, here’s a log snippet of when I do “sudo cat /etc/shadow” and enter a wrong password. ----xxxxxxx----- May 27 21:36:37 pldap03 slapd[9514]: do_bind: version=3 dn="uid=joe,ou=people,dc=example,dc=net" method=128 May 27 21:36:37 pldap03 slapd[9514]: => bdb_entry_get: ndn: "uid=joe,ou=people,dc=example,dc=net" May 27 21:36:37 pldap03 slapd[9514]: => bdb_entry_get: oc: "(null)", at: "(null)" May 27 21:36:37 pldap03 slapd[9514]: bdb_dn2entry("uid=joe,ou=people,dc=example,dc=net") May 27 21:36:37 pldap03 slapd[9514]: => bdb_entry_get: found entry: "uid=joe,ou=people,dc=example,dc=net" May 27 21:36:37 pldap03 slapd[9514]: bdb_entry_get: rc=0 May 27 21:36:37 pldap03 slapd[9514]: => bdb_entry_get: ndn: "cn=default,ou=policies,dc=example,dc=net" May 27 21:36:37 pldap03 slapd[9514]: => bdb_entry_get: oc: "(null)", at: "(null)" May 27 21:36:37 pldap03 slapd[9514]: bdb_dn2entry("cn=default,ou=policies,dc=example,dc=net") May 27 21:36:37 pldap03 slapd[9514]: => bdb_entry_get: found entry: "cn=default,ou=policies,dc=example,dc=net" May 27 21:36:37 pldap03 slapd[9514]: bdb_entry_get: rc=0 May 27 21:36:37 pldap03 slapd[9514]: ==> bdb_bind: dn: uid=joe,ou=people,dc=example,dc=net May 27 21:36:37 pldap03 slapd[9514]: bdb_dn2entry("uid=joe,ou=people,dc=example,dc=net") May 27 21:36:37 pldap03 slapd[9514]: => access_allowed: result not in cache (userPassword) May 27 21:36:37 pldap03 slapd[9514]: => access_allowed: auth access to "uid=joe,ou=people,dc=example,dc=net" "userPassword" requested May 27 21:36:37 pldap03 slapd[9514]: => dn: [1] May 27 21:36:37 pldap03 slapd[9514]: => dn: [2] cn=subschema May 27 21:36:37 pldap03 slapd[9514]: => dn: [3] cn=monitor May 27 21:36:37 pldap03 slapd[9514]: => dn: [4] ou=people,dc=example,dc=net May 27 21:36:37 pldap03 slapd[9514]: => acl_get: [4] matched May 27 21:36:37 pldap03 slapd[9514]: => acl_get: [4] attr userPassword May 27 21:36:37 pldap03 slapd[9514]: => acl_mask: access to entry "uid=joe,ou=people,dc=example,dc=net", attr "userPassword" requested May 27 21:36:37 pldap03 slapd[9514]: => acl_mask: to value by "", (=0) May 27 21:36:37 pldap03 slapd[9514]: <= check a_dn_pat: cn=manager,dc=example,dc=net May 27 21:36:37 pldap03 slapd[9514]: <= check a_dn_pat: ou=admins,dc=ldapadmins,dc=ssn May 27 21:36:37 pldap03 slapd[9514]: <= check a_dn_pat: anonymous May 27 21:36:37 pldap03 slapd[9514]: <= acl_mask: [3] applying auth(=xd) (stop) May 27 21:36:37 pldap03 slapd[9514]: <= acl_mask: [3] mask: auth(=xd) May 27 21:36:37 pldap03 slapd[9514]: => slap_access_allowed: auth access granted by auth(=xd) May 27 21:36:37 pldap03 slapd[9514]: => access_allowed: auth access granted by auth(=xd) May 27 21:36:37 pldap03 slapd[9514]: send_ldap_result: conn=1005 op=3 p=3 May 27 21:36:37 pldap03 slapd[9514]: send_ldap_result: err=49 matched="" text="" May 27 21:36:37 pldap03 slapd[9514]: => bdb_entry_get: ndn: "uid=joe,ou=people,dc=example,dc=net" May 27 21:36:37 pldap03 slapd[9514]: => bdb_entry_get: oc: "(null)", at: "(null)" May 27 21:36:37 pldap03 slapd[9514]: bdb_dn2entry("uid=joe,ou=people,dc=example,dc=net") May 27 21:36:37 pldap03 slapd[9514]: => bdb_entry_get: found entry: "uid=joe,ou=people,dc=example,dc=net" May 27 21:36:37 pldap03 slapd[9514]: bdb_entry_get: rc=0 May 27 21:36:37 pldap03 slapd[9514]: bdb_dn2entry("uid=joe,ou=people,dc=example,dc=net") May 27 21:36:37 pldap03 slapd[9514]: send_ldap_result: conn=1005 op=3 p=3 May 27 21:36:37 pldap03 slapd[9514]: send_ldap_result: err=10 matched="" text="" May 27 21:36:37 pldap03 slapd[9514]: send_ldap_result: referral="ldap://pldap01.ssntest.net/uid=joe,ou=people,dc=example,dc=net" May 27 21:36:37 pldap03 slapd[9514]: >>> dnPrettyNormal: <uid=joe,ou=people,dc=example,dc=net> May 27 21:36:37 pldap03 slapd[9514]: <<< dnPrettyNormal: <uid=joe,ou=people,dc=example,dc=net>, <uid=joe,ou=people,dc=example,dc=net> May 27 21:36:37 pldap03 slapd[9514]: daemon: activity on 1 descriptor May 27 21:36:37 pldap03 slapd[9514]: daemon: activity on: --------------xxxxxxxx---------------------------------------------------------------------------

Compare this to when chaining is disabled and for the same command “sudo cat /etc/shadow”, I enter a wrong password. --------------xxxxxxxx--------------------------------------------------------------------------- May 27 21:42:40 pldap03 slapd[9545]: do_bind: version=3 dn="uid=joe,ou=people,dc=example,dc=net" method=128 May 27 21:42:40 pldap03 slapd[9545]: => bdb_entry_get: ndn: "uid=joe,ou=people,dc=example,dc=net" May 27 21:42:40 pldap03 slapd[9545]: => bdb_entry_get: oc: "(null)", at: "(null)" May 27 21:42:40 pldap03 slapd[9545]: bdb_dn2entry("uid=joe,ou=people,dc=example,dc=net") May 27 21:42:40 pldap03 slapd[9545]: => bdb_entry_get: found entry: "uid=joe,ou=people,dc=example,dc=net" May 27 21:42:40 pldap03 slapd[9545]: bdb_entry_get: rc=0 May 27 21:42:40 pldap03 slapd[9545]: => bdb_entry_get: ndn: "cn=default,ou=policies,dc=example,dc=net" May 27 21:42:40 pldap03 slapd[9545]: => bdb_entry_get: oc: "(null)", at: "(null)" May 27 21:42:40 pldap03 slapd[9545]: bdb_dn2entry("cn=default,ou=policies,dc=example,dc=net") May 27 21:42:40 pldap03 slapd[9545]: => bdb_dn2id("ou=policies,dc=example,dc=net") May 27 21:42:40 pldap03 slapd[9545]: <= bdb_dn2id: got id=0x8 May 27 21:42:40 pldap03 slapd[9545]: daemon: activity on 1 descriptor May 27 21:42:40 pldap03 slapd[9545]: daemon: activity on: May 27 21:42:40 pldap03 slapd[9545]: May 27 21:42:40 pldap03 slapd[9545]: daemon: epoll: listen=7 active_threads=0 tvp=zero May 27 21:42:40 pldap03 slapd[9545]: daemon: epoll: listen=8 active_threads=0 tvp=zero May 27 21:42:40 pldap03 slapd[9545]: => bdb_dn2id("cn=default,ou=policies,dc=example,dc=net") May 27 21:42:40 pldap03 slapd[9545]: <= bdb_dn2id: got id=0x9 May 27 21:42:40 pldap03 slapd[9545]: entry_decode: "cn=default,ou=policies,dc=example,dc=net" May 27 21:42:40 pldap03 slapd[9545]: <= entry_decode(cn=default,ou=policies,dc=example,dc=net) May 27 21:42:40 pldap03 slapd[9545]: => bdb_entry_get: found entry: "cn=default,ou=policies,dc=example,dc=net" May 27 21:42:40 pldap03 slapd[9545]: bdb_entry_get: rc=0 May 27 21:42:40 pldap03 slapd[9545]: ==> bdb_bind: dn: uid=joe,ou=people,dc=example,dc=net May 27 21:42:40 pldap03 slapd[9545]: bdb_dn2entry("uid=joe,ou=people,dc=example,dc=net") May 27 21:42:40 pldap03 slapd[9545]: => access_allowed: result not in cache (userPassword) May 27 21:42:40 pldap03 slapd[9545]: => access_allowed: auth access to "uid=joe,ou=people,dc=example,dc=net" "userPassword" requested May 27 21:42:40 pldap03 slapd[9545]: => dn: [1] May 27 21:42:40 pldap03 slapd[9545]: => dn: [2] cn=subschema May 27 21:42:40 pldap03 slapd[9545]: => dn: [3] cn=monitor May 27 21:42:40 pldap03 slapd[9545]: => dn: [4] ou=people,dc=example,dc=net May 27 21:42:40 pldap03 slapd[9545]: => acl_get: [4] matched May 27 21:42:40 pldap03 slapd[9545]: => acl_get: [4] attr userPassword May 27 21:42:40 pldap03 slapd[9545]: => acl_mask: access to entry "uid=joe,ou=people,dc=example,dc=net", attr "userPassword" requested May 27 21:42:40 pldap03 slapd[9545]: => acl_mask: to value by "", (=0) May 27 21:42:40 pldap03 slapd[9545]: <= check a_dn_pat: cn=manager,dc=example,dc=net May 27 21:42:40 pldap03 slapd[9545]: <= check a_dn_pat: ou=admins,dc=ldapadmins,dc=ssn May 27 21:42:40 pldap03 slapd[9545]: <= check a_dn_pat: anonymous May 27 21:42:40 pldap03 slapd[9545]: <= acl_mask: [3] applying auth(=xd) (stop) May 27 21:42:40 pldap03 slapd[9545]: <= acl_mask: [3] mask: auth(=xd) May 27 21:42:40 pldap03 slapd[9545]: => slap_access_allowed: auth access granted by auth(=xd) May 27 21:42:40 pldap03 slapd[9545]: => access_allowed: auth access granted by auth(=xd) May 27 21:42:40 pldap03 slapd[9545]: send_ldap_result: conn=1001 op=3 p=3 May 27 21:42:40 pldap03 slapd[9545]: send_ldap_result: err=49 matched="" text="" May 27 21:42:40 pldap03 slapd[9545]: => bdb_entry_get: ndn: "uid=joe,ou=people,dc=example,dc=net" May 27 21:42:40 pldap03 slapd[9545]: => bdb_entry_get: oc: "(null)", at: "(null)" May 27 21:42:40 pldap03 slapd[9545]: bdb_dn2entry("uid=joe,ou=people,dc=example,dc=net") May 27 21:42:40 pldap03 slapd[9545]: => bdb_entry_get: found entry: "uid=joe,ou=people,dc=example,dc=net" May 27 21:42:40 pldap03 slapd[9545]: bdb_entry_get: rc=0 May 27 21:42:40 pldap03 slapd[9545]: bdb_dn2entry("uid=joe,ou=people,dc=example,dc=net") May 27 21:42:40 pldap03 slapd[9545]: send_ldap_result: conn=1001 op=3 p=3 May 27 21:42:40 pldap03 slapd[9545]: send_ldap_result: err=10 matched="" text="" May 27 21:42:40 pldap03 slapd[9545]: send_ldap_result: referral="ldap://pldap01.ssntest.net/uid=joe,ou=people,dc=example,dc=net" May 27 21:42:40 pldap03 slapd[9545]: send_ldap_response: msgid=4 tag=97 err=49 May 27 21:42:40 pldap03 slapd[9545]: conn=1001 op=3 RESULT tag=97 err=49 text= May 27 21:42:40 pldap03 slapd[9545]: daemon: activity on 1 descriptor May 27 21:42:40 pldap03 slapd[9545]: daemon: activity on: --------------xxxxxxxx---------------------------------------------------------------------------

Obeservations:

1. In both cases, the server returns “send_ldap_result: err=49 matched="" text=""” which says bind failed so sudo should fail irrespective of other things.

2. With chaining enabled, this operations is missing “bdb_dn2id("ou=policies,dc=example,dc=net")”.

3. With chaining disabled, entering a wrong password yields a log that says “sudo: pam_ldap: error trying to bind as user "uid=joe,ou=people,dc=example,dc=net" (Invalid credentials)” when I turn on debugging for pam_ldap.

4. With chaining enabled, entering a wrong password yields no such error message by pam_ldap so clearly with chaining enabled, pam_ldap interprets “err=49” not as bind failure but a successful auth (somehow).

All makes me think there’s a bug in pam_ldap. But then, I haven’t completed my investigation yet.

From: openldap-technical-bounces+sjain=silverspringnet.com@openldap.org [mailto:openldap-technical-bounces+sjain=silverspringnet.com@openldap.org] On Behalf Of Siddhartha Jain Sent: Wednesday, May 26, 2010 1:06 PM To: 'openldap-technical@openldap.org' Subject: RE: ppolicy master/slave issue (currently "forward ppolicy updates" OR "authenticate")

As a follow-up, I will send “any” logs of what the slave does when a user auths with bad password in these two setups:

1. Chaining disabled

2. Chaining enabled

Will also try to get logs from pam_ldap to see what’s going on there.

Thanks,

Siddhartha

From: Chris Jacobs [mailto:Chris.Jacobs@apollogrp.edu] Sent: Wednesday, May 26, 2010 11:44 AM To: Siddhartha Jain; 'openldap-technical@openldap.org' Cc: Howard Chu Subject: RE: ppolicy master/slave issue (currently "forward ppolicy updates" OR "authenticate")

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.

________________________________ This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.