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