[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: replication breaks ppolicy
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.