expireAgeUnix not compatible with Windows 64bit servers about adpassmon

[pmbuko]

Thanks for letting me know. I'm looking into how to break the number out into its two 32-bit components prior to converting it.

[pmbuko]

Francois, after some initial investigation, I think I've found a solution but I'll need some help testing it in multiple environments before rolling it out since it will be a much different (and simpler!) method of obtaining a password's expiration date. Does running the following command return a value for you?

dscl localhost read /Search/Users/$USER msDS-UserPasswordExpiryTimeComputed

If it does, divide that value by 10000000 and then subtract 11644473600. The resulting number should be the unix timestamp of your password's expiration.

This script should return the correct date and time for your password's expiration:

#!/bin/bash
expireDateWin=$(dscl localhost read /Search/Users/$USER msDS-UserPasswordExpiryTimeComputed 2>/dev/null | awk '/dsAttrTypeNative/{print $NF}')
expireDateUnix=$(echo "($expireDateWin/10000000)-11644473600" | bc)
date -r $expireDateUnix

[ftiff]

Peter, thanks for your investigation. I agree it is much, much simpler than your original design, while seeming more solid. It looks like it's working well, as you can see below (note the "No such key" error) :

admins-macbook:~ levaufr1$ dscl localhost read /Search/Users/levaufr1 msDS-UserPasswordExpiryTimeComputed
No such key: msDS-UserPasswordExpiryTimeComputed
dsAttrTypeNative:msDS-UserPasswordExpiryTimeComputed: 130860089140437712
admins-macbook:~ levaufr1$ bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
130860089140437712/10000000-11644473600
1441535314
quit
admins-macbook:~ levaufr1$ date -r 1441535314
Sun Sep  6 12:28:34 CEST 2015
admins-macbook:~ levaufr1$ 

Same using your script:

admins-macbook:~ levaufr1$ expireDateWin=$(dscl localhost read /Search/Users/$USER msDS-UserPasswordExpiryTimeComputed 2>/dev/null | awk '/dsAttrTypeNative/{print $NF}')
expireDateUnix=$(echo "($expireDateWin/10000000)-11644473600" | bc)
date -r $expireDateUnix
admins-macbook:~ levaufr1$ expireDateUnix=$(echo "($expireDateWin/10000000)-11644473600" | bc)
admins-macbook:~ levaufr1$ date -r $expireDateUnix
Sun Sep  6 12:28:34 CEST 2015
admins-macbook:~ levaufr1$

I'm curious, where did you get this idea ?

[pmbuko]

I found that since Win2k8, when MS introduced fine-grained password policy (FGPP), they also introduced the key that holds the value for when the password expires so it wouldn't have to be calculated. Before FGPP, it was simple to calculate: pwdLastSet +maxPwdAge and convert the result to date/time, but FGPP makes it more complex.

Using this new key also avoids the 64-bit integer conversion problem.

-- Peter (from phone)

On Jul 3, 2015, at 1:35 AM, Francois Levaux-Tiffreau [email protected] wrote:

Peter, thanks for your investigation. I agree it is much, much simpler than your original design, while seeming more solid. It looks like it's working well, as you can see below (note the "No such key" error) :

admins-macbook:~ levaufr1$ dscl localhost read /Search/Users/levaufr1 msDS-UserPasswordExpiryTimeComputed
No such key: msDS-UserPasswordExpiryTimeComputed
dsAttrTypeNative:msDS-UserPasswordExpiryTimeComputed: 130860089140437712
admins-macbook:~ levaufr1$ bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
130860089140437712/10000000-11644473600
1441535314
quit
admins-macbook:~ levaufr1$ date -r 1441535314
Sun Sep 6 12:28:34 CEST 2015
admins-macbook:~ levaufr1$
Same using your script:

admins-macbook:~ levaufr1$ expireDateWin=$(dscl localhost read /Search/Users/$USER msDS-UserPasswordExpiryTimeComputed 2>/dev/null | awk '/dsAttrTypeNative/{print $NF}')
expireDateUnix=$(echo "($expireDateWin/10000000)-11644473600" | bc)
date -r $expireDateUnix
admins-macbook:~ levaufr1$ expireDateUnix=$(echo "($expireDateWin/10000000)-11644473600" | bc)
admins-macbook:~ levaufr1$ date -r $expireDateUnix
Sun Sep 6 12:28:34 CEST 2015
admins-macbook:~ levaufr1$
I'm curious, where did you get this idea ?

—
Reply to this email directly or view it on GitHub.

[pmbuko]

I think what I'll do is add another configuration method, say Auto 2, to the settings instead of completely replacing my current method. I did some polling among my peers and this new method didn't work for everyone.

-- Peter (from phone)

On Jul 3, 2015, at 1:35 AM, Francois Levaux-Tiffreau [email protected] wrote:

Peter, thanks for your investigation. I agree it is much, much simpler than your original design, while seeming more solid. It looks like it's working well, as you can see below (note the "No such key" error) :

admins-macbook:~ levaufr1$ dscl localhost read /Search/Users/levaufr1 msDS-UserPasswordExpiryTimeComputed
No such key: msDS-UserPasswordExpiryTimeComputed
dsAttrTypeNative:msDS-UserPasswordExpiryTimeComputed: 130860089140437712
admins-macbook:~ levaufr1$ bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
130860089140437712/10000000-11644473600
1441535314
quit
admins-macbook:~ levaufr1$ date -r 1441535314
Sun Sep 6 12:28:34 CEST 2015
admins-macbook:~ levaufr1$
Same using your script:

admins-macbook:~ levaufr1$ expireDateWin=$(dscl localhost read /Search/Users/$USER msDS-UserPasswordExpiryTimeComputed 2>/dev/null | awk '/dsAttrTypeNative/{print $NF}')
expireDateUnix=$(echo "($expireDateWin/10000000)-11644473600" | bc)
date -r $expireDateUnix
admins-macbook:~ levaufr1$ expireDateUnix=$(echo "($expireDateWin/10000000)-11644473600" | bc)
admins-macbook:~ levaufr1$ date -r $expireDateUnix
Sun Sep 6 12:28:34 CEST 2015
admins-macbook:~ levaufr1$
I'm curious, where did you get this idea ?

—
Reply to this email directly or view it on GitHub.

[ftiff]

Thanks pmbuko. Could it be used when first method returns a large negative integer ?

[pmbuko]

That's a good idea. I'll work on integrating it this way. I suppose any negative integer returned as an expiration date could be assumed incorrect.

On Jul 6, 2015, at 2:29 AM, Francois Levaux-Tiffreau [email protected] wrote:

Thanks pmbuko. Could it be used when first method returns a large negative integer ?

—
Reply to this email directly or view it on GitHub #8 (comment).

[pmbuko]

Please try this pre-release and let me know if it resolves the issue for you.

[ftiff]

It works !

[ftiff]

In fact it behaves a bit weird.
Using 10.11 Beta (15A216g)

When waking up from sleep it switches back to the old way of working:

Then after a while it comes back:

10.07.15 13:39:53.995 ADPassMon[1714]: Starting auto process…
10.07.15 13:39:53.996 ADPassMon[1714]:   Found expireDateUnix in plist: 1441535314
10.07.15 13:39:54.074 ADPassMon[1714]:   Using alt method
10.07.15 13:39:54.171 ADPassMon[1714]:   New pwdSetDate (16594.44)
10.07.15 13:39:54.172 ADPassMon[1714]:   ≥ plist value (1.659444E+4) so we use it
10.07.15 13:39:54.188 ADPassMon[1714]:   daysUntilExp: -32.04604
10.07.15 13:39:54.188 ADPassMon[1714]:   daysUntilExpNice: -32
10.07.15 13:39:54.189 ADPassMon[1714]:   expirationDate: lundi, 8 juin 2015 12:33:36
10.07.15 13:42:08.804 ADPassMon[1714]: Testing for Kerberos ticket presence…
10.07.15 13:42:08.972 ADPassMon[1714]:   Ticket found and renewed
10.07.15 13:42:09.070 ADPassMon[1714]: Starting auto process…
10.07.15 13:42:09.071 ADPassMon[1714]:   Found expireDateUnix in plist: 1.441535314E+9
10.07.15 13:42:09.179 ADPassMon[1714]:   Got expireDateUnix: 1441535314
10.07.15 13:42:09.180 ADPassMon[1714]:   Using msDS method
10.07.15 13:42:09.207 ADPassMon[1714]:     daysUntilExp: 57.948900462963
10.07.15 13:42:09.208 ADPassMon[1714]:     daysUntilExpNice: 57

[pmbuko]

Ah, thanks for letting me know. I think I'll add an item to the preferences that tells it to only use the new method if it's able to find the computed expiration date value.

Peter

On Jul 10, 2015, at 7:45 AM, Francois Levaux-Tiffreau [email protected] wrote:

In fact it behaves a bit weird.
Using 10.11 Beta (15A216g)

When waking up from sleep it switches back to the old way of working:

Then after a while it comes back:

10.07.15 13:39:53.995 ADPassMon[1714]: Starting auto process…
10.07.15 13:39:53.996 ADPassMon[1714]: Found expireDateUnix in plist: 1441535314
10.07.15 13:39:54.074 ADPassMon[1714]: Using alt method
10.07.15 13:39:54.171 ADPassMon[1714]: New pwdSetDate (16594.44)
10.07.15 13:39:54.172 ADPassMon[1714]: ≥ plist value (1.659444E+4) so we use it
10.07.15 13:39:54.188 ADPassMon[1714]: daysUntilExp: -32.04604
10.07.15 13:39:54.188 ADPassMon[1714]: daysUntilExpNice: -32
10.07.15 13:39:54.189 ADPassMon[1714]: expirationDate: lundi, 8 juin 2015 12:33:36
10.07.15 13:42:08.804 ADPassMon[1714]: Testing for Kerberos ticket presence…
10.07.15 13:42:08.972 ADPassMon[1714]: Ticket found and renewed
10.07.15 13:42:09.070 ADPassMon[1714]: Starting auto process…
10.07.15 13:42:09.071 ADPassMon[1714]: Found expireDateUnix in plist: 1.441535314E+9
10.07.15 13:42:09.179 ADPassMon[1714]: Got expireDateUnix: 1441535314
10.07.15 13:42:09.180 ADPassMon[1714]: Using msDS method
10.07.15 13:42:09.207 ADPassMon[1714]: daysUntilExp: 57.948900462963
10.07.15 13:42:09.208 ADPassMon[1714]: daysUntilExpNice: 57
—
Reply to this email directly or view it on GitHub.

[pmbuko]

Ok. Please try v1.11.0-b2

[ftiff]

This one looks good !

[pmbuko]

Closed with v1.11.0-final