Unable to change password for AD user with expired password

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Configure PWM to authenticate against AD user store
2. Modify domain password policy to set passwords to expire in 1 day (minimum)
3. Create test account in AD, wait 24 hours and attempt to change password - 
this will fail with message "The username or password is not valid. Please try 
again."
4. Create additional test account in AD, this should still have a valid 
(unexpired password as it was newly created) - attempt to change the password 
for this user and it should succeed.

What is the expected output? What do you see instead?
Expected - successful password change
Result - The username or password is not valid. Please try again.

What version of the product are you using? On what operating system?

Tested with pwm 1.5.2 and 1.5.1 

Tomcat Version  Apache Tomcat/6.0.20
JVM Version     1.6.0_22-b04
JVM Vendor  Sun Microsystems Inc.
OS Name     Windows 2003
OS Architecture x86

Please provide any additional information below.

I suspect that the problem may be in the underlying LDAP Chai code or not. 
There appears to be no checking of the sub-error code, both incorrect password 
and password expired produce the same result.

    * 525 - user not found
    * 52e - invalid credentials
    * 530 - not permitted to logon at this time
    * 532 - password expired
    * 533 - account disabled
    * 701 - account expired
    * 773 - user must reset password

See attached excerpt of a PWM trace, one login is deliberately mistyping 
password, the other is with the correct but expired password.

Original issue reported on code.google.com by oner...@gmail.com on 12 Nov 2010 at 12:16

Attachments:

• AuthFailure.txt

[GoogleCodeExporter]

Original comment by jrivard on 16 Nov 2010 at 5:30

• Changed state: Accepted

[GoogleCodeExporter]

The problem here is that PWM is unable to bind as the user.  PWM is built to 
always bind as the user for security reasons.  Since the bind fails, the user 
is considered unauthenticated.

So it appears that in AD, once the password is expired, an ldap bind is 
impossible.  This isn't the case with other directories (such as eDirectory).

I guess we'll have to take a look at supporting a proxy user model for 
authentication for AD instead of a direct bind as the user if we support for 
authentication with an expired password is really a good idea.

Original comment by jrivard on 17 Nov 2010 at 1:14

[GoogleCodeExporter]

Any progress on this additional feature? I wrote a php app strictly for 
resetting AD passwords and in the code I watch for the return code of 773, 532, 
and 533. If 773 or 532 is returned the administrator has the option of 
specifying an account with privs to reset AD passwords and that account is used 
for the ldap bind to reset the user's password. Since these return codes are 
only returned if the user enters the correct expired password we consider this 
to be a valid auth for the purpose of the reset and proceed to use the higher 
priv account to allow the user's new password to be set.

If the return is 533 we print a message to contact our IT dept for help. 
Anyways, with this feature added we will use PWM for it's additional 
functionality of registering guests, as you type verification, etc. Thanks!

Original comment by dra...@gmail.com on 22 Sep 2011 at 12:46

[GoogleCodeExporter]

dra...@gmail.com,

Mind sharing the php app along with any details?

Thanks,

Philip

Original comment by ptong...@gmail.com on 3 Nov 2011 at 8:35

[GoogleCodeExporter]

If I'm reading this defect correctly, that's the issue I'm having with using AD 
to create a new user and setting the must change password flag.  If I turn 
"must change password" off on the account, the user can get in.

LDAP error coming back: [LDAP: error code 49 - 80090308: LdapErr: 
DSID-0C0903A9, comment: AcceptSecurityContext error, data 773, v1db0]

Original comment by KennethP...@gmail.com on 17 Nov 2011 at 3:55

[GoogleCodeExporter]

Basically any condition that makes an bind fail will cause PWM to be unable to 
login.  An enhancement to solve this would capture that failure and use the 
authWithUnknownPassword() to login to pwm.

Original comment by jrivard on 17 Nov 2011 at 4:16

[GoogleCodeExporter]

Are there plans to fix this in the near future?  We are planning a rollout at 
our site by August and need this feature.  We may attempt a patch ourselves but 
wanted to verify nothing was already in the works before we put effort into it.

Original comment by jason.al...@gmail.com on 14 Mar 2012 at 2:09

[GoogleCodeExporter]

Can you point out where to modify the code and use the authWithUknownPassword? 
I also require this feature since Billware won't let you do a bind with an 
expired user account. I don't want to always use an administrator credentials 
to change all passwords. Thanks.

Original comment by sid.mcla...@gmail.com on 3 Apr 2012 at 1:15

[GoogleCodeExporter]

Is there already a fix, need this too

Original comment by gschoute...@gmail.com on 15 Jan 2013 at 4:00

[GoogleCodeExporter]

If I read the admin guide, it looks like that this funcionality should work:
Check Expiration During Authentication (page 32)

Is it?

Original comment by gschoute...@gmail.com on 17 Jan 2013 at 4:07

[GoogleCodeExporter]

We're seeing this happen with 389 directory server as well; interestingly, an 
anonymous bind shows:

passwordExpirationTime: 19700101000000Z

but the bind via the user in pwm just fails, so perhaps Check Expiration During 
Authentication needs to happen anonymously first, and then attempt a password 
reset as that particular user, just as ldappasswd appears to do?

Original comment by and...@scalefactory.com on 30 Jan 2013 at 4:22

[GoogleCodeExporter]

@11: First of all I wonder why you would want someone whose password expired 
more than 43 years ago to login. 

Apart from that, this is an issue related to AD, not 
389DS/Sun/iPlanet/Netscape/Fedora family directory servers. Those behave 
differently. Please see 
http://www.centos.org/docs/5/html/CDS/ag/8.0/User_Account_Management-Managing_th
e_Password_Policy.html#Configuring_the_Password_Policy-Configuring_a_Global_Pass
word_Policy_Using_the_Command_Line for instructions on how to set a grace limit 
to allow login with an expired password.

- Menno

Original comment by menno.pi...@gmail.com on 30 Jan 2013 at 7:35

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thanks for your reply, and the info; yes, I think this is probably not the same 
issue, and will log another issue to address what we're experiencing. 

Further to your suggestion, Menno, we already have passwordGraceLimit set to 3 
in our password policy, and still pwm won't allow a user to login. I think the 
issue is that pwm is not detecting that passwordMustChange is on, and that 
users that login once the rootdn has reset their password, should go through a 
forced password change.
This is usually achieved through an extended password operation when using any 
of the linux ldap-utils

As far as the passwordExpirationTime is concerned, that's how dirsrv sets that 
entry when passwordMustChange is set to 'on': it sets it to the Unix Epoch.

thanks,
Andrew

Original comment by and...@scalefactory.com on 31 Jan 2013 at 7:59

[GoogleCodeExporter]

We made a patch which fixes this issue in AD and have been running successfully 
for several months now.  Attached patch is against 1.6.3.  

Original comment by jason.al...@gmail.com on 31 Jan 2013 at 7:49

Attachments:

• 0001-Fix-Issue-23.patch

[GoogleCodeExporter]

Thanks very much, Jason; I'll see if we can implement that as well, and report 
back.

Original comment by and...@scalefactory.com on 1 Feb 2013 at 2:19

[GoogleCodeExporter]

It won't help you if you're not running AD.  But for AD sites, it's difficult 
to get along without it.

Original comment by jason.al...@gmail.com on 1 Feb 2013 at 2:40

[GoogleCodeExporter]

Thank you for clarifying that - that's going to save us some unnecessary time 
wasting.  I've created an additional issue to address the problem we've 
experienced with 389 dirsrv - #327

Original comment by and...@scalefactory.com on 1 Feb 2013 at 2:55

[GoogleCodeExporter]

This issue has been addressed in the latest SVN revision and will be available 
in the next PWM nightly build.  Thanks to all that contributed suggestions and 
code to the issue.  A configuration option in "Active Directory --> Allow 
authentication when "must change password on next login" is set must be set to 
true. 

Original comment by jrivard on 4 Feb 2013 at 3:26

• Changed state: Fixed

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hello There, 

I commented earlier asking how to apply this patch. I deleted the comment 
because I figure it out. I edited each file listed manually. After I did it, I 
compile it following the instructions on the PWMAdministrationGuide. I backup 
my settings downloading the xml file. I deleted the original pwm folder and 
pwm.war. I deployed the new pwm.war with modifications and It works great. 

Thank you all for your comments and such a great software.   

Original comment by josel.mo...@macaulay.cuny.edu on 13 Jun 2013 at 2:26