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

RE: Expired password allowed in via pwdGraceAuthNLimit w/o warning to user


Thanks for the information.....please see my responses inserted below.


-----Original Message-----
From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net] 
Sent: Monday, July 05, 2010 4:56 AM
To: openldap-technical@openldap.org
Cc: Licause, Al
Subject: Re: Expired password allowed in via pwdGraceAuthNLimit w/o warning to user

>>I did not reply to your off-list mails, primarily because I was out of the office 
>>(at a data centre) all of Friday, and without internet access over the 
>>weekend. You could have sent those replies to your original thread to the list 

No problem.   You were correct in stating that I posted to the wrong discussion
and I therefore should have expected no further discussion.

On Friday, 2 July 2010 20:09:15 Licause, Al wrote:
> I have installed and configured the ppolicy overlay software on a Red Hat
>  V5.4 server along with the openldap server software and the following
>  components:
> openldap-servers-2.3.43-3.el5
> python-ldap-2.2.0-2.1
> openldap-devel-2.3.43-3.el5
> checkpassword-ldap-0.01-1.2.el5.rf
> mozldap-6.0.5-1.el5
> openldap-2.3.43-3.el5
> openldap-debuginfo-2.3.43-3.el5
> openldap-servers-overlays-2.3.43-3.el5
> nss_ldap-253-22.el5_4
> openldap-clients-2.3.43-3.el5
> I have notice that when an ldap users' password expires, and
>  pwdGraceAuthNLimit is set to a non-zero value...in my case it is set to 1
>  for testing purposes,  the user is allowed to login one time.   The next
>  login forces a password change.
> On the first login, allowed via pwdGraceAuthNLimit, there is no
>  announcement sent to the user telling them that the password has expired. 

>>You should actually get a prompt to change your password immediately.

I'm not seeing that.   If the number of permitted logins specified by pwdGraceAuthNLimit
has not counted an equal number of attempted logins, the login is allowed with
no warnings.    When the number of attempts to login finally exceeds pwdGraceAuthNLimit,
then and only then is the user prompted to change the password.

>>BTW, if your PAM setup was correct, you should have seen warnings about expiry 
>>before this.

>>Did you bother testing with a guaranteed-to-work tool, such as (with 
>>appropriate values to -D option) 'ldapwhoami -e ppolicy' ?

I hadn't but having done so at your suggestion, and using -x since I am not using sasl,
it yields the following:

$ ldapwhoami -x ppolicy
Result: Success (0)

Pardon my ignorance, but I'm not sure of the significance of this test and what it would
have shown with regard to the pwdGraceAuthNLimit warnings.

>  Nor that they will have to change their password on the next login.     I
>  have to wonder if there is also a missing announcement that might tell the
>  user how many more logins they are permitted given the value of
>  pwdGraceAuthNLimit
>  It was suggested that the problem may be in the pam configuration.
> I am using the following /etc/pam.d/system-auth file that is autogenerated
>  by authconfig:
> #%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

>>This should be pam_deny.so, but is likely not the cause of your problems.

I tried changing this entry to pam_deny.so and while it didn't force a
warning to be printed, it also simply denied access to the user as it should have.

> password    requisite     pam_cracklib.so try_first_pass retry=3
> password    sufficient    pam_unix.so md5 shadow nis 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
> I am testing by logging into the client with ssh.   I also have many of the
>  pwd* values set fairly low for quick testing.   This is the default policy
>  in use:
> dn: cn=Standard,ou=Policies,dc=mydomain,dc=com
> objectClass: top
> objectClass: device
> objectClass: pwdPolicy
> cn: Standard
> pwdAttribute: userPassword
> pwdLockoutDuration: 15
> pwdInHistory: 6
> pwdCheckQuality: 0
> pwdMinLength: 5
> pwdAllowUserChange: TRUE
> pwdMustChange: TRUE
> pwdMaxFailure: 3
> pwdFailureCountInterval: 120
> pwdSafeModify: FALSE
> pwdLockout: TRUE
> pwdReset: TRUE
> structuralObjectClass: device
> entryUUID: 421d8558-1a33-102f-8b9e-a5541f2aaf30
> creatorsName: cn=Manager,dc=mydomain,dc=com
> createTimestamp: 20100702143843Z
> pwdMinAge: 0
> pwdMaxAge: 300
> pwdGraceAuthNLimit: 1
> pwdExpireWarning: 86400
> entryCSN: 20100702154010Z#000000#00#000000
> modifiersName: cn=Manager,dc=mydomain,dc=com
> modifyTimestamp: 20100702154010Z
> This is the test users profile:
> dn: uid=ldap1,dc=mydomain,dc=com
> uid: ldap1
> cn: ldap1
> objectClass: account
> objectClass: posixAccount
> objectClass: top
> uidNumber: 10001
> gidNumber: 150
> homeDirectory: /home/ldap1
> loginShell: /bin/csh
> gecos: ldap test user
> pwdPolicySubentry: cn=Standard,ou=Policies,dc=mydomain,dc=com
> structuralObjectClass: account
> entryUUID: 334312be-1a33-102f-8a83-a5541f2aaf30
> creatorsName: cn=Manager,dc=mydomain,dc=com
> createTimestamp: 20100702143818Z
> pwdHistory:
>  20100702151010Z#{SSHA}BIxGPXPqBY+
>  2yK6pY2i+6l7UbE/gaVhY
> pwdHistory:
>  20100702154253Z#{SSHA}q4inOFGO+0N
>  c6T0q6FYiiMrPCTTUqQdr
> pwdHistory:
>  20100702183229Z#{SSHA}3T0Cna8AGIg
>  X69V7zsDxGiTx/q0ceBnc
> userPassword:: e1NTSEF9WkZ0ekJrUWVOQVJrMDhFbDJXd0VNaU1maWlGVURaT28=
> pwdChangedTime: 20100702183229Z
> pwdGraceUseTime: 20100702184519Z
> entryCSN: 20100702184519Z#000000#00#000000
> modifiersName: cn=Manager,dc=mydomain,dc=com
> modifyTimestamp: 20100702184519Z
> I have examined various log files and enabled debugging in system-auth (now
>  removed to show the standard autogenerated content) for any clues.  I have
>  examined various pam modules and library files with strings to see if I
>  could get an idea as to which module may be at fault.
> I have to admit I am no pam expert and given the number of combinations and
>  variations possible in the system-auth file alone, I don't feel
>  comfortable modifying this file to any great extent.
> I have omitted the slapd.conf and client ldap.conf files assuming that they
>  are not at fault and don't have any obvious omissions which could cause a
>  warning messages to be suppressed during login, but can supply them if
>  required.

>>You need to supply the pam_ldap ldap.conf (/etc/ldap.conf on RH), specifically 
>>verify whether 'pam_lookup_policy' is set to 'yes'. Please see 'man pam_ldap'.

These are the uncommented lines from my /etcldap.conf file:

base dc=osn,dc=cxo,dc=cpqcorp,dc=net

binddn cn=Manager,dc=osn,dc=cxo,dc=cpqcorp,dc=net
rootpw          {SSHA}RHVddPmANdnsYDuMzFlM/D4D7aAH1yYG

rootbinddn cn=Manager,dc=osn,dc=cxo,dc=cpqcorp,dc=net

nss_base_group dc=osn,dc=cxo,dc=cpqcorp,dc=net?one?&(objectCategory=group)(gidnumber=*)


pam_lookup_policy yes
ppolicy_default "cn=Standard,ou=Policies,dc=osn,dc=cxo,dc=cpqcorp,dc=net"

ssl no

nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,ntp,smmsp,xfs

pam_password exop

bind_policy soft

> If the default system-auth file generated by the authconfig utility defeats
>  a feature of the ldap or other system modules,

>>It doesn't "defeat" a feature, but the feature does need to be specifically 

That's the key then......how do we specifically enable this feature ?

>  we need to report this to
>  Red Hat and have the problem corrected.

>>Of course, then this entire discussion is more or less off-topic here ...

Not sure why ?