Hello,
I've gotten our password policy to function as it should - password expire requiring password changes, can't use old passwords, etc.
I'm working on last little detail - getting the password expiration warning to display.
For example, I see in the logs: "Mar 29 19:27:38 ldapmaster1 slapd[32653]: ppolicy_bind: Setting warning for password expiry for uid=chrisjtest,ou=people,dc=unix,dc=aptimus,dc=net = 3141 seconds"
But I never get the notice on login clients - regardless of client type (even from machine to itself).
I suspect ya'll are going to be interested in ldap.conf and pam config, so here they are, along with some possibly relevant bits:
/etc/ldap.conf: uri ldaps://ldapmaster1.corp.aptimus.net timelimit 10 bind_timelimit 10 bind_policy soft base dc=unix,dc=aptimus,dc=net scope sub ssl on tls_checkpeer no tls_cacertfile /etc/openldap/cacert.pem pam_login_attribute uid pam_lookup_policy yes pam_password exop
/etc/pam.d/system-auth-ac: #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. 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 md5 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
# ssh -V OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
# grep -i pam /etc/ssh/sshd_config # Set this to 'yes' to enable PAM keyboard-interactive authentication # PAMAuthenticationViaKbdInt no UsePAM yes
Ppolicy directives in /etc/openldap/slapd.conf (under the sold database definition): overlay ppolicy ppolicy_hash_cleartext ppolicy_use_lockout
AND just for giggles, I decided to see if I could get the version of pam_ldap.so that's installed, and ran strings on it. I notice two things: 1.3.6.1.4.1.42.2.27.8.5.1 (objectclass=passwordPolicy)
The ppolicy.schema file compiled used IDs 1.3.6.1.4.1.42.2.27.8.1.x - not ..8.5.x - could I possibly have some weird mismatch here?
(I suspect and hope that the last bit here is a totally unrelated red herring.)
Thanks, - chris
Chris Jacobs, Jr. Linux Administrator, Information Technology & Operations Apollo Group | Apollo Marketing | Aptimus, Inc. 2001 6th Ave | Ste 3200 | Seattle, WA 98121 phone: 206.441-9100 x1245 | cell: 206.601.3256 | Fax: 208.441.9661 email: chris.jacobs@apollogrp.edu
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
STRANGE.
I'd just decided to 'heck with this' and work out some process that will send emails - removing the 'need' for this feature.
So I modified the policy to 184 days (max value for any 6 months), set the password warning to 1 second less than that, and viola! When I login with my test account it now tells me my password will expire in 183 days.
Is that the trick? Previously, I'd set my expiration to 60 minutes...
ALSO: when I asked my coworker to login to check it out - he wasn't getting the notice.
Investigating further, I notice that his account was setup a long time ago - and things are done differently now.
His account objectclasses: objectClass: account objectClass: posixAccount objectClass: shadowAccount objectClass: top
Mine (Test account): objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount objectClass: top
If I attempt to modify his account to remove the objectclass account and add inetOrgPerson, ldap complains: "Mar 29 22:51:36 ldapmaster1 slapd[32653]: entry failed schema check: structural object class modification from 'account' to 'inetOrgPerson' not allowed"
At the same time, my LDAP browser (apache DS) also adds organizationalPerson and person objectclasses to his account - which smbldap-useradd (the tool we've historically used to add accounts) hasn't been doing.
If I simply attempt to add just the inetOrgPerson class, and not remove account - slapd complains slightly differently: "Mar 29 23:05:22 ldapmaster1 slapd[32653]: entry failed schema check: invalid structural object class chain (account/inetOrgPerson)"
I suspect, and would love verification/clarification/clue-by-fours: 1) I'm going to need to change how we add users - suggestions for a 'better' CLI method? 2) I'm probably going to need to scrub these accounts so that they're created correctly - likely through a slapcat - modify output - wipe db (or delete entry) - slapadd (replace slapcat/add with ldapmodify if that's your pref).
Am I about on target?
- chris
PS: I haven't seen /anywhere/ what objectclasses are required for certain 'features' to work correctly - why not? If that's a limitation/requirement you'd expect someone to mention it...
-----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, March 29, 2010 12:37 PM To: 'openldap-technical@openldap.org' Subject: Not getting password expiry warnings on login
Hello,
I've gotten our password policy to function as it should - password expire requiring password changes, can't use old passwords, etc.
I'm working on last little detail - getting the password expiration warning to display.
For example, I see in the logs: "Mar 29 19:27:38 ldapmaster1 slapd[32653]: ppolicy_bind: Setting warning for password expiry for uid=chrisjtest,ou=people,dc=unix,dc=aptimus,dc=net = 3141 seconds"
But I never get the notice on login clients - regardless of client type (even from machine to itself).
I suspect ya'll are going to be interested in ldap.conf and pam config, so here they are, along with some possibly relevant bits:
/etc/ldap.conf: uri ldaps://ldapmaster1.corp.aptimus.net timelimit 10 bind_timelimit 10 bind_policy soft base dc=unix,dc=aptimus,dc=net scope sub ssl on tls_checkpeer no tls_cacertfile /etc/openldap/cacert.pem pam_login_attribute uid pam_lookup_policy yes pam_password exop
/etc/pam.d/system-auth-ac: #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. 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 md5 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
# ssh -V OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
# grep -i pam /etc/ssh/sshd_config # Set this to 'yes' to enable PAM keyboard-interactive authentication # PAMAuthenticationViaKbdInt no UsePAM yes
Ppolicy directives in /etc/openldap/slapd.conf (under the sold database definition): overlay ppolicy ppolicy_hash_cleartext ppolicy_use_lockout
AND just for giggles, I decided to see if I could get the version of pam_ldap.so that's installed, and ran strings on it. I notice two things: 1.3.6.1.4.1.42.2.27.8.5.1 (objectclass=passwordPolicy)
The ppolicy.schema file compiled used IDs 1.3.6.1.4.1.42.2.27.8.1.x - not ..8.5.x - could I possibly have some weird mismatch here?
(I suspect and hope that the last bit here is a totally unrelated red herring.)
Thanks, - chris
Chris Jacobs, Jr. Linux Administrator, Information Technology & Operations Apollo Group | Apollo Marketing | Aptimus, Inc. 2001 6th Ave | Ste 3200 | Seattle, WA 98121 phone: 206.441-9100 x1245 | cell: 206.601.3256 | Fax: 208.441.9661 email: chris.jacobs@apollogrp.edu
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.
On Tuesday, 30 March 2010 00:09:42 Chris Jacobs wrote:
STRANGE.
I'd just decided to 'heck with this' and work out some process that will send emails - removing the 'need' for this feature.
So I modified the policy to 184 days (max value for any 6 months), set the password warning to 1 second less than that, and viola! When I login with my test account it now tells me my password will expire in 183 days.
Is that the trick? Previously, I'd set my expiration to 60 minutes...
ALSO: when I asked my coworker to login to check it out - he wasn't getting the notice.
Most likely he had last changed his password before ppolicy was enabled, as such his account's entry probably has not pwdChangedTime, ppolicy can't calculate the password age.
Investigating further, I notice that his account was setup a long time ago
- and things are done differently now.
His account objectclasses: objectClass: account objectClass: posixAccount objectClass: shadowAccount objectClass: top
Mine (Test account): objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount objectClass: top
If I attempt to modify his account to remove the objectclass account and add inetOrgPerson, ldap complains: "Mar 29 22:51:36 ldapmaster1 slapd[32653]: entry failed schema check: structural object class modification from 'account' to 'inetOrgPerson' not allowed"
You can't change structuralObjectclass, and account and inetOrgPerson are the structuralObjectclasses in question. If you want to change this (which in itself isn't the cause of your problem), you will have to delete and recreate. Most likely this will fix your problem as you will have a newly modified userPassword attribute (but, any other way of updating userPassword would fix the password expiry problem).
At the same time, my LDAP browser (apache DS) also adds organizationalPerson and person objectclasses to his account - which smbldap-useradd (the tool we've historically used to add accounts) hasn't been doing.
Irrelevant.
If I simply attempt to add just the inetOrgPerson class, and not remove account - slapd complains slightly differently: "Mar 29 23:05:22 ldapmaster1 slapd[32653]: entry failed schema check: invalid structural object class chain (account/inetOrgPerson)"
See above.
I suspect, and would love verification/clarification/clue-by-fours:
- I'm going to need to change how we add users - suggestions for a
'better' CLI method?
Not necessarily.
- I'm probably going to need to scrub these accounts
so that they're created correctly - likely through a slapcat - modify output - wipe db (or delete entry) - slapadd (replace slapcat/add with ldapmodify if that's your pref).
No, update userPassword. E.g., something which does more or less:
ldapsearch "(&(userPassword=*)(!(pwdChangedTime=*)))" userPassword|ldapmodify
Am I about on target?
- chris
PS: I haven't seen /anywhere/ what objectclasses are required for certain 'features' to work correctly - why not? If that's a limitation/requirement you'd expect someone to mention it...
Since it isn't, it isn't ...
Regards, Buchan
I haven't had any success adding pwdChangedTime to accounts - and it seems you've assisted others with that issue - with the result being "ya can't do that".
http://www.openldap.org/lists/openldap-software/200706/msg00298.html
So, how do I add pwdChangedTime to accounts?
I'm being advised here to do so, but the only success I've had so far is painful: delete the entry, and use slapadd.
Thanks, - chris
PS: Yes, I've read the man page for ldapmodify - I see mention of some 'general extensions flag - but it doesn't make sense to me. I've also seen mention of a '-k' flag, but it's not an option with the version of ldapsearch compiled with openldap 2.4.
-----Original Message----- From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net] Sent: Tuesday, March 30, 2010 3:57 AM To: openldap-technical@openldap.org Cc: Chris Jacobs Subject: Re: Not getting password expiry warnings on login
On Tuesday, 30 March 2010 00:09:42 Chris Jacobs wrote:
STRANGE.
I'd just decided to 'heck with this' and work out some process that will send emails - removing the 'need' for this feature.
So I modified the policy to 184 days (max value for any 6 months), set the password warning to 1 second less than that, and viola! When I login with my test account it now tells me my password will expire in 183 days.
Is that the trick? Previously, I'd set my expiration to 60 minutes...
ALSO: when I asked my coworker to login to check it out - he wasn't getting the notice.
Most likely he had last changed his password before ppolicy was enabled, as such his account's entry probably has not pwdChangedTime, ppolicy can't calculate the password age.
Investigating further, I notice that his account was setup a long time ago
- and things are done differently now.
His account objectclasses: objectClass: account objectClass: posixAccount objectClass: shadowAccount objectClass: top
Mine (Test account): objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount objectClass: top
If I attempt to modify his account to remove the objectclass account and add inetOrgPerson, ldap complains: "Mar 29 22:51:36 ldapmaster1 slapd[32653]: entry failed schema check: structural object class modification from 'account' to 'inetOrgPerson' not allowed"
You can't change structuralObjectclass, and account and inetOrgPerson are the structuralObjectclasses in question. If you want to change this (which in itself isn't the cause of your problem), you will have to delete and recreate. Most likely this will fix your problem as you will have a newly modified userPassword attribute (but, any other way of updating userPassword would fix the password expiry problem).
At the same time, my LDAP browser (apache DS) also adds organizationalPerson and person objectclasses to his account - which smbldap-useradd (the tool we've historically used to add accounts) hasn't been doing.
Irrelevant.
If I simply attempt to add just the inetOrgPerson class, and not remove account - slapd complains slightly differently: "Mar 29 23:05:22 ldapmaster1 slapd[32653]: entry failed schema check: invalid structural object class chain (account/inetOrgPerson)"
See above.
I suspect, and would love verification/clarification/clue-by-fours:
- I'm going to need to change how we add users - suggestions for a
'better' CLI method?
Not necessarily.
- I'm probably going to need to scrub these accounts
so that they're created correctly - likely through a slapcat - modify output - wipe db (or delete entry) - slapadd (replace slapcat/add with ldapmodify if that's your pref).
No, update userPassword. E.g., something which does more or less:
ldapsearch "(&(userPassword=*)(!(pwdChangedTime=*)))" userPassword|ldapmodify
Am I about on target?
- chris
PS: I haven't seen /anywhere/ what objectclasses are required for certain 'features' to work correctly - why not? If that's a limitation/requirement you'd expect someone to mention it...
Since it isn't, it isn't ...
Regards, Buchan
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
On Tuesday, 30 March 2010 19:50:15 Chris Jacobs wrote:
I haven't had any success adding pwdChangedTime to accounts - and it seems you've assisted others with that issue - with the result being "ya can't do that".
http://www.openldap.org/lists/openldap-software/200706/msg00298.html
So, how do I add pwdChangedTime to accounts?
By updating userPassword, as covered in point (2) in my previous reply. See below.
I'm being advised here to do so, but the only success I've had so far is painful: delete the entry, and use slapadd.
Thanks,
- chris
PS: Yes, I've read the man page for ldapmodify - I see mention of some 'general extensions flag - but it doesn't make sense to me. I've also seen mention of a '-k' flag, but it's not an option with the version of ldapsearch compiled with openldap 2.4.
I provide a more complete script below.
-----Original Message----- From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net] Sent: Tuesday, March 30, 2010 3:57 AM To: openldap-technical@openldap.org Cc: Chris Jacobs Subject: Re: Not getting password expiry warnings on login
- I'm probably going to need to scrub these accounts
so that they're created correctly - likely through a slapcat - modify output - wipe db (or delete entry) - slapadd (replace slapcat/add with ldapmodify if that's your pref).
No, update userPassword. E.g., something which does more or less:
ldapsearch "(&(userPassword=*)(!(pwdChangedTime=*)))" userPassword|ldapmodify
ldapsearch -LLL "(&(userPassword=*)(!(pwdChangedTime=*)))" userPassword|perl - p0e 's/\n(userPassword:)/\nreplace: userPassword\n$1/g'|ldapmodify
Now, if you only have simple binds working, then you would need to do it this way:
read -p 'Enter Root DN: ' ROOTDN read -s -p 'Enter Root DN Password: ' ROOTPW
ldapsearch -x -D "$ROOTDN" -w "$ROOTPW" -LLL "(&(userPassword=*)(! (pwdChangedTime=*)))" userPassword|perl -p0e 's/\n(userPassword:)/\nreplace: userPassword\n$1/g'|ldapmodify -x -D "$ROOTDN" -w "$ROOTPW"
However, if you don't yet know how to use ldapmodify and ldapsearch, you really should try and learn ...
Regards, Buchan
openldap-technical@openldap.org
-
Buchan Milne -
Chris Jacobs