macmule / adpassmon Goto Github PK

Hi.. I'm new to github.. so I may not be doing this right!?
I installed ADPassMon. .and I love it... but the "Assistive Access" popup prompting for my Password.. is happening at EVERY login. Is that normal ? (note:.. I had to set to "Manual" to fix the "10million days" problem).

ADPassMon 2.20.19 launches only once per user on multiple machines. First launch is all okay, the second launch produces the following error in console:

05.04.16 13:18:44,455 ADPassMon[13480]: *** -[ADPassMonAppDelegate applicationWillFinishLaunching:]: Can’t make «class ocid» id «data optr00000000904D70F1EF7F0000» into type integer. (error -1700)

As a (relatively) new user, I wanted to find the documentation. I looked in About ADPassMon… and saw this:
Documentation:
    http://yourmacguy.wordpress.com

I clicked the link and it took me here: http://yourmacguy.wordpress.com/ADPassMon/

On that page I found a link to this page: https://github.com/macmule/ADPassMon/wiki

Shouldn't the link in the about box go to the documentation page on GitHub?

This isn't really an issue with ADPassMon but it is closely related to it.

So my 10.10.5 Mac has a fine grained password policy. When I login I’m getting warned by the OS that my password expires in 10 days (and I should change it) which isn’t correct. ADPassMon reports 65 days which is correct. Yeah for ADPassMod for respecting the policy! Is it a known issue that the Mac doesn't respect a fine grained password policy from AD? How is the Mac calculating the password expiry? Any thoughts or known workarounds for turning off the OS warnings or fine tuning the settings?

Thanks for merging the forks!

More often than not when returning a Mac from Sleep the date remaining until pwd reset will be negative. If you refresh the ticket or wait until the tool does it own interval check it displays the correct count down. Any ideas how to remedy this?

was asked by macmule to log this. I was having issues with ADPassMon not reporting the correct password expiry date even though i reset my password from AD. Turns out we were missing a reverse DNS entry for our time server and our macs were pointing their time server to it's IP address, because of this the DC wasn't contactable. Changing the time server to it's hostname fixed this issue. This also resolved issues with other user's and having to recreate tickets constantly.

I'm trying to use the application on a domain-joined iMac running OSX 10.9.5.
Logged on as a domain user (which is also an admin on the iMac) I've downloaded the latest version, put it in the Applications directory and launched it from there. It went through a first run configuration, and it installed itself in the menu bar as supposed to.
At this point I've logged off and logged on as a different user, also a domain user but without administration rights on the machine. The application did not show in the menu bar. The task monitor showed that the process was running. I tried to kill the process and start the app, but again there was no sign of it being active at all besides it being listed in the active tasks. I've tried to promote the user to admin, uninstall the app and install it again; I've tried to delete the plist preferences and reboot, the problem was not solved.
What is the correct procedure to install the app and configure it to run automatically for all the users?

It would be helpful to either grey out, or hide a preference in the Preferences window if the preference is enforced by Profiles or MCX.

Morning All,

I am struggling with an issue. I have setup our infrastructure so that Mac's are bound to the domain but have local accounts (with usernames the same as their AD usernames). This is working well, ADPassMon runs in the foreground one a kerberos ticket has been acquired (KerbMinder manages this) and displays password expiry etc. correctly. I believe this is the recommended way for ADPassMon to run with local accounts.

The problem I am having is that when changing a password via ADPassMon, either when its due to expire or at any time, it will return a success message and state password has been changed however it is not updating the AD password for the user.

Is there something I am missing here? ADPassMon preferences is set to allow password changes and to use ADPassMon to perform the changes.

All Mac's are running 10.11.4 at present.

Has anyone else run into this issue?

ADpassmon assists in fixing and extremely annoying problem where the local items keychain does not update sometimes when a user updates their password. Our passwords expire every 2 months so you can imagine how annoying that gets.

When the issue occurs for one of our users they will login, see the osx notification that the keychain cannot be unlocked, and then they usually end up saying "continue login" :[

Now, ADpassmon (i have set as a launchagent) launches and checks to see if the local items keychain unlocks, but the "your keychain is locked" dialogue appears under all of the "xxxxx wants to use the local items keychain" osx prompts. My users never make it to the ADpassmon box because it is not in the foreground.

Is there any way to suppress the OSX notifications or make ADpassmon appear before or in front of them? If the only box that came up was ADpassmon life would be so easy.

Thank you very much for the time and effort put into this. Apple and Microsoft should have this worked out between themselves but we all know thats not happening

We're not in an AD environment here (OD-only), but this tool looks like it might be the best way to fix the rampant locked-local-items-keychain thing for our users. The app doesn't appear to do anything on launch for me (under 10.11.3) — nothing shows up in the menubar, anyway. Does it not work at all if it doesn't detect an AD account?

If that's the case, is there any way to use the keychain-fixing part separately in this scenario?

Thanks!

I just used the change password function for the first time. The Old Password, New Password, and Verify Password fields were empty. I filled them out, and it worked as expected.

Immediately afterwards I tried to use it a second time, and the Old Password, New Password, and Verify Password fields were populated with bullets, when they should have been empty.

(I also noticed that the number of bullets equaled the number of characters in the passwords. This doesn't bother me, but it seems to be common practice in other systems to always show the same number of bullets, regardless of password length.)

Not sure if this is intended behaviour or not but the test for a network account will match a local account that has the same username as a user in AD. This means ADPassMon will run even in the runIfLocal preference is false when this happens.

As far as I understand it I think that ADPassMon should work like this

Network and Mobile accounts => Always run
Local account with AD counterpart => Only run if runIfLocal is true
Local only account => Never run

Cheers

Matt

Some environments use a LaunchAgent to keep ADPassMon running for all users (whether local or AD-based). We should check whether the logged-in account is a local user early in the loading process so we can break out of all the processes and not draw the menu item. There should be a hidden pref option that tells ADPassMon to continue loading anyway. I will use this option, and others may find it useful, as well.

via Slack channel:

" i can’t get ADpassMon to start up with an AD account. The log claims it is a local account, so adpassmon quits."

I asked him to run dscl localhost read /Search/Users/$USER AuthenticationAuthority and see if the output contains "Active Directory".

He has a non-mobile AD accout and the output was AuthenticationAuthority: ;Kerberosv5;;[email protected];ISB.LOCAL; ;NetLogon;kyle;ISB

We should consider changing line 161 to read:

if "NetLogon" is in accountLoc

My Preferences are set to Allow password changes, using ADPassMon."

A few minutes ago I used ADPassMon to change my password from Password1 to Password2. Since our AD policy restricts password changes to once every 24 hours, I decided to try to change it again to see how ADPassMon would handle it when our DC rejected the change.

In the Old Password field I entered Password2, and in New Password and Verify Password I entered Password3 and clicked Change. As expected, it failed. I saw this error: Password change failed. Please try again.

I clicked OK and then saw another dialog saying the change was successful.

Huh?

I closed the Change Password dialog, then tried to use Change Password… a 3ʳᵈ time, and got a message that my keychain was locked.

Huh?

Using Keychain Access I verified that it was indeed locked. And when I tried to manually unlock it, I discovered that I had to use Password3.

It took me a minute to figure out what happened. Even though the AD password change failed (my AD password remained Password2), ADPassMon nevertheless changed my login keychain password to Password3!

In other words, ADPassMon had created a situation in which my AD password was different from my login keychain password.

Avoiding exactly that problem is the main reason I want deploy ADPassMon.

When I try to change the value of the expiration check interval, the current NSTimer should terminate and a new one with the new interval should be started. Instead, I see the following error in Console:

9/14/15 9:50:50.962 AM ADPassMon[16589]: *** -[ADPassMonAppDelegate setValue:forUndefinedKey:], key "passwordCheckInterval": missing value doesn’t understand the “invalidate” message. (error -1708)

Hey,
I've been using your helpfull tool for some time now, but it seems to have a little problem.
About 50% of the time, the remaining days until I need to change my password are displayed in the negative, bot in the status bar and the adpassmon notifications.
I mean, it's still kinda correct....
It displays the remaining time as "-163 days", our passworld policy requires the password to be changed every 180 days, which means I have 17 days left, which is correct.

Is there some way to fix this? If I can provide you with any more information, I'll be happy to help.

I am using release 2.20.12 (127) on OS X 10.10.5.

the domain check triggers a process run every 5 minutes, regardless of the expiration check interval setting.

Pinched from AutoDMG & added to AutoCasperNBI, add to build phase:

Helps when testing & people are compiling own versions:

#
# Sets the version string to a monotonically increased string, based on
# the number of git commits.

set -o errexit
set -o nounset

VERSION=$(git --git-dir="$PROJECT_DIR/.git" --work-tree="$PROJECT_DIR" log | grep '^commit' | wc -l)
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $VERSION" "$TARGET_BUILD_DIR/$INFOPLIST_PATH"```

I'd really appreciate a version that understands 2K12R2 server and has the login items syncing...

It's only supposed to do it on the first launch.

Really like this tool, thanks for all of your work on it.

This issue is present when DNS resolves the Domain Controllers successfully, but the machine (and therefore the app) is unable to connect to them. It looks like the check for domain connectivity uses dig to see if there are DCs in DNS, but doesn't confirm connectivity.

Use case: An environment where DNS resolves the DCs, but doesn't allow devices to connect to those subnets without a device certificate.

Note: Maybe this isn't a common enough issue to warrant a fix, but it may be related to other reported issues regarding negative expiration dates. An additional check for connectivity may prevent this from occurring, though I don't know why the stored expireDateUnixplist value is getting updated to an incorrect value, which is very close to the SMBPasswordLastSet value.

Here is what I am seeing:

Configuration:

defaults read org.pmbuko.adpassmon
accTest = 0;
enableKeychainLockCheck = 1;
expireDateUnix = 1467652519;
"first_run" = 0;
isBehaviour2Enabled = 1;
"menu_title" = 54d;
pwdSetDate = "16926.72";
selectedBehaviour = 2;
tooltip = "Your password expires\nMon Jul 4 12:15:19 CDT 2016";

If connected to LAN:

Tool works as intended
Expiration Date in menu bar is correct (55d)
expireDateUnix in plist is correct (1462468608)
Dig successful (multiple domain controllers returned in ANSWER section)
ping to DCs successful
Able to read msDS-UserPasswordExpiryTimeComputed successfully

5/11/16 11:34:33.021 AM ADPassMon[548]: Domain reachable.
5/11/16 11:34:33.021 AM ADPassMon[548]: Starting auto process…
5/11/16 11:34:33.022 AM ADPassMon[548]: Found expireDateUnix in plist: 1462468608
5/11/16 11:34:33.070 AM ADPassMon[548]: Got expireDateUnix: 1467652519
5/11/16 11:34:33.070 AM ADPassMon[548]: Using msDS method
5/11/16 11:34:33.084 AM ADPassMon[548]: daysUntilExp: 54.028310185185
5/11/16 11:34:33.091 AM ADPassMon[548]: ADPassMon password method selected
5/11/16 11:34:33.091 AM ADPassMon[548]: Testing Keychain Lock state...;
5/11/16 11:34:33.127 AM ADPassMon[548]: Keychain unlocked...

If connected to WiFi:

Expiration Date in menu bar is incorrect (-5d) (yes, negative 5)
expireDateUnix in plist is incorrect (1462468607)
--The incorrect expireDateUnix is very close to the SMBPasswordLastSet value, about 78 seconds later. I've tried tracking down the root cause for this in the code but haven't had much luck.
Dig successful (multiple domain controllers returned in ANSWER section)
ping to DCs fails (traffic cannot access DC subnets without cert)
Unable to read msDS-UserPasswordExpiryTimeComputed

5/11/16 11:54:35.816 AM ADPassMon[548]: Domain reachable.
5/11/16 11:54:35.816 AM ADPassMon[548]: Starting auto process…
5/11/16 11:54:35.817 AM ADPassMon[548]: Found expireDateUnix in plist: 1467652519
5/11/16 11:54:45.925 AM ADPassMon[548]: Using alt method
5/11/16 11:54:45.960 AM ADPassMon[548]: New pwdSetDate (16926.72)
5/11/16 11:54:45.960 AM ADPassMon[548]: ≥ plist value (1.692672E+4) so we use it
5/11/16 11:54:45.968 AM ADPassMon[548]: daysUntilExp: -5.984688
5/11/16 11:54:45.975 AM ADPassMon[548]: expireDateUnix: 1462468607
5/11/16 11:54:45.976 AM ADPassMon[548]: expirationDate: Thursday, May 5, 2016 at 12:16:48 PM
5/11/16 11:54:45.982 AM ADPassMon[548]: Triggering notification…
5/11/16 11:54:45.983 AM ADPassMon[548]: ADPassMon password method selected
5/11/16 11:54:45.983 AM ADPassMon[548]: Testing Keychain Lock state...
5/11/16 11:54:46.017 AM ADPassMon[548]: Keychain unlocked...

If connected to external network (after things are working internally):

Tool works as intended
Expiration Date in menu bar is correct (55d)
expireDateUnix in plist is correct (1462468608)
Dig fails
no DCs to ping
Unable to read msDS-UserPasswordExpiryTimeComputed

5/11/16 12:19:40.400 PM ADPassMon[548]: Domain test timed out.
5/11/16 12:19:40.401 PM ADPassMon[548]: Starting auto process…
5/11/16 12:19:40.401 PM ADPassMon[548]: Offline. Updating menu…
5/11/16 12:19:40.414 PM ADPassMon[548]: ADPassMon password method selected
5/11/16 12:19:40.415 PM ADPassMon[548]: Testing Keychain Lock state...
5/11/16 12:19:40.449 PM ADPassMon[548]: Keychain unlocked...

Hello guys, trying this out for our environment.
So far looks good, except when deploying a custom plist (via defaults) for users prior to running the App, on first run the 'Change Password' is greyed out.
The rest of the settings are deploying fine, and if we either relaunch the App, 'Re-check Expiration' or 'Test Settings' then the option becomes available. But I'd rather it be ready to go right away?
I tested on a few Macs, this seems a consistent issue in our environment with these settings.
I think there were settings that I tested where this was not the case (maybe it's the manual expiration check?)

Items I am deploying:
defaults write $plistPath accTest 0
defaults write $plistPath enableKeychainLockCheck 1
defaults write $plistPath enableNotifications 1
defaults write $plistPath expireAge "60"
defaults write $plistPath pwPolicy "Passwords must have at least 8 characters etc"
defaults write $plistPath selectedBehaviour 2
defaults write $plistPath selectedMethod 1
defaults write $plistPath warningDays 7

I've been running a version of ADPM that's several months out of date (v 2.20.10).

I would have downloaded a newer version if I'd been aware that a newer version existed. But I'm not in the habit of visiting Github just to check for updates.

There are several ways updates could be handled. In order from simplest to most complex:

1. A menu item "Check for Updates…" that lets me manually check for updates from within ADPM.
2. Automatically check for updates, and display a notification if an update is found.
3. Same as 2, but it should be an option that can be turned on/off in preferences. (Many of the users I support can't install updates, so notifications would just be annoying to them.)
4. Self-installing updates. ("A newer version of ADPassMon is available. Would you like to install it?")

I don't know how difficult it would be to implement this request, but I think update notifications are an important feature for any app. I'd be pretty happy just to have # 1 (the menu item).

Hi guys

It would be great if there was a way to make this software easier to deploy with reasonable settings.
I have now written an 'outset' script which runs at login to set the defaults that are sensible for our environment, but this still requires the users to open the software and set it to run in startup.

Is there any simple way to also get this to open at startup? Perhaps I just need to add another line to my outset script - but perhaps you guys have a simpler way than using outset at all?

Thanks!

This is a feature request from @SlackMac on Slack.

when using defaults write to set a pwPolicyButton its still just has the default "OK"

It was recommended trying pwPolicyButtonTitle as well and that didn't work.

2.20.4:

Old v2 fork:

We have a non-standard setup that I've been trying to configure ADPassMon around. We have an identity management system that handles all password changes and expiry and pushes this down to all affected systems, including Active Directory.

Password expiry itself is not set on the AD side. So, it seems your code is doing a check in AD for password expiry, sees it's not set, then skips/ignores the selectedMethod and expireAge keys entirely. Disclaimer: my AppleScript is very rusty and I may not be entirely understanding all your code. ;)

Is there a key I'm missing or set incorrectly in my plist that would force manual mode or is the logic in your code part of the cause?

org.pmbuko.ADPassMon.txt

Issue:

ADPassMon v2.20.8 is not displaying in the menu bar on an AD account. There is no evident way to interact with ADPassMon via the GUI.

Attempted Resolution:

Ran defaults write org.pmbuko.ADPassMon runIfLocal -bool false as suggested with no change in app behavior.
Issue persists through killall cfprefsd, logout, and reboot. ADPassMon process is running.

Environment:

AD Bound Mac
AD Account w/ local admin right
OS X 10.11 (15A284)

from #adpassmon on macadmins.org slack

3/2/16 12:53:11.005 PM ADPassMon[522]:   expirationDate: Monday, March 30, 1970 at 6:53:11 PM
3/2/16 12:53:11.014 PM ADPassMon[522]: Script Error: Failed conversion of ``Monday, March 30, 1970 at 6:53:11 PM'' using format ``%A, %d %b %Y %H:%M:%S''
date: illegal time format
usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... 
            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]
3/2/16 12:53:11.014 PM ADPassMon[522]: ADPassMon password method selected
3/2/16 12:53:11.015 PM ADPassMon[522]: Testing Keychain Lock state...
3/2/16 12:53:11.033 PM ADPassMon[522]:   Keychain unlocked

We are looking to deploy ADPassMon to our users, however we have many who work from home at times and while testing, I've found that it does not work when connected to VPN.

We run a Cisco VPN and use the built-in Mac client to connect. When connected to VPN the Refresh Ticket and Change Password options are greyed out. A look at the log shows "Domain not reachable". Our domain is reachable as logins are permitted for users not cached on the machine.

I ran your script ad_pass_exp.sh and got the following:

ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
No such key: userAccountControl
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
(standard_in) 1: parse error
No such key: pwdLastSet
myLDAP: 192.168.x.x
mySearchBase:
uAC: 512
passExpires: yes
expireAgeUnix:
expireAge:
pwdSetDateRaw: 130977844049510960
pwdSetDateUnix: 1453310804.95109600000000000000
pwdSetDate: 16820.72690915620370370370
todayUnix: 1453318462
today: 16820.81553240740740740740
daysUntilExp: -.08862325120370370370
daysUntilExpNice: -

The value for myLDAP is being set to my home router instead of the DC.

scutil --dns shows the first resolver as my home router and then the DCs as the second resolver.

Is there not a way to have this program work on a VPN connection?

The UI scripting fails to pop up the change password dialog. It takes you to the System Preferences window only.

I'm running 2.5.0 build 1 (latest commit), though I think this has been around for a couple versions in my own code. This is most likely due to the domain test halting any further activity when off the domain.

Hi Group!

Getting this weird string in Console when launching version 2.20.19 on some but not all of our folks. Worked in version 2.20.15. Here's the string:

4:42:21 PM ADPassMon: *** -[ADPassMonAppDelegate applicationWillFinishLaunching:]: <dscl_cmd> DS Error: -14136 (eDSRecordNotFound) (error56)

Any thoughts? THANKS!

In the case where a user has a borked Local Items keychain from an earlier password change (multiple prompts for Local Items keychain password on login), a nice feature for remote support would be to have an option to reset this separately (maybe from the menubar dropdown?), i.e. just nuking the UUID folder in ~/Library/Keychains/ and requesting reboot as opposed to taking out the Login Keychain along with it.

There are three files in the ADPassMon bundle that have executable permission, but don't require such permission. Here are the files, as reported by RB App Checker:

In testing, I cannot for the life of me get the
defaults write com.apple.keychainaccess SyncLoginPassword -bool false to prevent the keychain sync dialog from appearing at the loginwindow.

I've tried manually running (ensuring that the preference is correctly set in my user's preferences) as well as automated it with an outset login-once script performing the defaults write.

I'm running 10.11.3 on my machine. To be fair, I haven't tested it on any others.

Also, I realize that if this doesn't work, it's not your fault! I'm just wondering if either something has changed and the wiki documentation just needs to be updated, or a caveat needs to be added mentioning under what versions this actually works.

Thanks!

Haven't had time to properly investigate, logging this to remind me.

I've been told by some sources that Keychain Access's Keychain First Aid functionality is disappearing in future versions of OS X. Potentially as early as 10.11.2 since it's broken in 10.11.1...

Will this have an impact on ADPassMon's ability to fix the keychain password?

Hi there,

I was testing ADPassMon and noticed something odd.

When setting this plist item (allowPasswordChange):
defaults write org.pmbuko.ADPassMon allowPasswordChange -bool false

Which should:

You may not wish the user to change their password via ADPassMon at all (for example, if your users are required to use a website). You can set this with the following command or via MCX. Any password policy options you've set will still appear, but when the user clicks “OK” the dialog box is dismissed & no further action is taken. This option is available in the preferences window.

I found that I can still click and select Change Password from the menu and ADPassMon will show me the password policy and then (depending on setting) will either bring up system preferences or prompt for a password change through ADPassMon.

I also noticed that the Password policy would not display the button to goto the website url specified.

I am testing on 10.10.5 as well. Other than that, everything else works quite well.

Here is the output of the plist/settings:

Reset and performed action auto and then manual 90
12/11/15 11:19:15.008 AM ADPassMon[1971]: *** -[ADPassMonAppDelegate revertDefaults:]: 2015-12-11 11:19:15.006 defaults[2629:47744]
Domain (org.pmbuko.ADPassMon) not found.
Defaults have not been changed. (error 1)
12/11/15 11:25:47.674 AM ADPassMon[1971]: selectedMethod: 90
12/11/15 11:25:47.724 AM ADPassMon[1971]: Domain reachable.
12/11/15 11:25:47.724 AM ADPassMon[1971]: Starting manual process…
12/11/15 11:25:47.726 AM ADPassMon[1971]: Found expireDateUnix in plist: 910692730085
12/11/15 11:25:47.783 AM ADPassMon[1971]: Got expireDateUnix: 910692730085
12/11/15 11:25:47.783 AM ADPassMon[1971]: Using alt method
12/11/15 11:25:47.809 AM ADPassMon[1971]: New pwdSetDate (16650.69)
12/11/15 11:25:47.809 AM ADPassMon[1971]: will be saved to plist.
12/11/15 11:25:47.815 AM ADPassMon[1971]: daysUntilExp: -40.11957
12/11/15 11:25:47.816 AM ADPassMon[1971]: expirationDate: Sunday, November 1, 2015 at 8:33:36 AM
12/11/15 11:25:47.817 AM ADPassMon[1971]: Triggering notification…
12/11/15 11:25:47.817 AM ADPassMon[1971]: Native password method selected
12/11/15 11:25:47.818 AM ADPassMon[1971]: Testing Universal Access settings…
12/11/15 11:25:50.798 AM ADPassMon[1971]: Prompting for password
12/11/15 11:26:01.805 AM ADPassMon[1971]: Enabled
12/11/15 11:26:01.806 AM ADPassMon[1971]: Skipping Keychain Lock state check...
12/11/15 11:26:10.572 AM ADPassMon[1971]: selectedMethod: 1
12/11/15 11:26:10.622 AM ADPassMon[1971]: Domain reachable.
12/11/15 11:26:10.622 AM ADPassMon[1971]: Starting auto process…
12/11/15 11:26:10.751 AM ADPassMon[1971]: Got expireDateUnix: 910692730085
12/11/15 11:26:10.751 AM ADPassMon[1971]: Using msDS method
12/11/15 11:26:10.761 AM ADPassMon[1971]: daysUntilExp: 1.052364430689E+7
12/11/15 11:26:10.764 AM ADPassMon[1971]: Native password method selected
12/11/15 11:26:10.764 AM ADPassMon[1971]: Testing Universal Access settings…
12/11/15 11:26:10.764 AM ADPassMon[1971]: Enabled
12/11/15 11:26:10.765 AM ADPassMon[1971]: Skipping Keychain Lock state check...
12/11/15 11:26:18.581 AM ADPassMon[1971]: selectedMethod: 90
12/11/15 11:26:18.633 AM ADPassMon[1971]: Domain reachable.
12/11/15 11:26:18.633 AM ADPassMon[1971]: Starting manual process…
12/11/15 11:26:18.635 AM ADPassMon[1971]: Found expireDateUnix in plist: 910692730085
12/11/15 11:26:18.670 AM ADPassMon[1971]: Got expireDateUnix: 910692730085
12/11/15 11:26:18.670 AM ADPassMon[1971]: Using alt method
12/11/15 11:26:18.697 AM ADPassMon[1971]: New pwdSetDate (16650.69)
12/11/15 11:26:18.698 AM ADPassMon[1971]: ≥ plist value (1.665069E+4) so we use it
12/11/15 11:26:18.704 AM ADPassMon[1971]: daysUntilExp: -40.11993
12/11/15 11:26:18.704 AM ADPassMon[1971]: expirationDate: Sunday, November 1, 2015 at 8:33:36 AM
12/11/15 11:26:18.707 AM ADPassMon[1971]: Triggering notification…
12/11/15 11:26:18.708 AM ADPassMon[1971]: Native password method selected
12/11/15 11:26:18.708 AM ADPassMon[1971]: Testing Universal Access settings…
12/11/15 11:26:18.708 AM ADPassMon[1971]: Enabled
12/11/15 11:26:18.708 AM ADPassMon[1971]: Skipping Keychain Lock state check...

What's up Group! Not sure what happened but all of the sudden, i have folks who's expiration number is in the tens of millions. 10523501d to be exact on one! Got the log for this. Wondering if you can see something:

4/27/16 2:41:14.583 PM ADPassMon[17138]: Running on OS 10.11.x
4/27/16 2:41:14.685 PM ADPassMon[17138]: Running under a locally cached network account.
4/27/16 2:41:14.692 PM ADPassMon[17138]: Native password method selected
4/27/16 2:41:14.692 PM ADPassMon[17138]: Testing Universal Access settings…
4/27/16 2:41:14.692 PM ADPassMon[17138]: Enabled
4/27/16 2:41:14.850 PM ADPassMon[17138]: Domain reachable.
4/27/16 2:41:14.850 PM ADPassMon[17138]: Testing if password can expire…
4/27/16 2:41:14.890 PM ADPassMon[17138]: Password does expire.
4/27/16 2:41:14.924 PM ADPassMon[17138]: Domain reachable.
4/27/16 2:41:14.925 PM ADPassMon[17138]: Starting auto process…
4/27/16 2:41:14.925 PM ADPassMon[17138]: Found expireDateUnix in plist: -2.147483648E+9
4/27/16 2:41:15.378 PM ADPassMon[17138]: Got expireDateUnix: 910692730085
4/27/16 2:41:15.378 PM ADPassMon[17138]: Using msDS method
4/27/16 2:41:15.390 PM ADPassMon[17138]: daysUntilExp: 1.052350633808E+7
4/27/16 2:41:15.392 PM ADPassMon[17138]: Native password method selected
4/27/16 2:41:15.392 PM ADPassMon[17138]: Testing Universal Access settings…
4/27/16 2:41:15.392 PM ADPassMon[17138]: Enabled
4/27/16 2:41:15.392 PM ADPassMon[17138]: Testing Keychain Lock state...
4/27/16 2:41:15.426 PM ADPassMon[17138]: Keychain unlocked...

If this is the wrong place to make this request, please point me in the appropriate direction.

Short version:
I know that ADPassMon is a Mac-only app, but is there a similar Windows utility? An app that can display (in the systray) days until password expiration?

Long version:
My windows users have noticed Mac users have this lovely tool in their menubar to show them when their passwords expire. (I suspect they think it's a feature of OS X.)

Several have now asked me how they can get that on their Windows 7 PCs. I've just spent 10 minutes Googling for a solution, but I can't find one.

Asking my fellow Mac admins might not be the best strategy for asking for Windows help, but asking in the ADPassMon group has the advantage of me not having to first explain what ADPassMon does.

Should I just tell those Windows users to switch to Mac?

Hello,

I am very impressed by this tool. Being able to advise users of there pending password change is golden.

OSX El Capitan 10.11.3

I am hoping to be able to utilize tools built in password dialog box which apparently will update the keychain. However it is not working. I get a message that states:

Password change failed. Please try again.
In system logs I see:
ADPassMon[334] All password fields populated & new & veryify match...
ADPassMon[334] Attempting user password change..
ADPassMon[334] Password change failed.

Please help! I would investigate changing settings on the domain to help this work properly!

Thank you,
Tony H.

Hello!
We're looking into deploying this to our staff laptops, however, in testing I noticed that Gatekeeper stops the first-time run since the app is not in the "identified developers" list. I was wondering if there is a possibility of this app being signed in the future to alleviate this issue? We really don't want to disable Gatekeeper for our staff machines.
Thanks!

Today when I unlocked my Mac, I looked in my menu bar and was surprised to see that my password would expire in [-58d]. That's actually when I last changed my password — 58 days ago.

I selected Re-check Expiration and it changed to [31d] which is the correct number.