Good morning all
After quite a bit of work, I got replication working (thank you all).
So I forged ahead and deployed the server in our RHEL 5.5 environment. But now I just realized that none of my ppolicy rules work. Also, the Redhat clients are configured to use MD5 hash. When I look at the accounts in webmin, it shows it being crypt????? I know openldap likes salted SHA, but I thought I'd do what Redhat wanted, which was MD5.
Password history, aging etc... A search used to show me all of my ppolicy objects.
ldapsearch -v -x -b 'dc=chin,dc=ca' cn=default
But now returns nothing. Users can reuse passwords, so no history or aging is working. No locking. I had to change ACL's on the provider and consumer to get the replication working. Would that cause the problem?
Here is my policy LDIF file I added to the server:
# policies, chin.com dn: ou=policies,dc=chin,dc=ca objectClass: organizationalUnit objectClass: top ou: policies
# default, policies, chin.com dn: cn=default,ou=policies,dc=chin,dc=ca objectClass: top objectClass: device objectClass: pwdPolicy cn: default pwdAttribute: userPassword pwdInHistory: 6 pwdCheckQuality: 1 pwdMinLength: 8 pwdMaxFailure: 4 pwdLockout: TRUE pwdLockoutDuration: 1920 pwdGraceAuthNLimit: 0 pwdFailureCountInterval: 0 pwdMustChange: TRUE pwdAllowUserChange: TRUE pwdSafeModify: FALSE pwdMaxAge: 10368000 pwdExpireWarning: 1209600 pwdMinAge: 86400
Provider: # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/misc.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/redhat/autofs.schema
include /etc/openldap/schema/ppolicy.schema
### added for host_attr access, this scheme gives me a host object for wrappers include /usr/share/doc/nss_ldap-253/ldapns.schema
# Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 bind_anon_cred
# Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org
pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args
# note, enabling debbuging info really slows the beast down #loglevel 128 loglevel 256 #loglevel conns filter
logfile /var/log/slapd.log
# Load dynamic backend modules using this path!!! modulepath /usr/lib/openldap
moduleload ppolicy.la moduleload accesslog.la
# modules available in openldap-servers-sql RPM package: # moduleload back_sql.la
#################################################################
schemacheck on lastmod on
access to attrs=userPassword by self write by anonymous auth by * none
######################################## ### ACL for syncrepl. ########################################
#access to attrs=userPassword # by self write #by uid=replicator,ou=people,dc=chin,dc=ca read # by anonymous auth # by * none
access to attrs=userPassword,shadowLastChange by dn="dc=admin,dc=chin,dc=ca" write by anonymous auth
access to * by dn="dc=admin,dc=chin,dc=ca" write by * read
#access to attrs=shadowLastChange # by self write # by * read
access to * by * read
#### WIDE OPEN - For testing only ##NOPE access to * by * write access to * by * read # ------------------------------------------------------------------- # # Access log database instance for replication # ------------------------------------------------------------------- #
# Accesslog database definitions database bdb suffix cn=accesslog directory /var/lib/db/accesslog rootdn cn=accesslog index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart
overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE
# ------------------------------------------------------------------- # # Primary database instance # ------------------------------------------------------------------- #
database bdb suffix "dc=chin,dc=ca" rootdn "cn=admin, dc=chin,dc=ca"
# rootpw rootpw {SSHA}TCYoUVYYYXXXXXbQsitJ3V7zo+c887NC
directory /var/lib/ldap
index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub index entryCSN,entryUUID eq
# define the default policy overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=chin,dc=ca" ppolicy_use_lockout
# syncrepl Provider for primary db overlay syncprov syncprov-checkpoint 1000 60
# accesslog overlay definitions for primary db overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE # scan the accesslog DB every day, and purge entries older than 7 days logpurge 07+00:00 01+00:00
# Let the replica DN have limitless searches limits dn.exact="uid=replicator,ou=People,dc=chin,dc=ca" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
Consumer:
# # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/misc.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/redhat/autofs.schema include /etc/openldap/schema/ppolicy.schema
### added for host_attr access, this scheme gives me a host object for wrappers include /usr/share/doc/nss_ldap-253/ldapns.schema
# Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 bind_anon_cred
pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args
loglevel 256 logfile /var/log/slapd.log
modulepath /usr/lib/openldap
# ------------------------------------------------------------------- # # Primary database instance # ------------------------------------------------------------------- #
database bdb suffix "dc=chin,dc=ca" rootdn "cn=admin,dc=chin,dc=ca"
directory /var/lib/ldap
moduleload ppolicy.la overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=chin,dc=ca" ppolicy_use_lockout
# ------------------------------------------------------------------- # # Replica configuration instance # ------------------------------------------------------------------- #
# syncrepl specific indices index entryUUID eq uniqueMember index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub index entryCSN eq
# syncrepl directives syncrepl rid=0 provider=ldap://ldap bindmethod=simple binddn="uid=replicator,ou=people,dc=chin,dc=ca" #binddn="cn=admin,dc=chin,dc=ca" credentials=xxxxx searchbase="dc=chin,dc=ca" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=off type=refreshAndPersist retry="60 +" syncdata=accesslog
# Refer updates to the master updateref ldap://ldap
Any suggestions would be dandy and much appreciated. I'm new to LDAP, as you can tell.
Thanks
On Tuesday, 23 August 2011 15:12:41 rocke.robertson@pch.gc.ca wrote:
Good morning all
After quite a bit of work, I got replication working (thank you all).
So I forged ahead and deployed the server in our RHEL 5.5 environment.
RHEL5's openldap packages finally became somewhat usable at RHEL5.4, for openldap *2.3*. You may find you want newer (e.g. for ppolicy_forward_updates).
But now I just realized that none of my ppolicy rules work. Also, the Redhat clients are configured to use MD5 hash.
You don't want clients to hash passwords, you can't enforce any password quality checks on hashes. Use 'pam_password exop' if you want to enforce password quality (or otherwise be able to control password hashing on the server-side).
When I look at the accounts in webmin, it shows it being crypt????? I know openldap likes salted SHA, but I thought I'd do what Redhat wanted, which was MD5.
Why?
Password history, aging etc... A search used to show me all of my ppolicy objects.
ldapsearch -v -x -b 'dc=chin,dc=ca' cn=default
?
But now returns nothing. Users can reuse passwords, so no history or aging is working. No locking. I had to change ACL's on the provider and consumer to get the replication working. Would that cause the problem?
No.
Here is my policy LDIF file I added to the server:
# policies, chin.com dn: ou=policies,dc=chin,dc=ca objectClass: organizationalUnit objectClass: top ou: policies
# default, policies, chin.com dn: cn=default,ou=policies,dc=chin,dc=ca objectClass: top objectClass: device objectClass: pwdPolicy cn: default pwdAttribute: userPassword pwdInHistory: 6 pwdCheckQuality: 1 pwdMinLength: 8 pwdMaxFailure: 4 pwdLockout: TRUE pwdLockoutDuration: 1920 pwdGraceAuthNLimit: 0 pwdFailureCountInterval: 0 pwdMustChange: TRUE pwdAllowUserChange: TRUE pwdSafeModify: FALSE pwdMaxAge: 10368000 pwdExpireWarning: 1209600 pwdMinAge: 86400
Show some example accounts, requesting the operational attributes ('+'), and show authentication attempts (see ldapwhoami(1)) and password change attempts (see ldappasswd(1)) with the ppolicy control enabled (-e ppolicy).
Regards, Buchan
From: Buchan Milne bgmilne@staff.telkomsa.net To: openldap-technical@openldap.org Cc: rocke.robertson@pch.gc.ca Date: 23/08/2011 09:45 AM Subject: Re: replication breaks ppolicy
On Tuesday, 23 August 2011 15:12:41 rocke.robertson@pch.gc.ca wrote:
Good morning all
After quite a bit of work, I got replication working (thank you all).
So I forged ahead and deployed the server in our RHEL 5.5 environment.
RHEL5's openldap packages finally became somewhat usable at RHEL5.4, for openldap *2.3*. You may find you want newer (e.g. for ppolicy_forward_updates).
Will look into getting a newer version.
But now I just realized that none of my ppolicy rules work. Also, the Redhat clients are configured to use MD5 hash.
You don't want clients to hash passwords, you can't enforce any password quality checks on hashes. Use 'pam_password exop' if you want to enforce password quality (or otherwise be able to control password hashing on the server-side).
Have tried exop and clear as the documentation suggests is needed. No aging / history though...
When I look at the accounts in webmin, it shows it being crypt????? I know openldap likes salted SHA,
but
I thought I'd do what Redhat wanted, which was MD5.
Why?
Because... I guess cause I blindly follow vendor documentation? I do see folks complaining about this though.
Password history, aging etc... A search used to show me all of my ppolicy objects.
ldapsearch -v -x -b 'dc=chin,dc=ca' cn=default
?
But now returns nothing. Users can reuse passwords, so no history or
aging
is working. No locking. I had to change ACL's on the provider and
consumer
to get the replication working. Would that cause the problem?
No.
THen this is good.
Here is my policy LDIF file I added to the server:
# policies, chin.com dn: ou=policies,dc=chin,dc=ca objectClass: organizationalUnit objectClass: top ou: policies
# default, policies, chin.com dn: cn=default,ou=policies,dc=chin,dc=ca objectClass: top objectClass: device objectClass: pwdPolicy cn: default pwdAttribute: userPassword pwdInHistory: 6 pwdCheckQuality: 1 pwdMinLength: 8 pwdMaxFailure: 4 pwdLockout: TRUE pwdLockoutDuration: 1920 pwdGraceAuthNLimit: 0 pwdFailureCountInterval: 0 pwdMustChange: TRUE pwdAllowUserChange: TRUE pwdSafeModify: FALSE pwdMaxAge: 10368000 pwdExpireWarning: 1209600 pwdMinAge: 86400
Show some example accounts, requesting the operational attributes ('+'),
and
show authentication attempts (see ldapwhoami(1)) and password change
attempts
(see ldappasswd(1)) with the ppolicy control enabled (-e ppolicy).
-bash-3.2$ ldapwhoami -x -D "uid=bigbob,ou=People,dc=chin,dc=ca" -W -e ppolicy Enter LDAP Password: dn:uid=bigbob,ou=People,dc=chin,dc=ca Result: Success (0)
Not a whole hell of a lot of information is produced. I don't know this command well so I'm not sure, but I think this is a little shy on output?
-bash-3.2$ id uid=10014(bigbob) gid=100(users) groups=100(users)
-bash-3.2$ ldappasswd -h ldap -x -D cn=admin,dc=chin,dc=ca "uid=bigbob,ou=People,dc=chin,dc=ca" -W -S -e ppolicy New password: Re-enter new password: Enter LDAP Password: Result: Success (0)
-bash-3.2$
I can change the password with ldappasswd, and here I am changing it to the existing password with no errors or complaints. That used to fail.
I'm sorry but I'm not %100 sure what an operations attribute of ('+')is, but here is an account that was created with the pwdpolicy objectclass. I used to be able to get all the aging, last changed, lock and history information....
ldapsearch -v -x -b 'dc=chin,dc=ca' uid=bigbob -e ppolicy
# extended LDIF # # LDAPv3 # base <dc=chin,dc=ca> with scope subtree # filter: uid=bigbob # requesting: ALL #
# bigbob, People, chin.ca dn: uid=bigbob,ou=People,dc=chin,dc=ca pwdAttribute: userPassword shadowMax: 99999 uid: bigbob cn: Big Bob homeDirectory: /homes/bigbob uidNumber: 10014 objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount objectClass: hostObject objectClass: pwdPolicy host: db1.rcip-chin.gc.ca host: db2.rcip-chin.gc.ca host: db-cl1.rcip-chin.gc.ca host: db-cl2.rcip-chin.gc.ca shadowWarning: 7 gidNumber: 100 gecos: Big Bob loginShell: /bin/bash
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
Buchan, thanks for your help.
Rocke
On Tuesday, 23 August 2011 16:12:52 rocke.robertson@pch.gc.ca wrote:
From: Buchan Milne bgmilne@staff.telkomsa.net To: openldap-technical@openldap.org Cc: rocke.robertson@pch.gc.ca Date: 23/08/2011 09:45 AM Subject: Re: replication breaks ppolicy
On Tuesday, 23 August 2011 15:12:41 rocke.robertson@pch.gc.ca wrote:
Good morning all
After quite a bit of work, I got replication working (thank you all).
So I forged ahead and deployed the server in our RHEL 5.5 environment.
RHEL5's openldap packages finally became somewhat usable at RHEL5.4, for openldap *2.3*. You may find you want newer (e.g. for ppolicy_forward_updates).
Will look into getting a newer version.
You may want to look here:
http://staff.telkomsa.net/packages/
(has 2.4.25, will soon have 2.4.26).
But now I just realized that none of my ppolicy rules work. Also, the Redhat clients are configured to use MD5 hash.
You don't want clients to hash passwords, you can't enforce any password quality checks on hashes. Use 'pam_password exop' if you want to enforce password quality (or otherwise be able to control password hashing on the server-side).
Have tried exop and clear as the documentation suggests is needed. No aging / history though...
When I look at the accounts in webmin, it shows it being crypt????? I know openldap likes salted SHA,
but
I thought I'd do what Redhat wanted, which was MD5.
Why?
Because... I guess cause I blindly follow vendor documentation? I do see folks complaining about this though.
Password history, aging etc... A search used to show me all of my ppolicy objects.
ldapsearch -v -x -b 'dc=chin,dc=ca' cn=default
?
But now returns nothing. Users can reuse passwords, so no history or
aging
is working. No locking. I had to change ACL's on the provider and
consumer
to get the replication working. Would that cause the problem?
No.
THen this is good.
Here is my policy LDIF file I added to the server:
# policies, chin.com dn: ou=policies,dc=chin,dc=ca objectClass: organizationalUnit objectClass: top ou: policies
# default, policies, chin.com dn: cn=default,ou=policies,dc=chin,dc=ca objectClass: top objectClass: device objectClass: pwdPolicy cn: default pwdAttribute: userPassword pwdInHistory: 6 pwdCheckQuality: 1 pwdMinLength: 8 pwdMaxFailure: 4 pwdLockout: TRUE pwdLockoutDuration: 1920 pwdGraceAuthNLimit: 0 pwdFailureCountInterval: 0 pwdMustChange: TRUE pwdAllowUserChange: TRUE pwdSafeModify: FALSE pwdMaxAge: 10368000 pwdExpireWarning: 1209600 pwdMinAge: 86400
Show some example accounts, requesting the operational attributes ('+'),
and
show authentication attempts (see ldapwhoami(1)) and password change
attempts
(see ldappasswd(1)) with the ppolicy control enabled (-e ppolicy).
-bash-3.2$ ldapwhoami -x -D "uid=bigbob,ou=People,dc=chin,dc=ca" -W -e ppolicy Enter LDAP Password: dn:uid=bigbob,ou=People,dc=chin,dc=ca Result: Success (0)
Not a whole hell of a lot of information is produced. I don't know this command well so I'm not sure, but I think this is a little shy on output?
An example with a password that is about to expire (coincidentally):
[bgmilne@tiger ~]$ ldapwhoami -x -D uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com -W -e ppolicy Enter LDAP Password: ldap_bind: Success (0) (Password expires in 14811 seconds)
-bash-3.2$ id uid=10014(bigbob) gid=100(users) groups=100(users)
-bash-3.2$ ldappasswd -h ldap -x -D cn=admin,dc=chin,dc=ca "uid=bigbob,ou=People,dc=chin,dc=ca" -W -S -e ppolicy New password: Re-enter new password: Enter LDAP Password: Result: Success (0)
-bash-3.2$
I can change the password with ldappasswd, and here I am changing it to the existing password with no errors or complaints. That used to fail.
[bgmilne@tiger ~]$ ldappasswd -x -D uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com -W -S -e ppolicy New password: Re-enter new password: Enter LDAP Password: Result: Constraint violation (19) Additional info: Password is not being changed from existing value control: 1.3.6.1.4.1.42.2.27.8.5.1 false MAOBAQg= ppolicy: error=8 (New password is in list of old passwords)
I'm sorry but I'm not %100 sure what an operations attribute of ('+')is, but here is an account that was created with the pwdpolicy objectclass. I used to be able to get all the aging, last changed, lock and history information....
ldapsearch -v -x -b 'dc=chin,dc=ca' uid=bigbob -e ppolicy
# extended LDIF # # LDAPv3 # base <dc=chin,dc=ca> with scope subtree # filter: uid=bigbob # requesting: ALL #
# bigbob, People, chin.ca dn: uid=bigbob,ou=People,dc=chin,dc=ca pwdAttribute: userPassword shadowMax: 99999 uid: bigbob cn: Big Bob homeDirectory: /homes/bigbob uidNumber: 10014 objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount objectClass: hostObject objectClass: pwdPolicy host: db1.rcip-chin.gc.ca host: db2.rcip-chin.gc.ca host: db-cl1.rcip-chin.gc.ca host: db-cl2.rcip-chin.gc.ca shadowWarning: 7 gidNumber: 100 gecos: Big Bob loginShell: /bin/bash
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
[bgmilne@tiger CatDap]$ ldapsearch -LLL -x -D 'uid=LDAP Admin,ou=System Accounts,dc=ranger,dc=dnsalias,dc=com' -W "(uid=bgmilne)" '+' Enter LDAP Password: dn: uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com structuralObjectClass: inetOrgPerson entryUUID: 8b74bea0-f20d-101e-8cdf-6105b6f2f478 creatorsName: uid=account admin,ou=system accounts,dc=ranger,dc=dnsailas,dc=co m createTimestamp: 19960203002836Z pwdPolicySubentry: cn=default,ou=Password Policies,dc=ranger,dc=dnsalias,dc=co m pwdChangedTime: 20110824062606Z pwdHistory: 20110824062606Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}Os/M84d/89D oNHCc1JutMnIHnyezjE47 entryCSN: 20110824062606.003012Z#000000#003#000000 modifiersName: uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com modifyTimestamp: 20110824062606Z entryDN: uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com subschemaSubentry: cn=Subschema hasSubordinates: FALSE
Of interest are pwdChangedTime, pwdHistory, and possibly pwdFailureTime, pwdAccountLockedTime etc.
But, yes, it looks like ppolicy is not active, even though your configuration looks ok.
Hi again Buchan
Will look into getting a newer version.
You may want to look here:
http://staff.telkomsa.net/packages/
(has 2.4.25, will soon have 2.4.26).
Have downloaded the newer version and will mess about with it today.
Boy oh boy. NIS was a lot easier.
Not a whole hell of a lot of information is produced. I don't know this command well so I'm not sure, but I think this is a little shy on output?
An example with a password that is about to expire (coincidentally):
[bgmilne@tiger ~]$ ldapwhoami -x -D uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com -W -e ppolicy Enter LDAP Password: ldap_bind: Success (0) (Password expires in 14811 seconds)
First of all, my ldap.conf has the following:
base dc=chin,dc=ca timelimit 120 bind_timelimit 120 idle_timelimit 3600 pam_lookup_policy yes pam_check_host_attr yes nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm
uri ldap://ldapslave,ldap://ldap ssl no tls_cacertdir /etc/openldap/cacerts pam_password clear
(I've tried exop, but all my redhat documentation claims that I need clear for ppolicy to work). I've found Redhat's documentation to be incorrect in some cases. So... maybe exop is the way to go as you mentioned earlier. Here is my ldapwhoami:
ldapwhoami -x -D uid=bigbob,ou=People,dc=chin,dc=ca -W -e ppolicy Enter LDAP Password: dn:uid=bigbob,ou=People,dc=chin,dc=ca Result: Success (0)
But no expiry information
Here I try to change my password using ldappasswd and set it to the existing password, and it does error out.
-bash-3.2$ ldappasswd -x -D uid=bigbob,ou=People,dc=chin,dc=ca -W -S -e ppolicy New password: Re-enter new password: Enter LDAP Password: Result: Constraint violation (19) Additional info: Password is not being changed from existing value
But I can set my password to an obvious dictionary word and it allows it. So that is a little odd.
If I use the native redhat password (/usr/bin/passwd) , it goes through the PAM modules and gives the following:
-bash-3.2$ passwd Changing password for user bigbob. Enter login(LDAP) password: New UNIX password: BAD PASSWORD: it does not contain enough DIFFERENT characters New UNIX password: BAD PASSWORD: it is based upon your password entry New UNIX password: BAD PASSWORD: it does not contain enough DIFFERENT characters passwd: Authentication token manipulation error
Should users use the /bin/passwd or ldappasswd to change there passwords?
If the ldap.conf is set to:
pam_password md5 and a password is generated:
# getent shadow bigbob berts:$1$HAxEnXcQ$fxRpg7vv5Y/EabPkdrpu00:15202:0:99999:7:::
Which makes sense as it's the client who generates the hash (md5) in this case.
A password generated from a /bin/passwd give me:
pam_password exop
# getent shadow bigbob bigbob:*:::99999:7:::
Which I think makes sense, because it's the ldap server that has generated the hash. ?? This is the way it should be I believe.
Re. @tiger.. Brings back memories. I worked on a SPARC 10 for years called tiger. Early 90's.. (SunOS 4.x...)
[bgmilne@tiger CatDap]$ ldapsearch -LLL -x -D 'uid=LDAP Admin,ou=System Accounts,dc=ranger,dc=dnsalias,dc=com' -W "(uid=bgmilne)" '+' Enter LDAP Password: dn: uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com structuralObjectClass: inetOrgPerson entryUUID: 8b74bea0-f20d-101e-8cdf-6105b6f2f478 creatorsName: uid=account admin,ou=system
accounts,dc=ranger,dc=dnsailas,dc=co
m createTimestamp: 19960203002836Z pwdPolicySubentry: cn=default,ou=Password
Policies,dc=ranger,dc=dnsalias,dc=co
m pwdChangedTime: 20110824062606Z pwdHistory:
20110824062606Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}Os/M84d/89D
oNHCc1JutMnIHnyezjE47 entryCSN: 20110824062606.003012Z#000000#003#000000 modifiersName: uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com modifyTimestamp: 20110824062606Z entryDN: uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com subschemaSubentry: cn=Subschema hasSubordinates: FALSE Of interest are pwdChangedTime, pwdHistory, and possibly pwdFailureTime, pwdAccountLockedTime etc. But, yes, it looks like ppolicy is not active, even though your
configuration
looks ok.
Here is my ldapsearch, just like your search:
ldapsearch -LLL -x -D 'cn=admin,dc=chin,dc=ca' -W "(uid=bigbob)" '+' Enter LDAP Password:
dn: uid=bigbob,ou=People,dc=chin,dc=ca structuralObjectClass: account entryUUID: 39e67d80-3603-1030-8b9b-d712f0a88d0f creatorsName: cn=admin,dc=chin,dc=ca createTimestamp: 20110628185024Z pwdChangedTime: 20110824135609Z entryCSN: 20110824135609Z#000000#00#000000 modifiersName: cn=admin,dc=chin,dc=ca modifyTimestamp: 20110824135609Z entryDN: uid=bigbob,ou=People,dc=chin,dc=ca subschemaSubentry: cn=Subschema hasSubordinates: FALSE
Here is mine which shows the pwdPolicy object:
ldapsearch -v -x -b 'dc=chin,dc=ca' uid=bigbob
# bigbob, People, chin.ca dn: uid=bigbob,ou=People,dc=chin,dc=ca pwdAttribute: userPassword shadowMax: 99999 uid: bigbob cn: Big Bob homeDirectory: /homes/bigbob uidNumber: 10014 objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount objectClass: hostObject objectClass: pwdPolicy host: db1.xyz.ca host: db2.xyz.ca host: db-sl1.xyz.ca shadowWarning: 7 gidNumber: 100 gecos: Big Bob loginShell: /bin/bash
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
Thank you for your continued help. I suppose my learning curve needs to be a bell curve, still.
On 08/24/2011 08:13 AM, rocke.robertson@pch.gc.ca wrote:
Have downloaded the newer version and will mess about with it today.
Boy oh boy. NIS was a lot easier.
True, but not nearly as secure. :-)
My employer sells time on some systems with thousands of CPU cores and we recently set them up to use LDAP with a combination of nss_ldap and pam_ldap with OpenLDAP using ppolicy and accesslog (and N-way replication). It took a while to get all the bits 'n bobs configured 'n working the way we wanted, but was well worth the effort.
I sleep better at night knowing that even if someone manages to get root on one of these systems they can't get a list of hashes to try to crack (the OpenLDAP ACLs allow authentication requests and allow an authenticated user to change his own userPassword attribute but that's it). 'Course they could get the hashes if they hacked the OpenLDAP servers themselves but it raises the bar a lot higher than "cat /etc/shadow" or "ypcat passwd". :-)
And you can imagine how quickly a password cracker would run on a system with 2048+ CPUs and 16 terabytes of physical memory or one of the prism systems with crazy numbers of GPUs.... (heh heh)
Brent
openldap-technical@openldap.org
-
Brent Bice -
Buchan Milne -
rocke.robertson＠pch.gc.ca