Yup, that's exactly what I meant. Speaking of "account control" flags, AD does have something similar where there exists a userAccountControl attribute that is compromised of bitwise-flags indicating the account state. (I suspect ldaptive does a pretty good job at parsing and recognizing such flags). Not too familiar with RHDS, but if there exists such a thing and documentation on how the flags are paired up and what they are, consuming and processing those might even be "safer" compared to trusting the password expiration date.
-Misagh > -----Original Message----- > From: Marvin Addison [mailto:[email protected]] > Sent: Friday, January 11, 2013 9:23 AM > To: [email protected] > Subject: Re: [cas-user] catch result: 2.16.840.1.113730.3.4.4 from RHDS > > > Looks like the expiration date is java's epoch. > > The epoch value here is notable; it's the epoch start date. Maybe > that's what you mean by "epoch" instead of the storage format more > generally. I would imagine this is a directory-specific implementation > detail that possibly provides another route into the "must change > password" state instead of reading the response control directly. > > > You could, as a possible > > solution, modify your local ldap policy enforcer component to check > > for epoch and rethrow back the exception with the correct type. > > This sounds like it should work provided that the > passwordexpirationdate attribute is always set to the epoch start date > for the "must change password" state, which seems like a safe > assumption. Good suggestion! > > M > > -- > You are currently subscribed to [email protected] as: > [email protected] To unsubscribe, change settings or access archives, > see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
