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.
>