[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
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
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
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.