[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Not getting password expiry warnings on login



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.