I am having an issue in regards to handling expiring passwords during the grace period. I also filed a bug because I find the behavior to not be as expected (https://bugzilla.redhat.com/show_bug.cgi?id=576303). But to summarize my bug report, in my code that checks a user's credentials (username / password) I ask the server for the response controls (using Java/JNDI). When the user's pass hasn't expired yet but they are in the warning period, in the response I receive 2.16.840.1.113730.3.4.5 indicating the password is expiring, which works great. Then when their password actually expires and they still haven't changed it yet (Glass half full, they just haven't logged in during that time and didn't ignore my warnings) and I have say 3 grace logins allows in the policy the server doesn't respond with the warning (2.16.840.1.113730.3.4.5) or the password expired response control (2.16.840.1.113730.3.4.4). The only way I can determine during the grace period that the password is actually expired and I'm on my grace login seems to be by checking the passwordExpiredTime attribute by hand. This just seems silly to me since the server knows the password expired and it knows to increment the passwordGraceUserTime attribute for each successful login after the password expired. I would think the server would respond with both 2.16.840.1.113730.3.4.5 and 2.16.840.1.113730.3.4.4 like it does when your password is reset by the administrator. Am I missing something? Anyone else have a cleaner way of determining that it's a grace period login? By the way, for the record I'm accessing this in Java, not sure it matters and here's a little code blurb: LdapContext ctx = new InitialLdapContext(env, nul); Control[] ctls = ctx.getResponseControls(); if(ctls != null) { for(Control control : ctls) { System.out.println(control.getID()); } } Also if this question should be on the devel list I apologize but I figured that was for actually coding the 389 directory server. Thanks, Aaron Hagopian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20100323/4fe885c0/attachment.html
