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.