pmbuko / adpassmon Goto Github PK

10.10.4 (14E46)
In preferences, if user changes the manual field and then click on "Apply changes", it reverts to Auto.
User needs to first do "TAB" after inputing value, then click on "Apply changes".

Menu item is not loading despite ADPassMon running in Activity Monitor, behavior seen on both v1.11.0 and v1.11.0-b2 on OS 10.10.4. Issue does not present in v1.10.3

7/13/15 2:19:38.413 PM ADPassMon[28707]: Running on OS 10.10.x
7/13/15 2:19:38.413 PM ADPassMon[28707]: Testing Universal Access settings…
7/13/15 2:19:38.420 PM ADPassMon[28707]: *** -[ADPassMonAppDelegate applicationWillFinishLaunching:]: Can’t make «class ocid» id «data optr000000004574727565000000» into type integer. (error -1700)

The method used to determine the value for myLDAP assumes that the DNS server used is also an LDAP server. In our environment (which I admit is not ideal), DNS and AD/LDAP are separate. So ADpassMon is trying to do an ldapsearch to a DNS server. This DNS sever does contain SRV records, so perhaps finding a DC address with an SRV lookup would be more accurate?

When I run ADpassMon, there is a long delay (about 3 minutes) before the menu can be clicked. And any time I make a pref change, there is also a long delay. Also, when I try to set a manual password age discovery, it reverts back to Auto (even if configured from a profile or defaults write).

If I modify ADPassMonAppDelgate.applescript so that myLDAP is set to a known LDAP IP, the delay goes away and I can manually set the password age discovery.

However, my menu_title is set to -287d.

defaults read org.pmbuko.ADPassMon
{
expireAge = 365;
isBehaviour2Enabled = 1;
"menu_title" = "[-287d]";
pwdSetDate = "15944.56";
selectedBehaviour = 2;
selectedMethod = 1;
tooltip = "Password expires on Wednesday, August 27, 2014 at 9:26:25 AM";
warningDays = 14;
}

I'm not sure if its' inability to generate the correct expiration is site specific. We do not allow AD password changes, instead use a website to handle password changes. So I'm not sure if there's an attribute missing from our AD to get his to work. However, the date in the tooltip above does correctly show when this account last changed their password. So would think adding 365 days to that should give the correct value?

Jun 10 16:03:26 COL-PGALLA2-01a ADPassMon[65367]: selectedMethod: 365
Jun 10 16:03:26 COL-PGALLA2-01a ADPassMon[65367]: Starting manual process…
Jun 10 16:03:26 COL-PGALLA2-01a ADPassMon[65367]: Found expireAge in plist: 365
Jun 10 16:03:26 COL-PGALLA2-01a ADPassMon[65367]: New pwdSetDate (15944.56)
Jun 10 16:03:26 COL-PGALLA2-01a ADPassMon[65367]: ≥ plist value (1.594456E+4) so we use it
Jun 10 16:03:26 COL-PGALLA2-01a ADPassMon[65367]: daysUntilExp: -287.2757
Jun 10 16:03:26 COL-PGALLA2-01a ADPassMon[65367]: daysUntilExpNice: -287
Jun 10 16:03:26 COL-PGALLA2-01a ADPassMon[65367]: expirationDate: Wednesday, August 27, 2014 at 9:26:26 AM
Jun 10 16:03:26 COL-PGALLA2-01a ADPassMon[65367]: Behaviour 2 enabled...
Jun 10 16:03:26 COL-PGALLA2-01a ADPassMon[65367]: Skipping Keychain Lock state check...
Domain (org.pmbuko.ADPassMon) not found.
Jun 10 16:03:28 COL-PGALLA2-01a ADPassMon[65367]: *** -[ADPassMonAppDelegate revertDefaults:]: 2015-06-10 16:03:28.774 defaults[78609:1501747]
Domain (org.pmbuko.ADPassMon) not found.
Jun 10 16:03:31 COL-PGALLA2-01a ADPassMon[65367]: selectedMethod: 365
Jun 10 16:03:31 COL-PGALLA2-01a ADPassMon[65367]: Starting manual process…
Jun 10 16:03:31 COL-PGALLA2-01a ADPassMon[65367]: Found expireAge in plist: 365
Jun 10 16:03:31 COL-PGALLA2-01a ADPassMon[65367]: New pwdSetDate (15944.56)
Jun 10 16:03:31 COL-PGALLA2-01a ADPassMon[65367]: will be saved to plist.
Jun 10 16:03:31 COL-PGALLA2-01a ADPassMon[65367]: daysUntilExp: -287.2758
Jun 10 16:03:31 COL-PGALLA2-01a ADPassMon[65367]: daysUntilExpNice: -287
Jun 10 16:03:31 COL-PGALLA2-01a ADPassMon[65367]: expirationDate: Wednesday, August 27, 2014 at 9:26:22 AM
Jun 10 16:03:31 COL-PGALLA2-01a ADPassMon[65367]: Behaviour 2 enabled...
Jun 10 16:03:31 COL-PGALLA2-01a ADPassMon[65367]: Skipping Keychain Lock state check...
Jun 10 16:03:37 COL-PGALLA2-01a ADPassMon[65367]: Starting manual process…
Jun 10 16:03:37 COL-PGALLA2-01a ADPassMon[65367]: Found expireAge in plist: 365
Jun 10 16:03:37 COL-PGALLA2-01a ADPassMon[65367]: New pwdSetDate (15944.56)
Jun 10 16:03:37 COL-PGALLA2-01a ADPassMon[65367]: ≥ plist value (1.594456E+4) so we use it
Jun 10 16:03:37 COL-PGALLA2-01a ADPassMon[65367]: daysUntilExp: -287.2758
Jun 10 16:03:37 COL-PGALLA2-01a ADPassMon[65367]: daysUntilExpNice: -287
Jun 10 16:03:37 COL-PGALLA2-01a ADPassMon[65367]: expirationDate: Wednesday, August 27, 2014 at 9:26:28 AM
Jun 10 16:03:37 COL-PGALLA2-01a ADPassMon[65367]: Behaviour 2 enabled...
Jun 10 16:03:37 COL-PGALLA2-01a ADPassMon[65367]: Skipping Keychain Lock state check...

Testing with an AD account that is set to not expire. In this scenario, ADPassMon notifies via Notification Center whenever the daemon is running a check. In the case of a password set to not expire, it should not notify this regularly, or at all.

I'm accessing domain resources over VPN from a local user account that isn't domain-associated (yet) and doesn't have the same username as my AD user. (Recently joined a company, this is the interim setup.)

ADPassMon doesn't offer to set a username. But it does offer to refresh a kerberos ticket, and when I do so and enter my password, it comes up with an expiration time in the year when Hamlet is believed to have been first performed, and a password expiry timeout of -151180 days.

https://github.com/pmbuko/ADPassMon/blob/master/ADPassMon/ADPassMonAppDelegate.applescript#L410

on Windows 64 bit servers, this returns a large negative value: -36288000000000 (for 90 days)
ADPassMon incorrectly reports this as 42 days.

Here's some background :
http://www.pcreview.co.uk/threads/what-is-value-for-maxpwdage-in-ad-weird-value-in-one-of-ours.3490176/