ADPassMon has moved!
The ADPassMon source code, software releases, and documentation are now hosted on GitHub. This page will remain for a short time for historical purposes, but I encourage you to visit GitHub for up-to-date information about using ADPassMon, instead. I will still post about ADPassMon updates and bugfixes on this blog.
Also note, comments on this page are closed. Please submit bug reports and feature requests to the github project directly.
Quick Summary and Features
ADPassMon is a small menu bar application that shows the number of days remaining until your Active Directory password expires. ADPassMon features:
- support for Mac OS X 10.6 through 10.11
- optional Growl or Notification Center alerts with adjustable warning period
- integrated Kerberos ticket renewal
- Change Password menu item, with optional password requirements reminder
- offline functionality via cached expiry information
- MCX support for ease of administration
This software is released under the MIT license.
Read enough? Download the correct version for your operating system:
Mac OS X 10.8 or newer (tested up through OS X 10.11)
Want to know more? Read on for the full story.
The Problem
Most Active Directory sites require users to change their passwords at regular intervals – such as every 30, 60, 90, or 180 days. Unless you write your password expiration date on a calendar or set some other sort of reminder, it’s possible that your password will expire before you’ve had a chance to change it.
Mac OS X’s AD integration has come a long way in mitigating this issue. Since Mac OS 10.4, users with impending password expirations will be notified when they log in. If their password is set to expire within 24 hours, they will be forced to change their password before being allowed to log in. Administrators can adjust how long before password expiration to start showing these login screen warnings. This is not a foolproof solution, though. If you’re the kind of person who doesn’t regularly log out of your computer, you might go weeks without visiting the login screen, completely missing the warning period. If you can’t count on your operating system to keep you informed regardless of your use habits, what can you do?
The Solution
ADPassMon, short for Active Directory Password Monitor, is a utility that solves this issue by providing up-to-date password expiration information at a glance. It places an item in the menu bar that shows the number of days remaining until the password expires, simply and unobtrusively. Here it is on the left.
Hovering your cursor over the icon reveals more precise information in a tooltip.
Clicking on the menu item reveals some additional features, which I’ll discuss further below.
Selecting the Preferences item reveals the program’s configuration options. Note the message area at the top of the window. It will normally display the full password expiration information, but if can also display errors or other messages affecting use of the application.
Auto or Manual Mode
By default, ADPassMon attempts to automatically acquire all the information it needs to calculate your password expiration information. This will not work in all environments, so the option to set the maximum password age manually is provided. If Auto mode results in an incorrect or negative password expiration value, then you should use Manual mode and provide your site’s maximum password age in days.
Growl / Notification Center Alerts
If you have Growl installed or use OS X 10.8 with Notifcation Center, ADPassMon can optionally send you notifications of impending password expirations. Check the Enable Notifications box and enter the number of days before the password expires that you want the warnings to start appearing. Warnings will appear every 12 hours after the threshold is reached. Each warning will resemble the following:
Kerberos Tickets
ADPassMon can also acquire and/or renew Kerberos tickets for you. In OS 10.6, Apple buried the graphical Kerberos ticket management tool — Ticket Viewer.app — inside the /System/Library/CoreServices folder. ADPassMon lets you request a new ticket or renew an existing ticket right from its menu. (A Kerberos ticket is required if you’re using Auto mode, so you’ll be prompted to obtain a ticket if you launch ADPassMon and don’t have a ticket.) This menu item will be disabled if the app cannot communicate with your AD domain.
KerbMinder Integration (only in v1.10.0+)
If you have KerbMinder installed, ADPassMon will show an extra menu option that lets you enable and disable it.
Change Password Shortcut
ADPassMon’s menu provides a shortcut to Mac OS X’s standard password change interface. When you select it, System Preferences will automatically launch and show you the standard password change window.
This feature requires that ADPassMon be allowed to control the GUI in the Security & Privacy pref pane’s Accessibility settings. If it is not enabled, users with administrator access will be prompted to enable it when the program first launches.
Skip Accessibility Option Check
If you want to keep the Accessibility setup dialog box from appearing when your users first run ADPassMon, you can set the accTest preference value to 0 to disable it.
defaults write org.pmbuko.ADPassMon accTest 0
Password Policy Reminder
If you are an administrator and need an easy way to remind your users of your organization’s password complexity requirements, you can enable the password policy reminder feature by defining a pwPolicy key in ADPassMon’s plist file. You can do this either by editing the plist file directly with a plist editor (Xcode works well for this), or by setting the content of the reminder message in the terminal as follows:
defaults write org.pmbuko.ADPassMon pwPolicy "Your password requirement message goes here."
The password policy reminder dialog button’s default text is “OK”, but you can change it as follows:
defaults write org.pmbuko.ADPassMon pwPolicyButton "I understand"
When the pwPolicy value is set, a policy reminder alert like the one below will appear when you select Change Password from the ADPassMon menu. You must click the single button before you can change your password.
Lockable Preferences
If you’re an administrator and wish to deploy this utility to your Macs, you can disable access to the Preferences window by adding a prefsLocked key and setting its value to true in the org.pmbuko.ADPassMon.plist. You can do this via MCX, or manually by entering this command in the terminal:
defaults write org.pmbuko.ADPassMon prefsLocked true
Users will still be able to enable or disable Growl/Notification Center alerts via the menu option.
App Reset
If you’re experiencing trouble with ADPassMon, you can clear the settings and return the application to defaults by selecting the Reset tab in the Preferences window and clicking the Revert to Defaults button.
Acknowledgements
I have many people to thank for making this application possible.
- Jonathan Nathan, of JNSoftware, for providing sample code for a menu app written in AppleScript ObjectiveC
- Shane Stanley, for his excellent eBook, AppleScriptObjC Explored
- Andrew Thomson, for his work on the Password Monitor app on which ADPassMon is based
- John Welch, for recommending Shane’s book and inspiring me to start learning AppleScriptObjC
Last but not least, I give my sincere thanks to my beta testers: Joe Chilcote, Brian LaShomb, Joel Moses, Rusty Myers, Stephen Rayda, Tom Rodgers, and especially Rich Trouton. This app would have been less useful without their help.
MIT License
This software is released under the terms of the MIT license.
Copyright (C) 2015 by Peter Bukowinski
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
This is fantastic news, you should setup some way that I can pay you!
One issue in our environment. The menubar is showing [-39] and shows my expiration 39 days in the past not the future. Any thought on that?
Alan–
I’d recommend using Manual mode in this case. Just enter your site’s password change interval in days, hit enter, and then Apply changes.
Is there a way to set Add to Login Items to true through MCX?
Not in the current version. I’ll take that as a feature request. In the meantime, you should be ale to manage it by using the example I found here:
http://mailman.intermedia.net/pipermail/casper/2010-November/008890.html
Or whack this into a plist file (modify the path as appropriate) and deploy it into /Library/LaunchAgents. Set it to root:wheel, mode 644, done.
KeepAlive
SuccessfulExit
Label
com.wordpress.yourmacguy.adpassmon
ProgramArguments
/path/to/ADPassMon.app/Contents/MacOS/ADPassMon
Dang. Here instead:
http://pastebin.com/H4sYUaAa
Older Intel Core Duo MacBook:
You can’t open the application “ADPassMon” because it’s not supported on this type of Mac.
ADPassMon: Mach-O 64-bit executable x86_64
Any chance to add 32 bit support for older Macs?
Don’t think it will be a problem. I’ll see what I can do.
Ok, I’ve rebuilt the app to include 32-bit code. I updated the download link to point to the new version. Please let me know if it works for you.
Yes, it does.
Thank you!
I want this app, but …
… keep on display “Working …”
If I switch to “Manual”, app switch back to “Auto”.
When you switch to manual, make sure you press Tab or Enter after inputting the maximum password age.
Thanks.
Now display “Your password will expire in -15079 days ….” :-)
Can you open up Console.app (in Utilities), select Console messages, then type ADPassMon in the search field? Copy the last 20 log items you see and paste them here, please.
OK
———————
25.5.11 9:54:19 ADPassMon[1650] Starting manual process…
25.5.11 9:54:19 ADPassMon[1650] Found expireAge in plist: 40
25.5.11 9:54:19 ADPassMon[1650] The new pwdSetDate (-1,34774E+5)
25.5.11 9:54:19 ADPassMon[1650] is < value in plist (0,0) so we ignore it
25.5.11 9:54:19 ADPassMon[1650] daysUntilExp: -1,507932938657E+4
25.5.11 9:54:19 ADPassMon[1650] daysUntilExpNice: -15079
25.5.11 9:54:19 ADPassMon[1650] expirationDate: úterý, 10. února 1970 2:00:00
25.5.11 9:54:19 ADPassMon[1650] Finished process
25.5.11 9:54:19 ADPassMon[1650] Starting manual process…
25.5.11 9:54:19 ADPassMon[1650] Found expireAge in plist: 40
25.5.11 9:54:19 ADPassMon[1650] The new pwdSetDate (-1,34774E+5)
25.5.11 9:54:19 ADPassMon[1650] is < value in plist (0,0) so we ignore it
25.5.11 9:54:19 ADPassMon[1650] daysUntilExp: -1,507932938657E+4
25.5.11 9:54:19 ADPassMon[1650] daysUntilExpNice: -15079
25.5.11 9:54:19 ADPassMon[1650] expirationDate: úterý, 10. února 1970 2:00:00
25.5.11 9:54:19 ADPassMon[1650] Finished process
25.5.11 9:54:52 ADPassMon[1650] selectedMethod: 40
25.5.11 9:54:52 ADPassMon[1650] Starting manual process…
25.5.11 9:54:52 ADPassMon[1650] Found expireAge in plist: 40
25.5.11 9:54:52 ADPassMon[1650] The new pwdSetDate (-1,34774E+5)
25.5.11 9:54:52 ADPassMon[1650] is < value in plist (0,0) so we ignore it
25.5.11 9:54:52 ADPassMon[1650] daysUntilExp: -1,507932976852E+4
25.5.11 9:54:52 ADPassMon[1650] daysUntilExpNice: -15079
25.5.11 9:54:52 ADPassMon[1650] expirationDate: úterý, 10. února 1970 2:00:00
25.5.11 9:54:52 ADPassMon[1650] Finished process
What value are you putting in the maximum password age field?
40
Try running this in terminal and let me know the output.
/usr/bin/dscl localhost read /Search/Users/$USER pwdLastSet | /usr/bin/awk '/pwdLastSet:/{print $2}'
No such key: pwdLastSet
No such key: pwdLastSet
It appears that your computer is not bound to Active Directory, or at least the user account you are logged in with does not exist in Active Directory.
Hmm …
I tested the application on second computer (with clean install) with the same result :-(
Both computers are bind to AD, and logged user is domain user.
It can not be a problem on the domain controller? It runs on Windows SBS 2003.
Ok, the next thing to check is your Directory Service search policy:
dscl -q localhost -read /Search
If the output of this command does not include an Active Directory item, then you’ll need to modify or create your custom search path to include your Active Directory domain.
CSPSearchPath:
/Local/Default
/BSD/local
/Active Directory/All Domains
DHCPLDAPDefault: off
LSPSearchPath: /Local/Default /BSD/local
NSPSearchPath: /Local/Default /BSD/local
ReadOnlyNode: ReadOnly
SearchPath:
/Local/Default
/BSD/local
/Active Directory/All Domains
SearchPolicy: dsAttrTypeStandard:CSPSearchPath
Domain controller runs on Windows SBS 2003, but Domain Functional Levels is Windows 2000 Native …
Hmmm. Your search path is set correctly. I’m running out of ideas about what the problem could be, so it might be that you’re running in 2000 mode, but I can’t be sure. It could be a kerberos issue as well. Can you show me the output of the ‘klist’ command after a fresh login?
Output of the klist:
Kerberos 5 ticket cache: ‘API:Initial default ccache’
Default principal: testus@FIRMA.LOCAL
Valid Starting Expires Service Principal
06/15/11 11:48:51 06/15/11 19:48:51 krbtgt/FIRMA.LOCAL@FIRMA.LOCAL
renew until 06/15/11 19:48:51
06/15/11 11:49:01 06/15/11 19:48:51 cifs/server.firma.local@FIRMA.LOCAL
renew until 06/15/11 19:48:51
I’m getting the same output as MaM consistently with Leopard and Snow Leopard regardless of OS version on all AD bound machines (50 some odd machines) 3 users (in the IT group) and one enterprise admin user show the correct days until expiration. They are all in an OD IT group and the rest of the users are in a employees OD group that has the AD “Domain Users” as the member. This is Magic triangle with Server 03. I’ve gone into the Manually setting expiration, hit Enter, then apply, I’m still getting an expiration date in 1970. When I take a user out of Domain Users, nothing changes, let’s say I add that same test user to the “IT” OD group, still nothing changes; expiration date in 1970. Now what if I bind a machine only to AD and not OD? Same thing, expiration in 1970 despite our domain policy specifying expiration every 90 days.
I had the exact same problem with the older Password Monitor except it would just list a diamond (a sort of out of range error). Every time I deleted the user folder for testing. The users being local admins on the machine doesn’t help or hinder this false expiration repot. It’s a real mystery as to why this only works for 3 users in my domain.
Of the non-IT users, have their passwords ever been changed? I.e. Were they set initially by an admin and not reset by the users? Also, please let me know what the console log shows when you do a recheck expiration.
I reset the password interactively at the System Preferences level but had initially set the pass in AD. The log output is essentially the same as what MaM outputted. The initial opening of ADPass Mon produces this:
6/29/11 1:15:28 PM ADPassMon[1410] Running on OS 10.6.x
6/29/11 1:15:28 PM ADPassMon[1410] Testing Universal Access settings…
6/29/11 1:15:28 PM ADPassMon[1410] Disabled
6/29/11 1:15:28 PM ADPassMon[1410] Skipping because user not an admin
6/29/11 1:15:28 PM ADPassMon[1410] Testing for Growl…
6/29/11 1:15:28 PM ADPassMon[1410] Not running
6/29/11 1:15:28 PM ADPassMon[1410] Starting auto process…
6/29/11 1:15:28 PM ADPassMon[1410] Found expireAge in plist: 90
6/29/11 1:15:28 PM ADPassMon[1410] The new pwdSetDate (-1.34774E+5)
6/29/11 1:15:28 PM ADPassMon[1410] is < value in plist (0.0) so we ignore it
6/29/11 1:15:28 PM ADPassMon[1410] daysUntilExp: -1.506471907407E+4
6/29/11 1:15:28 PM ADPassMon[1410] daysUntilExpNice: -15064
6/29/11 1:15:28 PM ADPassMon[1410] expirationDate: Tuesday, March 31, 1970 8:00:00 PM
6/29/11 1:15:28 PM ADPassMon[1410] Finished process
I then reset the password and re-ran expiration check and got this:
6/29/11 1:16:06 PM ADPassMon[1410] Starting auto process…
6/29/11 1:16:06 PM ADPassMon[1410] Found expireAge in plist: 90
6/29/11 1:16:06 PM ADPassMon[1410] The new pwdSetDate (-1.34774E+5)
6/29/11 1:16:06 PM ADPassMon[1410] is < value in plist (0.0) so we ignore it
6/29/11 1:16:06 PM ADPassMon[1410] daysUntilExp: -1.506471951389E+4
6/29/11 1:16:06 PM ADPassMon[1410] daysUntilExpNice: -15064
6/29/11 1:16:06 PM ADPassMon[1410] expirationDate: Tuesday, March 31, 1970 8:00:00 PM
6/29/11 1:16:06 PM ADPassMon[1410] Finished process
For a successful user (enterprise admin):
6/29/11 1:24:52 PM ADPassMon[1555] Starting auto process…
6/29/11 1:24:52 PM ADPassMon[1555] Found expireAge in plist: 90
6/29/11 1:24:52 PM ADPassMon[1555] The new pwdSetDate (1.509770815694E+4)
6/29/11 1:24:52 PM ADPassMon[1555] is ≥ value in plist (1.509770800781E+4) so we use it
6/29/11 1:24:52 PM ADPassMon[1555] daysUntilExp: 32.982555084538
6/29/11 1:24:52 PM ADPassMon[1555] daysUntilExpNice: 32
6/29/11 1:24:52 PM ADPassMon[1555] expirationDate: Monday, August 1, 2011 12:59:45 PM
6/29/11 1:24:52 PM ADPassMon[1555] Finished process
I'm finding that all of the users showing the eroneus expiration date are missing LDAP attributes when I browse LDAP using "NextStudio" I find that the majority of domain accounts are missing the following LDAP attributes:
accountExpires
adminCount
pwdLastSet
The normal value for
accountExpires: 923372036854775807
adminCount:1
pwdLastSet (varies..obviously)
I can tell you that the value has to exist somehow. How is it that the Snow Leopard and Windows login screens will tell a user that their pass is to expire in 25 days or less? I did a bit more digging and fired open good old ADSIedit.msc on my DC and found that the aforementioned attributes exist but just aren't getting "published" to LDAP. Methinks that apple's directory services (and MS Entourage) are doing more than just simple LDAP queries to find out when a user's pass will expire. I'm guessing that when you're utility looks for pwdLastSet and can't find the attribute that some default date gets returned in 1970.
You’ve definitely found the issue here. I’m somewhat gladdened that it’s no ADPassMon’s fault, but don’t know what can be done to fix the issue. Has your AD schema been extended or altered from MS standards? I’ve never heard of the password exiration value not being published.
I did some tests and the result is as follows:
Clean install Windows 2003 Small Bussiness Server – ADPassMon is not functional
Clean install Windows 2003 Server R2 – ADPassMon is functional
Clean install Windows 2008 Server – ADPassMon is functional
Probably the problem is in the AD schema in Windows 2003 SBS.
Hey y’all. Sorta went on vacation and didn’t want to post anything until I had something to contribute. As MaM guessed, yes we do have a Domain that was SBS and then later upgraded to Standard. As he says, a fresh install of Server 03 Standard would resolve the issue. As my issue is with my production AD, such a resolution was less than desirable. So, I opened up my ADUC, right clicked on Domain Users (this doesn’t matter) and selected Delegate Control… The next box asks you (for what group). I typed in auth and hit enter to auto-fill Authenticated Users. At the next screen I select “only the following objects..” radio button and scrolled down and selected the “User objects”. At the next screen I checked the box “Property-Specific” as we don’t want to grant write to all user objects (LDAP attributes). I scrolled down to “pwdLastSet” and checked read and write. The next dialogue box is a Finished screen. I then changed the password of a normal test user and successfully had a pwdLastSet value.
This marks the end to a nearly 2 year long outstanding ticket. I thank the members of the forum and, of course, pmbuko, for helping me come to a resolution. And, to microsoft, much love for http://support.microsoft.com/kb/294952/en-us. No more users who say they weren’t warned that their password would be expiring!!
Thanks so much for returning and letting us know how you resolved your issue.
Thanks for this, it is really cool.
I found that on first use I was getting negative numbers as well. It would date back to when I last renewed the password for the user. I changed it from Auto mode to Manual mode and put in 365, then pressed Enter, and then clicked Apply Changes.
It took me a while to figure out that I had to hit the Enter key and then Apply Changes. It seems strange to require the Enter key press for it to work. It might be helpful to make that more obvious or just allow the Apply Changes button to set it instead of the Enter key. I had to read through the comments to figure it out.
I agree that needing to press enter is not intuitive (or Mac-like). It bothered me at the time I coded it, but not enough to figure out the right was, I guess. I’ve added it as a feature request for the next version.
Would it be possible to make the Method (Auto or Manual) an option in the plist? And then also put the interval in there as well? Then we can set those settings through ARD.
FYI, I use Plistbuddy instead of the defaults command which is much nicer, especially when crafting Unix scripts for ARD.
Ah, nevermind, I figured it out. expireAge and selectedMethod.
On our demo machine, everything seems to be working except the Refresh Kerberos Ticket menu item is disabled. We’re getting the correct number of days until expiration showing via the auto method, kerberos is working, and ticket viewer shows the current active ticket. What am I missing to allow the refresh ticket option to work?
Does it stay grayed out even if you re-check the expiration? The way I set up the Refresh Kerberos Ticket option is that it will be disabled under a certain test condition. The test compares the “password set date” that is saved in the plist against the just acquired “password set date”. If the fresh value is greater than or equal to the plist value, then I assume the computer is on the network and successfully talking to AD. If the fresh value is less, it is likely a negative value and I assume the computer is not on the network and disable the kerberos menu item.
ADPassMon writes to the console log. Open Console.app, select Console messages, and then type ADPassMon in the search field to filter for those messages. Can you paste what you see in the log when you do a re-check expiration while on the network with a valid kerberos ticket?
In the console, it did show a lesser value than the plist for the new pwdSetDate. This account is less than 45 days old, and thus had not yet changed the password. Once I changed the password and re-checked the expiration, it all works. Thanks for pointing me in the right direction so quickly. My users are going to love this.
Great program. I have a silly question. How can I push this out to all accounts on a mac?
For multiple or single Macs, if you have Apple Remote Desktop you can do it by running the following “Send UNIX command” as each user on the computer(s) — assuming you already have ADPassMon copied into the Applications folder:
defaults write loginwindow AutoLaunchedApplicationDictionary -array-add '{Path="/Applications/ADPassMon.app";}'
This worked perfectly. Thank you for your time.
I’d like to consider using this in a company, but they’re going to ask what license it’s released under. I didn’t see that anywhere, so I’ll ask – what license are you releasing this under?
The software is released under the MIT license. I’ve updated the documentation to reflect this, and I will include the text of this license in future releases of the software.
Thanks. I’m pulling up the license terms now. I appreciate the quick response!
Hi Peter, I’m trying out ADpassmon for the first time, and i’m running into some issues- I’ve got 2 machines bound to the domain and successfully authentication my AD account. On one machine, the expiration date given by ADpassmon is 42 days, which is incorrect- it should be (today anyway) 88 days. On the other machine, it returns -15233 days. Same AD account, same AD domain.
I tried running the command you suggested for an earlier commenter (/usr/bin/dscl localhost read /Search/Users/$USER pwdLastSet | /usr/bin/awk ‘/pwdLastSet:/{print $2}’) and got the no such key response, but my active directory is in my search path. If I look at the attributes on my AD account, pwdLastSet is there, and the value is yesterday, which is correct. Any ideas? thanks.
Which OS are you using?
Lion. Surprisingly, the problem was gone the next day, and hasn’t returned. It’s possible we were having some kerberos issues outside of my macs that day.
Hi Peter,
trying your tool with a 10.6 Client sucessfully bound to AD WinServ2008.R2 Cant get it work
Console says:
11.10.11 13:49:50 ADPassMon[834] Starting auto process…
11.10.11 13:49:50 ADPassMon[834] Script Error: {“Can’t make word 1 of \”\” into type text.”} doesn’t match the parameters {theError, showErr} for errorOut_.
any ideas? Cheers
Chris,
Please try the following command in the terminal and let me know the result:
scutil –dns | awk ‘/nameserver\[1\]/{print $3}’
Hi,
result is an invalid option. If I change command to
scutil –dns | awk ‘/nameserver\[1\]/{print $3}’
I get no result (empty prompt)
thanks
Ok, now try replacing the 1 with a 0. I’m guessing your site only uses one DNS server?
result is “nameserver[0] : 192.168.4.10”
which is our AD DNS. As far as I know several machines are providing DNS functionality in the corresponding Domain forest.
thanks
Chris, please download this version of ADPassMon and test it. If it works for you, I’ll roll the change into an official version 1.3 and release the update. http://dl.dropbox.com/u/3967964/ADPassMon1.3test.app.zip
Great! I was able to make it work by adding a second DNS entry in System Preferences and using manual method for obtaining maximum password age. But now with this new version it´s working straightaway ! Thanks a lot, I really appreciate your work.
Chris
Do you have any plan to support growl 1.3?
Russel, I’ve updated ADPassMon to make it compatible with Growl 1.3. Please try it out.
I just installed ADPassMon yesterday. Yesterday, it said that my password would expire in -7 days. So I switched it to manual and specified 60 days. It then said my password would expire in 52 days. I wasn’t sure if that was right (I changed my password *around* a week ago) so left it and figured I’d just see how it turned out. Today when I logged in, it said my password would expire in 52 days. So I reverted to default settings and refreshed my Kerberos Ticket. But again it says [-7d]. Any suggestions?
Can you open up Console.app and let me know what ADPassMon is putting in the log?
Here’s the last entry:
11/22/11 8:19:15.912 AM ADPassMon: Starting auto process…
11/22/11 8:19:15.925 AM ADPassMon: myDNS: 10.5.1.68
11/22/11 8:19:16.607 AM ADPassMon: mySearchBase: DC=liox,DC=org
11/22/11 8:19:17.291 AM ADPassMon: Got expireAge: 0
11/22/11 8:19:17.593 AM ADPassMon: The new pwdSetDate (1.529264898762E+4)
11/22/11 8:19:17.594 AM ADPassMon: is < value in plist (1.529264941406E+4) so we ignore it
11/22/11 8:19:17.601 AM ADPassMon: daysUntilExp: -7.988977141204
11/22/11 8:19:17.601 AM ADPassMon: daysUntilExpNice: -7
11/22/11 8:19:17.602 AM ADPassMon: expirationDate: Monday, November 14, 2011 8:35:09 AM
11/22/11 8:19:17.603 AM ADPassMon: Finished process
I just clicked on “Re-check Expiration” and it now says -8 days. I checked with my Sys Adm and he said I changed my password on 11/14, so that’s about right. At this point, I’m thinking I just need to use the Manual Mode to set the expiration time. Thanks!
Is the DNS reported in the log (10.5.1.68) a Microsoft DNS server? If not, then this is what’s preventing auto-discovery of your max password age. Try the Revert to Defaults button in the Reset tab before going back to Manual mode.
I have the same problem as Kevin above, the expiration date is when the password was last reset. Here’s the log output:
2/2/12 1:49:34.012 PM ADPassMon: Running on OS 10.7.x
2/2/12 1:49:34.012 PM ADPassMon: Testing Universal Access settings…
2/2/12 1:49:35.541 PM ADPassMon: Already enabled
2/2/12 1:49:35.542 PM ADPassMon: Testing for Growl…
2/2/12 1:49:35.546 PM ADPassMon: Not running
2/2/12 1:49:35.570 PM ADPassMon: Testing for Kerberos ticket presence…
2/2/12 1:49:35.622 PM ADPassMon: No ticket found
2/2/12 1:49:44.146 PM ADPassMon: Ticket acquired
2/2/12 1:49:46.443 PM ADPassMon: Testing for Kerberos ticket presence…
2/2/12 1:49:46.475 PM ADPassMon: Ticket found and renewed
2/2/12 1:49:46.477 PM ADPassMon: Starting auto process…
2/2/12 1:49:46.487 PM ADPassMon: myDNS: 172.21.169.33
2/2/12 1:49:46.611 PM ADPassMon: mySearchBase: DC=forest,DC=name
2/2/12 1:49:46.651 PM ADPassMon: Got expireAge: 0
2/2/12 1:49:46.802 PM ADPassMon: The new pwdSetDate (1.537156443377E+4)
2/2/12 1:49:46.803 PM ADPassMon: is ≥ value in plist (0.0) so we use it
2/2/12 1:49:46.810 PM ADPassMon: daysUntilExp: -0.928459753106
2/2/12 1:49:46.810 PM ADPassMon: daysUntilExpNice: 0
2/2/12 1:49:46.811 PM ADPassMon: expirationDate: Wednesday, February 1, 2012 3:32:47 PM
2/2/12 1:49:46.814 PM ADPassMon: Finished process
2/2/12 1:49:46.815 PM ADPassMon: in the loop
Is there a way to get this working with automatic setting? This is a multi-domain forest. The forest is seen in the output above, so it’s like ‘forest.name’ but the actual domain the host is bound to is ‘domain.forest.name’. Could this have anything to do with this or the Kerberos problem I posted earlier?
Perttu, can you please try the following command in your terminal and let me know if it returns the proper search base of “dc=domain,dc=forest,dc=name”?
ldapsearch -LLL -Q -s base -H ldap://172.21.169.33 defaultNamingContext | /usr/bin/awk ‘/defaultNamingContext/{print $2}’
If it works, I will release a new version of ADPassMon for you that uses the ‘defaultNamingContext’ value instead of the ‘rootDomainNamingContext’ I’m using now.
Yes, it returns the proper search base of “dc=domain,dc=forest,dc=name”.
Ok, I’ve revised the application: http://dl.dropbox.com/u/3967964/ADPassMon.v1.5.dmg — Please download and test this version and let me know if it works properly in your multi-domain forest.
Thanks! The updated version seems to have fixed both issues.
ADPassMon asks to renew the Kerberos ticket every time I log in and then asks for a password, is this normal? I already have a TGT so shouldn’t ADPassMon be able to get the ticket without providing a password?
If you already have a TGT then it should not need to ask you for your password. Are you using Lion? I probably didn’t do enough Kerberos testing with it. In any case, can you paste ADPassMon’s console log output here from the next time you log in?
Yes, it’s 10.7.2, here’s console log output:
“1/2/12 10:51:52.773 AM ADPassMon: Running on OS 10.7.x
1/2/12 10:51:52.774 AM ADPassMon: Testing Universal Access settings…
1/2/12 10:51:54.494 AM ADPassMon: Already enabled
1/2/12 10:51:54.495 AM ADPassMon: Testing for Growl…
1/2/12 10:51:54.498 AM ADPassMon: Not running
1/2/12 10:51:54.529 AM ADPassMon: Testing for Kerberos ticket presence…
1/2/12 10:51:54.695 AM ADPassMon: No ticket found
1/2/12 10:59:32.053 AM ADPassMon: Ticket acquired
1/2/12 10:59:35.502 AM ADPassMon: Testing for Kerberos ticket presence…
1/2/12 10:59:35.539 AM ADPassMon: Ticket found and renewed
1/2/12 10:59:35.542 AM ADPassMon: Starting auto process…
1/2/12 10:59:35.551 AM ADPassMon: myDNS: 172.21.169.35
1/2/12 10:59:35.842 AM ADPassMon: mySearchBase: DC=xxxx,DC=xxxx
1/2/12 10:59:35.878 AM ADPassMon: Got expireAge: 0
1/2/12 10:59:36.649 AM ADPassMon: The new pwdSetDate (1.531626249741E+4)
1/2/12 10:59:36.650 AM ADPassMon: is < value in plist (1.531626269531E+4) so we ignore it
1/2/12 10:59:36.667 AM ADPassMon: daysUntilExp: -25.112026909723
1/2/12 10:59:36.668 AM ADPassMon: daysUntilExpNice: -25
1/2/12 10:59:36.669 AM ADPassMon: expirationDate: Thursday, December 8, 2011 8:18:17 AM
1/2/12 10:59:36.671 AM ADPassMon: Finished process
1/2/12 10:59:36.672 AM ADPassMon: in the loop
1/2/12 2:54:13.659 PM ADPassMon: Starting auto process…
1/2/12 2:54:13.764 PM ADPassMon: Script Error: {"Can’t make word 1 of \"\" into type text."} doesn’t match the parameters {theError, showErr} for errorOut_.
"
I've obfuscated the search base.
Can you check to see if you have a “/Library/Preferences/edu.mit.Kerberos” file? If so, you should delete it as it may conflict with the new config file that should be at “/etc/krb5.conf”. Another thing to look for in the /etc/kkrb5.conf file. Do the servers listed in the [realms] section use FQDNs or just hostnames? If the latter, try editing the file so it uses FQDNs.
Also, can you show me the (obfuscated) output of ‘klist -v’?
I finally got this information. There is no edu.mit.Kerberos file and krb5.conf is empty.
Here’s ‘klist -v’ output before entering the password in ADPassMon:
Credentials cache: API:1754061474:1
Principal: username@FULLY.QUALIFIED.DOMAIN.NAME
Cache version: 0
Server: krbtgt/FULLY.QUALIFIED.DOMAIN.NAME@FULLY.QUALIFIED.DOMAIN.NAME
Client: username@FULLY.QUALIFIED.DOMAIN.NAME
Ticket etype: aes256-cts-hmac-sha1-96, kvno 3
Ticket length: 1669
Auth time: Jan 20 10:34:36 2012
End time: Jan 20 20:34:36 2012
Ticket flags: pre-authent, initial, forwardable
Addresses: addressless
And here’s after entering password in ADPassMon and getting the ldap ticket:
Credentials cache: API:1754061474:1
Principal: username@FULLY.QUALIFIED.DOMAIN.NAME
Cache version: 0
Server: krbtgt/FULLY.QUALIFIED.DOMAIN.NAME@FULLY.QUALIFIED.DOMAIN.NAME
Client: username@FULLY.QUALIFIED.DOMAIN.NAME
Ticket etype: aes256-cts-hmac-sha1-96, kvno 3
Ticket length: 1688
Auth time: Jan 20 10:37:16 2012
Start time: Jan 20 10:37:25 2012
End time: Jan 20 20:37:25 2012
Renew till: Jan 20 20:39:17 2012
Ticket flags: pre-authent, initial, renewable, forwardable
Addresses: addressless
Server: ldap/host.fully.qualified.domain.name@FULLY.QUALIFIED.DOMAIN.NAME
Client: username@FULLY.QUALIFIED.DOMAIN.NAME
Ticket etype: aes256-cts-hmac-sha1-96, kvno 36
Ticket length: 1675
Auth time: Jan 20 10:37:16 2012
Start time: Jan 20 10:37:25 2012
End time: Jan 20 20:37:25 2012
Ticket flags: ok-as-delegate, pre-authent
Addresses: addressless
If you need more specific information you can contact me directly. Thanks!
What is different in the way ADPassMon is checking the password expiration of a users account than in Password Expiration Checker script. ADPassMon works just fine on 10.7.2 machines, but when I try to run your script with all my server configurations entered in all I get is an error that says “The command exited with a non-zero status”.
My goal is to be able to link your script to a status menu link to check the expiration status of a users AD password.
Password Expiration Checker is failing for two reasons. First, the AD plugin changed in Lion and domain information is now stored a bit differently. Consequently, the dscl command in the script needs to be updated. Second, AppleScript handles some numerical values differently, so the dscl command I mentioned needs further tweaking to handle that. I just did this update and it tested fine on my machine. Here’s a link: http://dl.dropbox.com/u/3967964/Password_Expiration_Checker%28lion%29.zip
That version works sorta…When the script was ran on our test user account it says the password will expire in -150123 days. The password expiration is set to expire every 90 days. Your saying that the dscl command needs tweaking is there a calculation I need to edit in the script?
ADPassMon is still showing the correct expiration date on that test user.
I just found an error in the script I gave you. Line 67 reads “if expireAge is greater than 0 then”. Please change it to “if expireAge is 0 then”. That will make it use the expiration value you supplied at the top of the script instead of trying to find it from AD.
In ADPassMon, what calculation was used to provide the actual time and date the password would expire, for instance, “On Tuesday April 17, 2012 4:22:34PM”. I would like to be able to add that into the applescript.
I just added that code into the script for you, just above the last “display dialog” section. Download here: http://dl.dropbox.com/u/3967964/Password_Expiration_Checker%28lion%29.zip
Thanks, everything works great.
Thanks! This seems to have fixed both issues.
I have noticed the following with our users. When they try and change password through ADPassmon they get the following error.
“Your system administrator may not allow you to change your password or there was some other problem with your password.”
Anybody seen this or know why it happens? Where would I look in a log file for the answer?
Steve,
ADPassMon uses GUI scripting to bring up the same password change dialog that a user would see if he/she went into System Preferences > Users & Groups and clicked the Change Password button. I assume your users will get the same error if they do that. Can you verify this and let me know?
Yes, they get the same response either way.
Which Mac OS version are you using? Regardless of version, you need to ensure that your Mac’s clocks are in-sync with the AD domain’s clocks. Also, have a user try running ‘kpasswd’ from the Terminal to change their password. It will likely fail there as well, but the errors returned should be more helpful.
Our environment is using AD PSO for password policies and I was wondering if this is why it keeps giving me an incorrect day count until expire.
I believe PSOs store password expiration information differently, and my app doesn’t know how to deal with them … yet? For now, try using the manual mode and enter the max password age manually. If you could, please open up Console.app and show me output from ADPassMon when you try to refresh the information.
I have something else for you to try that can help me get ADPassMon working with PSOs. Please run this command in the terminal (replace the w.x.y.z with the ip address of a domain controller and dc=example,dc=org with the proper domain info) and the and let me know what you get:
ldapsearch -LLL -Q -s base -H ldap://w.x.y.z -b "dc=example,dc=org" msDS-MaximumPasswordAge | awk '/msDS-MaximumPasswordAge/'
Here is the console output.
4/10/12 7:14:52.985 AM ADPassMon: Testing for Kerberos ticket presence…
4/10/12 7:14:53.374 AM ADPassMon: Ticket found and renewed
4/10/12 7:14:53.379 AM ADPassMon: Starting auto process…
4/10/12 7:14:53.380 AM ADPassMon: Found expireAge in plist: 10675197
4/10/12 7:14:53.430 AM dscl: received message with invalid client_id 3
4/10/12 7:14:53.454 AM ADPassMon: The new pwdSetDate (1.543365144139E+4)
4/10/12 7:14:53.455 AM ADPassMon: is ≥ value in plist (1.543365136719E+4) so we use it
4/10/12 7:14:53.465 AM ADPassMon: daysUntilExp: 1.067519009944E+7
4/10/12 7:14:53.465 AM ADPassMon: daysUntilExpNice: 10675190
4/10/12 7:14:53.466 AM ADPassMon: expirationDate: Wednesday, December 14, 31239 9:38:04 AM
4/10/12 7:14:53.469 AM ADPassMon: Finished process
Here is the output for the ldapsearch
Referral (10)
Additional information: 0000202B: RefErr: DSID-031007EF, data 0, 1 access points
ref 1: ‘local”’
Referral: ldap://local”/“dc=scentsy,dc=local”
If you need anything else, let me know. I would love to get this to work. Thanks
I just installed ADPassMon, and if I could get it to work, I would be in heaven. I need a little help figuring out where I’ve gone wrong if you don’t mind though. I have a Mac running OS X 10.7.3 that is connected to an Active Directory, but after I enter the Kerberos password, it says that my password will expire in -15439d. The date of the password expiration that it gives in the preferences is Wednesday, December 31, 1969 8:00:00 PM. Any ideas as to what might be hanging it up?
I’ll need some more info to help you. Please quit ADPassMon, then open Console.app. Select “All Messages” from the left, then type “ADPassMon” in the search field. Now launch ADPassMon and copy and paste all the output that appears after it launches.
Sorry that it took me so long to get this back to you. Thanks for any help you can give. Here’s the output from Console.app after starting ADPassMon:
4/12/12 10:38:38.725 AM ADPassMon: Running on OS 10.7.x
4/12/12 10:38:38.726 AM ADPassMon: Testing Universal Access settings…
4/12/12 10:38:38.748 AM ADPassMon: Already enabled
4/12/12 10:38:38.754 AM ADPassMon: Testing for Growl…
4/12/12 10:38:38.779 AM ADPassMon: Running
4/12/12 10:38:38.915 AM ADPassMon: Testing for Kerberos ticket presence…
4/12/12 10:38:39.009 AM ADPassMon: No ticket found
4/12/12 10:38:46.527 AM ADPassMon: Ticket acquired
4/12/12 10:38:48.004 AM ADPassMon: Testing for Kerberos ticket presence…
4/12/12 10:38:48.234 AM ADPassMon: Ticket found and renewed
4/12/12 10:38:48.239 AM ADPassMon: Starting auto process…
4/12/12 10:38:48.261 AM ADPassMon: myDNS: 192.168.1.1
4/12/12 10:38:48.492 AM ADPassMon: mySearchBase:
4/12/12 10:38:48.515 AM ADPassMon: Got expireAge: 0
4/12/12 10:38:48.630 AM ADPassMon: The new pwdSetDate (-1.34774E+5)
4/12/12 10:38:48.632 AM ADPassMon: is < value in plist (0.0) so we ignore it
4/12/12 10:38:48.640 AM ADPassMon: daysUntilExp: -1.544261027778E+4
4/12/12 10:38:48.641 AM ADPassMon: daysUntilExpNice: -15442
4/12/12 10:38:48.643 AM ADPassMon: expirationDate: Wednesday, December 31, 1969 8:00:00 PM
4/12/12 10:38:48.645 AM ADPassMon: Finished process
4/12/12 10:38:48.646 AM ADPassMon: in the loop
4/12/12 10:39:03.739 AM ADPassMon: Starting auto process…
4/12/12 10:39:03.755 AM ADPassMon: myDNS: 192.168.1.1
4/12/12 10:39:03.793 AM ADPassMon: mySearchBase:
4/12/12 10:39:03.817 AM ADPassMon: Got expireAge: 0
4/12/12 10:39:03.917 AM ADPassMon: The new pwdSetDate (-1.34774E+5)
4/12/12 10:39:03.918 AM ADPassMon: is < value in plist (0.0) so we ignore it
4/12/12 10:39:03.926 AM ADPassMon: daysUntilExp: -1.544261045139E+4
4/12/12 10:39:03.927 AM ADPassMon: daysUntilExpNice: -15442
4/12/12 10:39:03.928 AM ADPassMon: expirationDate: Wednesday, December 31, 1969 8:00:00 PM
4/12/12 10:39:03.930 AM ADPassMon: Finished process
Kevin, this console data shows me that mySearchBase is blank. ADPassMon gets this from your domain by contacting your primary DNS server, so it looks like 192.168.1.1 is not an AD server. If you have an AD DNS server in your list, try moving it to be the first server. Otherwise, you can use the manual mode and enter the password expiration age manually. Be sure to type Enter after putting in the number.
This may have something to do with the fact that I’m using a VPN. I changed the primary DNS server to the AD server, and here is the console output. Thanks again for your help!
4/12/12 11:38:48.350 AM loginwindow: Login items – LSOpenApplication returned error -10660, url=/Users/kevin.martin/.Trash/ADPassMon.app
4/12/12 11:38:48.350 AM loginwindow: Login items – LSOpenApplication returned error -10660, url=/Users/kevin.martin/.Trash/ADPassMon.app
4/12/12 11:38:52.756 AM ADPassMon: Running on OS 10.7.x
4/12/12 11:38:52.756 AM ADPassMon: Testing Universal Access settings…
4/12/12 11:38:53.842 AM ADPassMon: Already enabled
4/12/12 11:38:53.843 AM ADPassMon: Testing for Growl…
4/12/12 11:38:53.929 AM ADPassMon: Running
4/12/12 11:38:54.536 AM ADPassMon: Starting auto process…
4/12/12 11:38:54.537 AM ADPassMon: Found expireAge in plist: 90
4/12/12 11:38:54.822 AM ADPassMon: The new pwdSetDate (-1.34774E+5)
4/12/12 11:38:54.824 AM ADPassMon: is < value in plist (0.0) so we ignore it
4/12/12 11:38:54.839 AM ADPassMon: daysUntilExp: -1.535265201389E+4
4/12/12 11:38:54.841 AM ADPassMon: daysUntilExpNice: -15352
4/12/12 11:38:54.844 AM ADPassMon: expirationDate: Tuesday, March 31, 1970 8:00:00 PM
4/12/12 11:38:54.848 AM ADPassMon: Finished process
4/12/12 11:38:52.756 AM ADPassMon: Running on OS 10.7.x
4/12/12 11:38:52.756 AM ADPassMon: Testing Universal Access settings…
4/12/12 11:38:53.842 AM ADPassMon: Already enabled
4/12/12 11:38:53.843 AM ADPassMon: Testing for Growl…
4/12/12 11:38:53.929 AM ADPassMon: Running
4/12/12 11:38:54.536 AM ADPassMon: Starting auto process…
4/12/12 11:38:54.537 AM ADPassMon: Found expireAge in plist: 90
4/12/12 11:38:54.822 AM ADPassMon: The new pwdSetDate (-1.34774E+5)
4/12/12 11:38:54.824 AM ADPassMon: is < value in plist (0.0) so we ignore it
4/12/12 11:38:54.839 AM ADPassMon: daysUntilExp: -1.535265201389E+4
4/12/12 11:38:54.841 AM ADPassMon: daysUntilExpNice: -15352
4/12/12 11:38:54.844 AM ADPassMon: expirationDate: Tuesday, March 31, 1970 8:00:00 PM
4/12/12 11:38:54.848 AM ADPassMon: Finished process
4/12/12 11:38:53.842 AM ADPassMon: Already enabled
4/12/12 11:38:53.843 AM ADPassMon: Testing for Growl…
4/12/12 11:38:53.929 AM ADPassMon: Running
4/12/12 11:38:54.536 AM ADPassMon: Starting auto process…
4/12/12 11:38:54.537 AM ADPassMon: Found expireAge in plist: 90
4/12/12 11:38:54.822 AM ADPassMon: The new pwdSetDate (-1.34774E+5)
4/12/12 11:38:54.824 AM ADPassMon: is < value in plist (0.0) so we ignore it
4/12/12 11:38:54.839 AM ADPassMon: daysUntilExp: -1.535265201389E+4
4/12/12 11:38:54.841 AM ADPassMon: daysUntilExpNice: -15352
4/12/12 11:38:54.844 AM ADPassMon: expirationDate: Tuesday, March 31, 1970 8:00:00 PM
4/12/12 11:38:54.848 AM ADPassMon: Finished process
4/12/12 11:38:53.842 AM ADPassMon: Already enabled
4/12/12 11:38:53.843 AM ADPassMon: Testing for Growl…
4/12/12 11:38:53.929 AM ADPassMon: Running
4/12/12 11:38:54.536 AM ADPassMon: Starting auto process…
4/12/12 11:38:54.537 AM ADPassMon: Found expireAge in plist: 90
4/12/12 11:38:54.822 AM ADPassMon: The new pwdSetDate (-1.34774E+5)
4/12/12 11:38:54.824 AM ADPassMon: is < value in plist (0.0) so we ignore it
4/12/12 11:38:54.839 AM ADPassMon: daysUntilExp: -1.535265201389E+4
4/12/12 11:38:54.841 AM ADPassMon: daysUntilExpNice: -15352
4/12/12 11:38:54.844 AM ADPassMon: expirationDate: Tuesday, March 31, 1970 8:00:00 PM
4/12/12 11:38:54.848 AM ADPassMon: Finished process
It’s still using some old info, so you should open up the prefs and hit the “Revert to Defaults” button in on the Reset tab.
Okay, I did that. Here’s the output now:
4/12/12 12:32:48.878 PM ADPassMon: Running on OS 10.7.x
4/12/12 12:32:48.881 PM ADPassMon: Testing Universal Access settings…
4/12/12 12:32:49.496 PM ADPassMon: Already enabled
4/12/12 12:32:49.499 PM ADPassMon: Testing for Growl…
4/12/12 12:32:49.519 PM ADPassMon: Running
4/12/12 12:32:49.708 PM ADPassMon: Testing for Kerberos ticket presence…
4/12/12 12:32:49.751 PM ADPassMon: No ticket found
4/12/12 12:32:56.440 PM ADPassMon: Ticket acquired
4/12/12 12:32:58.129 PM ADPassMon: Testing for Kerberos ticket presence…
4/12/12 12:32:58.329 PM ADPassMon: Ticket found and renewed
4/12/12 12:32:58.332 PM ADPassMon: Starting auto process…
4/12/12 12:32:59.275 PM ADPassMon: mySearchBase: DC=sunopta,DC=net
4/12/12 12:32:59.659 PM ADPassMon: Got expireAge: 90
4/12/12 12:32:59.828 PM ADPassMon: The new pwdSetDate (-1.34774E+5)
4/12/12 12:32:59.829 PM ADPassMon: is < value in plist (0.0) so we ignore it
4/12/12 12:32:59.838 PM ADPassMon: daysUntilExp: -1.535268957176E+4
4/12/12 12:32:59.839 PM ADPassMon: daysUntilExpNice: -15352
4/12/12 12:32:59.841 PM ADPassMon: expirationDate: Tuesday, March 31, 1970 8:00:00 PM
4/12/12 12:32:59.842 PM ADPassMon: Finished process
4/12/12 12:32:59.843 PM ADPassMon: in the loop
4/12/12 12:33:02.291 PM ADPassMon: Starting auto process…
4/12/12 12:33:02.293 PM ADPassMon: Found expireAge in plist: 90
4/12/12 12:33:02.420 PM ADPassMon: The new pwdSetDate (-1.34774E+5)
4/12/12 12:33:02.422 PM ADPassMon: is < value in plist (0.0) so we ignore it
4/12/12 12:33:02.431 PM ADPassMon: daysUntilExp: -1.535268960648E+4
4/12/12 12:33:02.443 PM ADPassMon: daysUntilExpNice: -15352
4/12/12 12:33:02.444 PM ADPassMon: expirationDate: Tuesday, March 31, 1970 8:00:00 PM
4/12/12 12:33:02.446 PM ADPassMon: Finished process
Just as an FYI, I think the date increased to March 31 because I tried doing what you said earlier and put a manual date of "90" in the preferences field. I have since done the "revert to defaults" option though.
I have been trying to use manual mode but after I have a password change it will not reset the expiration back to the manual entry of 90 days until I click “Re-Check Expiration”
Any ideas?
To keep chattiness to a minimum ADPassMon only communicates with AD periodically — which is twice a day or anytime the computer wakes or restarts.. Since it does not handle the password change itself, it won’t learn that the password changed until the next time it runs. This happens regardless of what mode you’re using.
Im now using Quest Authentication Services for domain authentication and up till now I’ve used manual mode to set the password policy but now manual mode doesn’t even work. I set it to 90 and hit enter and it gives me a -15365 days which shows the password expiring in 1970.
I just read through the Quest Authentication Services 4.0 Mac Admin Guide and see that it uses its own (non-Apple-native) Directory Services plugin. Currently, ADPassMon will only work if your Mac can communicate directly with your AD domain server(s) to get data on when your password was last changed. Manual mode is useful only for supplying the maximum password age if it can’t be obtained automatically. There may be a simple workaround I can implement, though.
Can you try the following two commands and show me the results? This will operate on the currently logged-in user, but you can substitute “$USER” for any username. The first command is the one I’m currently using. The second command is an alternate form that may work better for you.
dscl localhost read /Search/Users/$USER pwdLastSet
dscl /Search read /Users/$USER pwdLastSet
Also, please run ‘klist’ in the terminal and let me know if it shows an active kerberos ticket.
Here you go.
temp-mac:bin jcollins$ dscl /Search read /Users/jcollins pwdLastSet
No such key: pwdLastSet
No such key: pwdLastSet
temp-mac:bin jcollins$ dscl localhost read /Search/Users/jcollins pwdLastSet
No such key: pwdLastSet
No such key: pwdLastSet
temp-mac:bin jcollins$ klist
Credentials cache: API:62104299
Principal: jcollins@SCENTSY.LOCAL
Issued Expires Principal
Apr 25 10:22:27 Apr 25 20:19:56 krbtgt/SCENTSY.LOCAL@SCENTSY.LOCAL
Apr 25 10:22:28 Apr 25 20:19:56 ldap/corp-dc2.scentsy.local@SCENTSY.LOCAL
temp-mac:bin jcollins$
Your issue may be solved simply by ensuring that the Quest Authentication service binding is added to your search policy.
I just checked and it is in my search policy. Hmm.
I thought manual bypassed all authentication though. You would think it will work regardless.
It’s not an authentication issue, but a lookup issue. The “pwdLastSet” value lives in AD and is not cached locally. Using the native AD plugin, as long as you’re bound to AD, you can look up that value.
It does have an entry in the search policy called /VAS. I’m really hoping there is a workaround. We are going to quest because of the GPO control but losing ADPassMon in our environment will be a major subtraction from the benefits of quest. Thanks
Oh Okay,
I just didn’t wait long enough till after the change to have it auto update back to the 90 days I entered in manually.
Thanks. This will have to be the solution till PSO’s are supported. Appreciate the quick response.
It would be great to allow for some additional modifications. In our environment we use PGP and PGP does not do SSO on mac. It would be nice to have a plug-in that could also update the password for PGP Desktop so it could stay in sync as well.
Grant, I’m hesitant to add support for third-party products, but I’m downloading the trial version of PGP Desktop 10.2 to see if it’s workable.
Did you ever have any luck with Quest? I’m still in the dark with no working solution for ADpassmon. I tried everything I could think of with the search policy to no avail.
Sorry, Josh. I wasn’t able to get any further with Quest.
Hmm. How hard would it be to take all the authentication code out and just put a fixed 90 day timer that will count down and when you change your password or it expires it just resets to 90?
I’m desperate for some kind of notification especially for our file vault users.
Let me know if there is anything I can do! I appreciate it.
A fixed 90-day timer would not be trustworthy. If a user changed their password with anything other than ADPassMon — even the Accounts pref pane — the timer would reset. ADPassMon needs to query the directory to be sure it’s displaying correct info.
I think in your case, you should get assistance from your site’s Windows admins to send out email alerts to users whose passwords will expire soon. There are plenty of free scripts out there that cam do this.
Seems to be broken on Lion 10.7.4; reporting a -57 day password expiration. Standard Lion install bound against a 2003 domain.
Also reported that there wasn’t a ticket when the Ticket Viewer is showing a valid ticket.
Thanks for letting me know. I’ll have a look.
I’m not seeing this problem on my end. Can you please send me some the log output when you choose “Re-check Expiration”? To do this, first open /Applications/Utilities/Console.app, select All Messages from the list on the left, then type “ADPassMon” in the search field in the upper right. Now choose Re-check Expiration from the ADPassMon menu and copy the last block of entries from the console and paste it here.
We also have some issues using it with 10.7.4. Every time a AD User logs in AdPassMon is asking if the user would like to create a Kerberos-Ticket – but we already got one before. Any news on this Issue? We just downloaded the last Version (1.6).
Can you send me your console log output, like I asked DeepCrow?
Hi Peter,
i was just about to create the log for you, but then i read some other comments about how to set the manual value and then press tab or enter. after i did that also the question about the kerberos ticket never showed up again. So – this is solved – thanks!
Now i see another issue – if i use the menubar-menu hand choose “Change Password…” i can see the Systempreferences starting in the Dock, but no window appears. If i click on Systempreferences in the dock, the Window appears and shows the user-settings where i could change the password. is that the expected behavior?
That’s definitely not the expected behavior. I took a look at my code and changed it so the prefs pane pops to the foreground before the password change dialog slides down. Look for this fix in version 1.7.
AdPassMon can’t communicate with Growl for some reason. I’ve got Growl 1.3 installed with ADPassMon 1.7 on Mac OS X Server 10.7.4. Here are the relevant log entries:
8/1/12 2:58:42.888 PM ADPassMon: Testing for Growl…
8/1/12 2:58:42.906 PM ADPassMon: Running
8/1/12 2:58:42.990 PM ADPassMon: *** -[ADPassMonAppDelegate applicationWillFinishLaunching:]: Growl got an error: Can’t continue «event register». (error -1708)
8/1/12 3:00:22.715 PM ADPassMon: *** -[ADPassMonAppDelegate applicationWillTerminate:]: unrecognized function releaseStatusItem. (error -10000)
Any idea what may be going on here?
Can you look at the Applications list in your Growl prefs pane and see if ADPassMon is listed? If it is, please remove it, then quit and restart ADPassMon and try it again. Beyond that, I’m not sure I can help. I’ve made no changes to the Growl code since version 1.4 and it has been working well for me.
[Admin Note: I have not tried this app and do not endorse it, but I’m allowing the comment as it could be useful to some.]
I would like to introduce iCorpPass – Windows Password Reminder and Change for iPhone and iPad.
Here is the link http://itunes.apple.com/us/app/windows-domain-password-change/id545217155?mt=8
Sam
I’ve been using your applescript to tell when your AD account password expires on 10.7 and it works flawlessly. I recently started using 10.8, now when I check my AD account password it comes up with this error “Can’t make “8 (12A269)” into type integer.” This is the line its getting stuck on:
set osVersion to (do shell script “system_profiler SPSoftwareDataType | awk -F. ‘/System Version/ {print $2}'”) as integer
— get the value of ‘a’ in “Mac OS X 10.a.b”
Suggestions?
I’m not using 10.8 yet, so I’ll need your assistance. Can you run ‘system_profiler SPSoftwareDataType | awk ‘/System Version/’ in the terminal and paste the output here?
Here is a few things I tried.
Command:
system_profiler SPSoftwareDataType | awk ‘/System Version:/’
Output:
System Version: OS X 10.8 (12A269)
—————
Command:
system_profiler SPSoftwareDataType | awk /System Version/
Output:
awk: non-terminated regular expression System… at source line 1
context is
>>> <<>> <<<
awk: bailing out at source line 1
Ok, I’ve have the awk modification that will fix it. Replace this line:
set osVersion to (do shell script "system_profiler SPSoftwareDataType | awk -F. '/System Version/ {print $2}'") as integer
with this:
set osVersion to (do shell script "system_profiler SPSoftwareDataType | awk -F. '/System Version:/{sub(" \\(.*","");print $2}'") as integer
Anyway to add a notification that will remind users to update their mobile device passwords when their AD account password is updated?
example:
User receives notification to update AD password on Mac.
User forgets to update mobile devices password.
Now user is unable to receive mail on the mobile device until password is updated.
Anyway for ADPassMon to send a quick reminder alert to the user reminding them to update their mobile devices as well?
I don’t normally turn down feature requests, but a mobile device password change reminder is a bit outside the scope of my app. I’d suggest documenting an official password change procedure or your site and making sure that users are aware of it. Then you have something to point them to when some inevitably forget to update their mobile device passwords.
I total understand and agree with your suggestion. A customer asked that I inquiry. Thanks again for your response.
Hi pmbuko- I love ADPassmon and use it all the time, but I’ve got a problem with the launch agent I’m deploying with it. About 20% of the time when a user first logs in, OS X pops up a screen asking the user to locate System Events.app. Once the dialog has been pointed to Coreservices and the System Events application, ADPassmon pops up.
Like I said, though, this doesn’t happen on every machine I image, only about 20%. It only happens once if at all, and if it doesn’t happen on your first login, it won’t ever happen.
Here’s the contents of the launchagent I’m using:
KeepAlive
SuccessfulExit
Label
com.wordpress.yourmacguy.adpassmon
ProgramArguments
/Applications/ADPassMon.app/Contents/MacOS/ADPassMon
Any ideas?
Nick, the dialog asking for the location of System Events comes up because of an issue with AppleScript, not your launch agent. I have a hunch that System Events hasn’t made it into the launch services database on the affected systems and that’s the reason AppleScript is asking you to find it.
One thing you can try is simply launching System Events once *before* you launch ADPassMon. It should be invisible to the user and make it known to the OS so that ADPassMon doesn’t ask you to locate it.
I’m trying to do that by running an ‘open /System/Library/CoreServices/System\ Events.app/’ command in a login script, but I’m still getting the prompt. What would be the best way to force System Events to launch before the launchagent triggers?
I’m going to try rebuilding the launchservices database with this command in the login script instead:
`sudo find /System/Library/Frameworks -name lsregister` -kill -seed
Hopefully that will work. I don’t have any other suggestions.
unfortunately, I’m still getting the ‘Where is system events’ dialog. I also tried using a 10.8 server configuration profile with a login item instead of the launch agent, got the same results . . . .
hmm, looks like the site interpreted the tags from the XML. here’s a pastie link to the actual code:
http://pastie.org/4716659
Question and possible request – Can this app be repackage with a script I have. As we all know if macs are in an AD environment they are also required to rebuild / delete items in their keychain. I have a script that does a search of all keychain items from their old password and changes it to there new password / then changes their ad password / then reboots. If i give you the script can you put this in place of the Change Password item in your drop down box?
I won’t put it into the main version, but I could fork the project and create a version for you that includes your script. I’ll contact you via email.
Hi,
I would love to get my hands on Gregs Script or to see this forked..did anything happen in this regards ?
often the case that the old ad credentials have been saved in the keychain for non kerberised servers ie network printing, basic forms etc so users change their password, but still have to go through and update keychain passwords which the user is incapable of doing and and takes 5 minutes of support calls every password change despite guides been available
Hi Pmbuko i see a hersheys modification fork is this possibly with the includsion of gregs AD Old/New keychain password update script?
Yes, that was the reason for the fork.
also, where is support for 10.8 at?
Many thanks
Actually, I now have a beta version for 10.8 that I’ve modified to use the Notification Center. The app isn’t officially signed, so it won’t run if your security settings prevent unsigned apps from launching. I’m considering getting a proper Apple Developer account to remedy this. Looks for version 1.8 of ADPassMon to be released this week.
Champion!
I am trying to make it so my non administrative users can not access the preferences or push the reset button. I ran the defaults write org.pmbuko.ADPassMon prefsLocked true through ARD Unix command but they are still able to push the reset button. Is this by design or am I doing it wrong?
I’ll update the code so the reset tab also locks.
Joseph,
The prefsLocked setting already works as you want it to. When you run the ‘defaults write org.pmbuko.ADPassMon prefsLocked true’ command via ARD, make sure you run it as the current console user, not as root. Also, you will need to quit and re-launch ADPassMon for the change to take effect.
That was it. Thank you much. Your support has been excellent. Apple should learn a thing or two from you.
Thanks for the quick response. Is that something that will be done soon? Not being impatient just wanting to know whether I should wait in deploying it.
I’ll try to get it done today and give you a link to download it.
Having two issues here: Logged in as normal AD user and on launch I am getting “For best performance, ADPassMon requires that ‘Access for assistive devices’ be enabled” message. This I thought only occurs for Admins? And what is the command to turn on Assistive Devices from the cmd line?
The other problem is this message: No Kerberos ticket was found. Do you want to renew it? When users login they mount shares from a Windows server so they have to have a ticket or the shares wouldn’t mount. Ticket Viewer shows that the user has a ticket.
I have a LaunchAgent in /Library/LaunchAgents that starts a script in /sbin that runs:
/Applications/ADPassMon.app/Contents/MacOS/ADPassMon
Trying to get it so ADPassMon.app opens and doensn’t bother the user.
Thanks,
Dan
I’m about to leave for a two week vacation and can’t look into this now, but let me know what OS you’re using. Also, can you open up Console.app, filter the output of ‘All Messages’ for ‘ADPassMon’, save a copy and email it to me? (Send to my username at gmail)
After I install the application this is what I run through ARD. This should help you out.
Run as Root
sudo touch /private/var/db/.AccessibilityAPIEnabled
Run as Console user while user is logged in
defaults write org.pmbuko.ADPassMon prefsLocked true
defaults write loginwindow AutoLaunchedApplicationDictionary -array-add ‘{Path=”/Applications/ADPassMon.app”;}’
Thanks for the tips, Joseph!
Thanks Joseph……I looked before on how to turn on Accessibility and couldn’t find out how to do it. Will look into that! The other commands I can’t use though for console as users have a temp home on login. Need to set the pref file in the user template and seems to be giving me problems if I set the file up with limited keys. Was only putting in growlEnabled and PrefsLocked and it was displaying a wild number and getting kerberos errors on login about not having a ticket. Here is what I have now in the org.pmbuko.ADPassMon.plist pref file and think its working, adding expireAge seems to have fixed the issue for some reason (Hopefully the following displays correctly):
expireAge
180
growlEnabled
prefsLocked
Hello,
I also had the issue with ADPassMon telling me that my password will expire in -15716d. And indeed:
$ /usr/bin/dscl localhost read /Search/Users/$USER PwdLastSet | /usr/bin/awk ‘/LastSet:/{print $2}’
No such key: PwdLastSet
Looking at /Search/Users/$USER, I discovered the SMBPasswordLastSet value:
$ /usr/bin/dscl localhost read /Search/Users/$USER SMBPasswordLastSet | /usr/bin/awk ‘/LastSet:/{print $2}’
129991796360808927
So I modified the source code of ADPassMon (ADPassMonAppDelegate.applescript) from:
set my pwdSetDateUnix to (((do shell script “/usr/bin/dscl localhost read /Search/Users/$USER pwdLastSet | /usr/bin/awk ‘/LastSet:/{print $2}'”) as integer) / 10000000 – 1.16444736E+10)
to:
set my pwdSetDateUnix to (((do shell script “/usr/bin/dscl localhost read /Search/Users/$USER SMBPasswordLastSet | /usr/bin/awk ‘/LastSet:/{print $2}'”) as integer) / 10000000 – 1.16444736E+10)
And now, ADPassMon is working fine.
This is my two cents, I hope it can help…
Thanks for the detailed feedback, Jay. When I get back from vacation I’ll take a look at the code and update ADPassMon.
In some environments, this call to dscl may return multiple values (SMBPasswordLastSet can appear under dsAttr and a few other places). This will cause this command to fail as it’ll try converting the multiple lines returned into an integer. All you really need to get is the FIRST match. This is more reliable:
set my pwdSetDateUnix to (((do shell script “/usr/bin/dscl localhost read /Search/Users/$USER SMBPasswordLastSet | /usr/bin/grep -m 1 SMBPasswordLastSet | /usr/bin/awk ‘/LastSet:/{print $2}’”) as integer) / 10000000 – 1.16444736E+10)
Thanks for catching this. Instead of modifying the shell command, I inserted “first word of” right before the triple open parentheses. I’ll include this fix in the next release and credit you in the about box.
Right-o; old-school unix shell guy here — just spinning up on AppleScript — so I tend to default to the sed/grep/awk tricks. :)
Glad to help out.
Does Adpassmon support languages besides english? I’ve got a user in norway having some problems when his mac is set to use norwegian as the default system language . . . ADpassmon launches, but the menulet never appears.
Nick, ADPassMon is only available in English. I don’t have the resources to provide localization bundles for other languages. That being said, I’d like to see what the console log shows when the app is launched. Could you get that and paste it here?
Hi, your App rocks!!!! Just a quick question – Would be possible to display a message for the user remind him of the password policy in place – i.e minimum of eight characters, with at least one number and uppercase letter??
Thank you
Thanks for the compliment, Bruno. Different sites will have different complexity requirements, and while I could modify the app to include a custom reminder screen, I don’t think that would be the best way to remind users of password complexity requirements.
Hi Peter,
Many thanks for the quick reply. Would it be very hard / complicated to do so? My ideas was to have a settings in preferences that allows IT people to manually insert text that states the password policy in place in the “Change password box” so when user needs to change the password he /she knows the password policy.
We do have a few users that are very “forgetful”
Thanks in advance!
My app uses the native OS X change password box, so I wouldn’t be able to modify it.
Hi Peter,
Many thanks on getting back to me so quickly. Sorry to be so persistent but can would be possible to make the ADMon Preferences text stating ” Your password will expire on ” editable so we can pass the password policy to the user information to the user by Growl?
Example – Your password will experience on xxx day – Please ensure that when changing the password that it has 8 characters, with 1 number, one uppercase?
Many thanks – your support has been great!
Well, you were just persistent enough. :) Please check your email in a little bit for a link to a version I created for you that includes a password policy reminder. I’ll cover it in more detail in the email.
I think that’s a pretty good idea. Why not make it a full release?
I’m considering it. I’ll wait for your feedback, though.
I didn’t wait for any feedback. I released it as version 1.9.
Can you please support 10.9? Love this app, thanks so much.
I should have a version that supports OS X Mavericks before the public release. I can’t promise anything yet, though.
Any update on support for 10.9? Only issue I see is with the changes to Accessibility.
Alan–
Alan, I didn’t quite made the public release deadline, did I…. I will move it up my priority list and try to get it out the door soon.
Accessibility is the biggest change that affects ADPassMon. Security had been tightened and now each individual app that wants to use UI scripting needs to be given permission. Unless I can find a way to do it programmatically, it’ll have I be a manual process in 10.9.
Sounds good… I understand it may be difficult to do it programmatically. It would be nice at least that when prompted to enable “assistive devices” that it takes you to the correct PrefPane where the user can allow access. Although that requires Admin rights by default…
Thanks again for all your work on this!
Alan–
In addition to requiring admin rights, opening the right pref pane programmatically requires assistive devices to already be enabled… Catch 22? :)
This might be a relevant thread…
http://stackoverflow.com/questions/17693408/enable-access-for-assistive-devices-programmatically-on-10-9
I am able to programmatically add it via cli via
sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db “INSERT INTO access VALUES(‘kTCCServiceAccessibility’,’org.pmbuko.ADPassMon’,0,1,1,NULL);”
it will fail if it pre-exists so per the thread…
sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db “delete from access where client=’org.pmbuko.ADPassMon’;”
Good find. Thanks for sharing. Seems a little hacky, but promising. I’ll test it this weekend.
Got it working. https://yourmacguy.wordpress.com/2013/10/26/adpassmon-updated-to-1-9-1/
Peter:
A quick thought. To determine initial LDAP server, your code uses scutil -dns to pull the first nameserver and then attempts to connect to that to get the defaultNamingContext for the successive LDAP queries for password age. This is problematic in many cases: 1) the user is on a network where the DNS resolvers are not hosted on Windows but are replicas or hidden master, 2) the DNS resolver is actually a virtual address forwarding to a DNS pool, 3) DNS is deployed as a role on on non DC server, or 4) the nameserver address is tied to a VPN stub resolver and not an on-network resolver.
A better way to determine initial naming context is to do the following:
set my myLDAP to (do shell script “/usr/sbin/dsconfigad -show | /usr/bin/awk ‘/Active Directory Domain/ {print $5}'”) as text
and then use the extracted value (the domain that the machine belongs to) as the host for ldapsearch. This will of course fall to DNS and may query outside of your AD site, but this should still work in all of those scenarios above. It actually wouldn’t be too difficult to select a particular LDAP server _in_ your AD site, but this would need another ldapsearch lookup and DNS query for the correct SRV record.
Anyway, just my two cents. Do you accept external commits to any particular branch of your Github repository?
Joel, I can add you as a collaborator. I’m putting my latest changes into the mavericks branch, which I plan to release around the time that Apple releases Mac OS 10.9. Do you have a github account?
I do. Username is “joelmoses”.
If you like, I can branch and perhaps add AD site awareness capability and a few other things.
I’m having trouble starting the application. I’m getting an error registering with Growl. Here’s the last few lines in Console.
8/28/13 1:32:38.165 PM [0x0-0x58f58f].org.pmbuko.ADPassMon: objc[6856]: Object 0x10011d980 of class NSPathStore2 autoreleased with no pool in place – just leaking – break on objc_autoreleaseNoPool() to debug
8/28/13 1:32:38.165 PM [0x0-0x58f58f].org.pmbuko.ADPassMon: objc[6856]: Object 0x10011dc10 of class NSPathStore2 autoreleased with no pool in place – just leaking – break on objc_autoreleaseNoPool() to debug
8/28/13 1:32:38.203 PM [0x0-0x58f58f].org.pmbuko.ADPassMon: objc[6856]: Object 0x100513f00 of class __NSArrayM autoreleased with no pool in place – just leaking – break on objc_autoreleaseNoPool() to debug
8/28/13 1:32:38.203 PM [0x0-0x58f58f].org.pmbuko.ADPassMon: objc[6856]: Object 0x100513f30 of class __NSCFString autoreleased with no pool in place – just leaking – break on objc_autoreleaseNoPool() to debug
8/28/13 1:32:41.142 PM ADPassMon: Running on OS 10.7.x
8/28/13 1:32:41.143 PM ADPassMon: Testing Universal Access settings…
8/28/13 1:32:43.971 PM ADPassMon: Already enabled
8/28/13 1:32:43.972 PM ADPassMon: Testing for Growl…
8/28/13 1:32:43.987 PM ADPassMon: Running
8/28/13 1:32:44.127 PM ADPassMon: *** -[ADPassMonAppDelegate applicationWillFinishLaunching:]: Growl got an error: Can’t continue register. (error -1708)
What version of Growl are you using? Can you save the code found at this link into a new applescript and try to run it from Script Editor?
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
growl_register
hosted with ❤ by GitHub
I was using Growl version 2.1, which I found had an issue with Automator actions. Upon updating Growl to 2.1.1, I am able to register the application it is running successfully. The last line in my console above is exactly what was output from the Gist you sent.
So you updated to 2.1.1 today and that fixed the problem?
Yes! Thanks.
I would love it if ADPASSMON did NOT change my boot disk icon. Is this an option? How can I fix this?
Thank you,
Andy
I don’t believe ADPassMon is capable of changing your boot disk icon. Can you explain how you came to believe ADPassMon is doing this?
Sure. Thank you.
After installing ADPassMOn, When I boot my mac and hold the Option key, I get two icons. One is my HD, one is the Recovery Partition. The HD now has the words ADPassMon written on it. Try it. It’s disconcerting.
My disk icons appear normal in the Startup Manager (boot with Option key). Is your main HD icon showing up *as* the ADPassMon icon (https://yourmacguy.files.wordpress.com/2011/04/icon1.png?w=171&h=263)? Do you use a custom icon for the drive in the Finder? I was able to find this post on Apple’s discussion forum talking about the same issue: https://discussions.apple.com/thread/2138545
Yes, my main HD appears as a white drive icon with the the ADPassMon icon on top of it, but only when I Option boot. My macs HD icon has not been modified by me and shows as normal when mounted on the desktop.
That’s the icon you see when you mount the ADPassMon .dmg. I can tell you that it’s not ADPassMon’s fault this is happening — it’s just a coincidence. I would try repairing permissions on the disk. If you have DiskWarrior, I’d try running that on the disk, too.
Hi. I just installed ADPassMon on a 10.8 system. It shows “?” in the menu bar and I see this in the console:
10/29/13 4:01:56.380 PM ADPassMon[4977]: Starting manual process…
10/29/13 4:01:56.382 PM ADPassMon[4977]: Found expireAge in plist: 90
10/29/13 4:01:56.643 PM ADPassMon[4977]: Script Error: Can’t make “130268609830015509
130207927662076121” into type integer.
Which version of ADPassMon are you using? If you’re using 1.9.1, can you try 1.9 and see if you get the same error? I haven’t tested my newest version as thoroughly as older ones.
We recently made a change to our password policy so the passwords expire now, and I found ADPassMon as something that might help for our growing Mac users. Testing it out, it gives me 41d as the time but our policy is 180 days and when I try to change the password I get a message that it doesn’t meet the requirements when it should. I have refreshed the Kerberos ticket and I tried using the Apple generated password from Users & Groups, but still got the error message. Any ideas for what I should check?
ADPassMon doesn’t control the password complexity requirement, so I’m not sure why you’re unable to change your password. as for reporting the wrong expiration time, I would try using the Manual mode and putting in 180.
Hi. Just starting testing this out last week for use in my environment but, it seems like we’ve a got AD weirdness, too. Running 1.9.1. It looks like the last password set date is being set as the expiration date and I end up with a negative number.
Here’s the log:
11/4/13 9:19:11.570 AM ADPassMon[48903]: Running on OS 10.9.x
11/4/13 9:19:11.670 AM ADPassMon[48903]: Testing Universal Access settings…
11/4/13 9:19:12.087 AM ADPassMon[48903]: Testing for Kerberos ticket presence…
11/4/13 9:19:12.177 AM ADPassMon[48903]: Ticket found and renewed
11/4/13 9:19:12.181 AM ADPassMon[48903]: Starting auto process…
11/4/13 9:20:33.508 AM ADPassMon[48903]: mySearchBase:
11/4/13 9:21:52.463 AM ADPassMon[48903]: Got expireAge: 0
11/4/13 9:21:52.728 AM ADPassMon[48903]: The new pwdSetDate (1.598066247116E+4)
11/4/13 9:21:52.786 AM ADPassMon[48903]: is ≥ value in plist (1.598066210938E+4) so we use it
11/4/13 9:21:52.817 AM ADPassMon[48903]: daysUntilExp: -32.936047354384
11/4/13 9:21:52.835 AM ADPassMon[48903]: daysUntilExpNice: -32
11/4/13 9:21:53.093 AM ADPassMon[48903]: expirationDate: Wednesday, October 2, 2013 at 10:53:58 AM
11/4/13 9:21:53.101 AM ADPassMon[48903]: Finished process
11/4/13 9:21:53.121 AM ADPassMon[48903]: in the loop
If I look for SMBPasswordLastSet through dscl, I get a timestamp of 130252028375085808 which converts into the expiration date above.
Looks like it can’t find your domain’s search base, which has the form ‘dc=domain,dc=com’. Does your AD domain happen to use a subdomain? In any case, setting ADPassMon to manual mode and supplying the expiration age should avoid the error.
We actually have two domains in our forest, but when I tried setting it to manual last week, it wouldn’t take and kept resetting back to auto. Today, though, it decides to work.
Yeah, you have to hit enter after entering the manual expiration value to make it stick. I should be explicit about that.
First I’d like to say thanks for a great tool! We just started testing with it on 10.8 & 10.9, and everything is great except it does not open the sys prefs > users&groups > change password pane when clicking “Change Password” in the drop down menu. I did verify that assistive devices are enabled in 10.8, while in 10.9, I do not see ADPassMon in the Accessibility pane. What am I missing? TIA!!
Can you try using ADPassMon_v1.9 with OS 10.8 and let me know if it that works better for you? (download link: https://dl.dropboxusercontent.com/u/3967964/ADPassMon.v1.9.dmg)
As for 10.9, are you talking about the Accessibility item that’s found in the Privacy tab of the Security & Privacy pane? I tried to make ADPassMon v1.9.1 add itself to that pane and it was working when I tested it, but perhaps it’s not working as well as it should.
1.9 works flawlessly with 10.8 :D Any suggestions for 10.9 and 1.9.1 to try? Thank you!
Nothing yet. I haven’t had time to look it since my paying job has kept me really busy lately.
Hey! Can you change or add a preference to have the change password menu choice to to the password change in the newest ticket rather than the user pref pane?
Would you mind taking a look at an issue I am having? Even when using your tool, and choosing change password, the option in system preferences is greyed out.
https://discussions.apple.com/message/23869036#23869036
ADPassMon can’t bypass a disabled change password functionality. Are the Parental Controls enabled for these accounts? That’s where you can find restrictions on the ability for users to change their passwords.
I don’t see it enabled. “There are no user accounts to manage.”
Did some more looking around. I have a configuration profile installed. Even tho the profile allows the user to change the password, the option is still disabled. Removing the profile allows the user to change the profile. That being said the apple password expiration prompt still is not popping up on the login screen.
Just wanted to update you and others that may have this problem. There IS a bug in Mavericks that breaks login window password expiration notices when the system authenticate against active directory. See the below response from our AppleCare Enterprise Engineer.
“Thank you for the clarification. I’ve just tested and have been able to reproduce this behavior here with Mavericks. This certainly isn’t the expected behavior, so I’ve filed a report with Product Engineering to see if we can determine why this is occurring.
Unfortunately, I don’t have a workaround for you to force the prompt to appear; I’ll need to work with Product Engineering to see if I can develop one. In the interim, however, there is well-regarded third-party tool (under MIT license) that serves to give password expiration warnings that might suit your needs. That tools is ADPassMon, found here: https://yourmacguy.wordpress.com/adpassmon/.”
Thanks for sharing, Wes. If only I’d released this as a paid app…. :)
We are trying to add a kill process for adpassmon before the updated installer runs. In Activity Monitor the process name is blank. Is there a way to resolve this?
We have solved one issue, in the info.plist the CFBundleDisplayName string was blank. Added ADPassmon to the string and restarted the App and it now show in Activity Monitor correctly. The issue we are still having is how to kill the process that doesn’t have the the name added to the string.
Which version are you using? I’ll try to release a fix for that soon.
We are using 1.9, upgrading to 1.9.1.
I’ve been swamped at work lately and haven’t had any free time to devote to this. I’ll try to get to it next week.
I just released 1.9.2, which fixes the missing CFBundleDisplayName string.
Hey man, looking forward to utilizing this at work! Great tool! We have a handful of macs running Mountain Lion. I wanted to use the pwPolicy feature, but whenever I assign any value and then log off/on again, it flushes all of my settings and prompts me to download a new Kerberos ticket. I have tried this on 1.9, 1.9.1, 1.9.2, all with the same results. Also, I can confirm that v1.9.2 doesn’t open up Users & Groups when selecting change password from ADPassMon (it is working in both 1.9 & 1.9.1 however)
Thanks for letting me know. I’ll take a look and hopefully get a fix out soon.
A correction to my first post; my problem was that defaults wasn’t updating the plist file correctly, but once I switched over to a plist editor, things stopped breaking. I’m not running into the flushing of prefs anymore on any version of the program. Here’s what I found though…
(All of this on Mountain Lion, 10.8.5)
v1.9 – pwPolicy works great, brings up the window and then groups and prefs when changing password
v1.9.1 – when a pwPolicy attribute is set, ADPassMon stops opening up users and groups and doesn’t bring up the warning window. (Without the pwPolicy set, users and groups opens up as expected
v1.9.2 – doesn’t open up users and groups regardless of pwPolicy being set.
Hope that helps!
Ah, thanks for this! I’ve already identified the cause, at least in v1.9.2 — and I suspect the fix will also fix 1.9.1. I’m now forcing ADPassMon to read the pwPolicy value as a string and the dialog appears normally. When it’s dismissed the password change dialog appears. Also, when the pwPolicy is empty, the password change dialog appears. Expect 1.9.3 shortly…
Working like a champ – thanks!
Thanks for the update. When running defaults write org.pmbuko.ADPassMon prefsLocked true I can see the entry change in the plist but im still able to edit prefs. Any ideas?
If you’re using OS 10.9, it’s probably because all preferences are cached and it can take a while for the changes to be seen. Try doing ‘killall cfprefsd’ from the Terminal to force a reload of all preferences and see if that makes a difference.
I am using 10.9 and running killall cfprefsd and even reboot doesnt lock the prefs :(
Can you try deleting the plist file altogether? (Check in ~/Library/Preferences and /Library/Preferences). Then launch and set up ADPassMon again. It should create a new plist file. Then try adding the prefsLocked item (should be a boolean) with a plist editor. The comment Joe made a few above yours (https://yourmacguy.wordpress.com/adpassmon/#comment-4843) implies that the defaults method is no longer working well. I’ll have to see if it’s my fault or due to some higher up bug.
making the change in a plist editor and running killall cfprefsd fixes the issue. Thanks for your help!
Good to hear!
I’m noticing that 10.8 and 10.9 clients are not keeping ADPassmon in the menu bar anymore. 10.7 clients are fine. Testing with 1.9.3. Tried installing on a new 10.8.5 machine and ran the regular scripts through ARD
Console User
defaults write org.pmbuko.ADPassMon prefsLocked true
defaults write loginwindow AutoLaunchedApplicationDictionary -array-add ‘{Path=”/Applications/ADPassMon.app”;}’
Root
sudo touch /private/var/db/.AccessibilityAPIEnabled
They way to add login items changed in 10.8. You need to put them into the com.apple.loginitems.plist. This page should help with the command you’ll need: http://apple.stackexchange.com/questions/83014/the-command-to-enter-login-items-is-not-working-in-10-8.
Also, in 10.9, Accessibility is handled much differently, but ADPassMon will take care of it for you.
I haven’t figured out applescript very well hence why I use ARD for everything thus far. Would I just be able to modify my com.apple.loginitems.plist. and push it out via copy in ARD?
That would probably work well, as long as you’re fine completely replacing the contents of the file. The applescript command at the link should work as a simple copy/paste job. Just replace “TextEdit” with “ADPassMon” in both places.
Copied this into the Unix portion of ARD
osascript -e ‘tell application “System Events” to make new login item at end with properties {path:”/Applications/ADPassMon.app”, name:”ADPassMon”, hidden:true}’
Received error message 121:122: syntax error: Expected expression but found unknown token. (-2741)
Make sure your command is using plain quote marks. Copying and pasting from a browser will sometimes result in curly quotes.
Yep that was it. The quotes in “ADPassMon” Thanks!
Any chance you’d humor a feature request to change the dialog box that asks for kerberos password wording from “Kerberos” to “Domain” or something akin to that. AD/Kerberos? Or can I haxy the app to change the wording myself? I understand what kerberos is but most of the users I work with will just be confused when the app asks for their kerberos password.
That’s a logical enough request that I’ll add it to the next version.
Thanks, you rock!
Peter, how are you or others handling users changing their passwords while not on the corporate LAN or VPN? We have all sorts of issues with users changing their passwords off the network and wreaking havoc when they return because passwords are no longer in sync (in addition to fudging up their FV2). We basically run an Applescript if their password is determined to be within two weeks of expiring that asks them if they are on VPN or on the corporate network, but we are having all sorts of problems with Accessibility in 10.9.
Graham, my site doesn’t actually use ADPassMon any more — ironic, eh? — so this is not really a concern for us. Our users have both LDAP and AD accounts, and we use a third-party tool that syncs LDAP and AD account passwords. The tool also handles the reminders. Our users are trained to only use this tool to change their passwords.
Currently ADPassMon’s “Change Password” item is not tied to network state, but I *could* make it unavailable when the AD servers cannot be reached. This would not, of course, prevent users from changing the password via the Users & Groups pref pane.
FV2 issues are another thing altogether. Our site does not mandate it, so most users do not use it.
It would certainly be useful to be able to limit when users could change their password, at least as it pertains to the ADPassMon alert. A customizable alert would also be useful in letting users know to sign into VPN or something similar.
This is an interesting observation, one that may explain issues we’ve seen when users reset passwords through the User + Groups System Preferences pane, but then end up in password purgatory with sync between AD and local password stores. I had assumed this was just the usual Keychain hell. Have not causatively connected off-network password changes with subsequent password failures, but it does make sense. So are you guys saying the Mac definitively must be online at the moment the password change request is made in OS X? Obviously domain password changed eventually carry down to the Mac, prompting users to update their Keychain password on login, but perhaps not the other way around?
Unless somehow the OS caches both credentials and holds them until it is able to communicate with an AD controller, I don’t see it happening. At least in the wild, we’ve seen any number of Macs that will allow machines to change password offline and then fudge the sheets when it starts talking to AD again. It would be great to somehow prevent that from happening.
I agree. I already have the “disable change password menu option when AD cannot be reached” feature added to the next release of ADPassMon, but that won’t stop users who go directly to the System Prefs to change their password.
Hi from France. We are evaluating this very valuable tool and we encountered this problem : the customized change password dialog does not support special characters like “;” and it may fail with ‘ \ / ? * : ; ” | & . May you be able to fix this issue ? Best regards.
Hi from France. Feature request : would it be possible to set a new key that would permit to optionnaly add a clickable URL when the password policy string is shown. The idea would be that before the password dialog is shown, the user would see a message like “Go to this corporate page to get all the details about the password change process”, page which would include the password policy string with many other details. Actually, the password policy string does not permit us to enter all the details about the work to do and to drive the user to a web page. You have already a similar process to drive the user to go to a password change web page. Best regards.
Hi from France. Feature request : would it be possible that the previous / new password entered is not shown as bullets in the customized change password. It may lead to think that these informations are retained somewhere (in clear text ?), which is a bit scary. Best regards.
Awesome utility – Really appreciate you writing and sharing it with the world.
With that said, i’m having an issue a few people above have mentioned – “Password expiring on Password expires on Monday, 2 March 1970 10:00:00 am”
This is the result of the pwdLastSet lookup.
XXXXXXX:~ xxx$ dscl /Search read /Users/xxx pwdLastSet
No such key: pwdLastSet
dsAttrTypeNative:pwdLastSet: 130462242162960345
dsAttrTypeNative:pwdLastSet: 130462242162960345
Which is correct when translated – Any idea?
I believe the multiple pwdLastSet responses are throwing off my code. I can put in a fix for this in the code. Is your Mac bound to more than one AD server?
Hi,
Wow thanks for the quick response – Again, really appreciate it!
Just did some looking around, it’s because we have two search policies – If I remove one it returns only a single result and ADPassMon works beautifully.
However, we do need two search policies because we have a ridiculously huge AD schema and we direct machines to a cut down location first and then the entire schema second.
Don’t feel like you need to urgently make changes here, but would really appreciate it if you could add it in at some point!
It’s a simple fix. Here’s a download link for the new version. Please let me know if it works for you and I’ll release it (more) publicly. https://dl.dropboxusercontent.com/u/3967964/ADPassMon.v1.9.5.dmg
Nice thanks – I’m actually being a bit cheeky and using a fork here – http://macmule.com/2014/04/01/announcing-adpassmon-v2-fork/
But ill test this change and let you know. If i’m to recompile the fork with your changes do you mind letting me know what you changed? Save me comparing the sources!
Thanks!
Dave
No problem. Just change the line that starts “set my pwdSetDateUnix to (((do shell script” to “set my pwdSetDateUnix to first word of (((do shell script”.
Hey there! We’re having an issue where it shows password expiration in -3 days. I’ve just changed my password 3 days ago, os I should have quite a white before the next expiration. We’re using Mavericks 10.9.3 and our AD is on Windows Server 2012 R2. Can you suggest a fix?
I just recently uploaded a very small update that may help. Can you redownload the latest version and see if that fixes the issue?
Thanks! So, I had v2.0.6 and I just downloaded v1.9.4 using the link above… v1.9.4 had the same -3d behavior. Lemmie see if I can find a newer 2.x version….
Try replacing the .4 with a .5 in the URL. I think I forgot to update the download link.
gotcha…. got it…. now it’s showing -6 days today on the 1.9.5 version
Ok, so no difference (since it’s three days later now). Hmmm. Can you open up Console.app, filter for “ADPassMon”, and tell me what you see there?
6/30/14 11:23:32.629 AM com.apple.launchd.peruser.719161608[231]: ([0x0-0x2a72a7].org.pmbuko.ADPassMon[66043]) Exited: Killed: 9
6/30/14 11:23:41.990 AM ADPassMon[66054]: Running on OS 10.9.x
6/30/14 11:23:41.991 AM ADPassMon[66054]: Testing Universal Access settings…
6/30/14 11:23:42.021 AM ADPassMon[66054]: Testing for Kerberos ticket presence…
6/30/14 11:23:42.079 AM ADPassMon[66054]: Ticket found and renewed
6/30/14 11:23:42.080 AM ADPassMon[66054]: Starting auto process…
6/30/14 11:23:42.089 AM ADPassMon[66054]: myLDAP: 172.xxx.xxx.xxx
6/30/14 11:23:42.404 AM ADPassMon[66054]: mySearchBase:
6/30/14 11:23:42.427 AM ADPassMon[66054]: Got expireAge: 0
6/30/14 11:23:42.455 AM ADPassMon[66054]: The new pwdSetDate (1.624497048297E+4)
6/30/14 11:23:42.455 AM ADPassMon[66054]: is < value in plist (1.624497070312E+4) so we ignore it
6/30/14 11:23:42.460 AM ADPassMon[66054]: daysUntilExp: -6.670755208334
6/30/14 11:23:42.460 AM ADPassMon[66054]: daysUntilExpNice: -6
6/30/14 11:23:42.462 AM ADPassMon[66054]: expirationDate: Monday, June 23, 2014 at 7:17:49 PM
6/30/14 11:23:42.465 AM ADPassMon[66054]: Finished process
6/30/14 11:23:42.465 AM ADPassMon[66054]: in the loop
6/30/14 11:23:48.601 AM ADPassMon[66054]: Starting auto process…
6/30/14 11:23:48.609 AM ADPassMon[66054]: myLDAP: 172.xxx.xxx.xxx
6/30/14 11:23:48.632 AM ADPassMon[66054]: mySearchBase:
6/30/14 11:23:48.653 AM ADPassMon[66054]: Got expireAge: 0
6/30/14 11:23:48.688 AM ADPassMon[66054]: The new pwdSetDate (1.624497048297E+4)
6/30/14 11:23:48.688 AM ADPassMon[66054]: is < value in plist (1.624497070312E+4) so we ignore it
6/30/14 11:23:48.693 AM ADPassMon[66054]: daysUntilExp: -6.670824652778
6/30/14 11:23:48.693 AM ADPassMon[66054]: daysUntilExpNice: -6
6/30/14 11:23:48.694 AM ADPassMon[66054]: expirationDate: Monday, June 23, 2014 at 7:17:49 PM
6/30/14 11:23:48.696 AM ADPassMon[66054]: Finished process
6/30/14 11:23:54.198 AM ADPassMon[66054]: Starting auto process…
6/30/14 11:23:54.205 AM ADPassMon[66054]: myLDAP: 172.xxx.xxx.xxx
6/30/14 11:23:54.231 AM ADPassMon[66054]: mySearchBase:
6/30/14 11:23:54.252 AM ADPassMon[66054]: Got expireAge: 0
6/30/14 11:23:54.276 AM ADPassMon[66054]: The new pwdSetDate (1.624497048297E+4)
6/30/14 11:23:54.276 AM ADPassMon[66054]: is < value in plist (1.624497070312E+4) so we ignore it
6/30/14 11:23:54.281 AM ADPassMon[66054]: daysUntilExp: -6.670894097222
6/30/14 11:23:54.281 AM ADPassMon[66054]: daysUntilExpNice: -6
6/30/14 11:23:54.281 AM ADPassMon[66054]: expirationDate: Monday, June 23, 2014 at 7:17:49 PM
6/30/14 11:23:54.283 AM ADPassMon[66054]: Finished process
There it is in all its glory….. minus a slightly sanitized IP for the LDAP
Is the myLDAP value an AD domain controller? I make the assumption that your primary DNS server is an AD server. If it isn’t, and you can’t make it so, you will need to use manual mode.
myLDAP value = a Windows DC running ADS
Ok. Do you have a valid Kerberos ticket? (Check by running ‘klist’ in terminal.) If so, try running ‘ldapsearch -LLL -Q -s base -H ldap://172.x.x.x defaultNamingContext’ and let me know the output.
oh yes… def have a valid krbtgt that expires Jun 30 21:23:41 2014
Making a Mavericks image I now receive the following error message trying to start SSH for the automatic launch of ADPassmon. /bin/bash: line 1: /sbin/service: No such file or directory. Haven’t found much googling. What am I missing?
/sbin/service is something you’ll find on linux, not Mac. I’m guessing your home directories shared between Macs and linux? You should check your bash startup files (~/.profile or .bashrc or .bash_profile) for the offending line.
I must have googled to get it working in 10.8? This is what I always had to do in 10.8 machines. I’m reading now about V2 but when I downloaded it I downloaded v1.9.4. Is v2 not in production?
v2 was made by someone else. He forked my code and added some features. http://macmule.com/2014/04/01/announcing-adpassmon-v2-fork/
Yep that’s what I was reading. Is that pmbuko approved?
Yes. I encouraged him to take my code and extend it.
I’m guessing something is supposed to happen hen I double click the ADPassMon-2.0.6.dmg in my downloads?
Nevermind. It mounts “Disk Image” but does not open a finder window.
Sorry, I was mistaken. /sbin/service existed prior to 10.9. I’d recommend creating a LaunchAgent instead.
Have you ever seen 2.0.6 revert back to 1.9.4 after a reboot? That’s what just happened to me while testing. I ran the script for defaults write org.pmbuko.ADPassMon selectedBehaviour -int 2 and also created a password policy defaults write org.pmbuko.ADPassMon pwPolicy “Your password requirement message goes here.” rebooted and it reverted.
I don’t use the v2 fork, so I can’t really help you with it. Do you have both versions on your computer?
Apparently his response isn’t as quick as yours. :sighs:
Whoops. I see what happened it didn’t overwrite the application it created another one that didn’t startup at log in. So I’ll have to write a script to remove the old ADPassmon first before installing the new one.
I’m seeing an odd issue and forgive me if this is a simple fix. When I upgrade 1.9.4 to 1.9.5 the options to change the password from ADPassMon are grayed out. If I reset the application in ADPassMon the menu item appears again. If I recheck the kerberos ticket in the application the option grays out again.
Is this unique to 1.9.5? I didn’t change any code for this part of ADPassMon between 1.9.4 and 1.9.5, but that doesn’t mean there isn’t a bug.
Yes, this is the first time I’ve seen this issue. I tested another machine doing just a drag and replace and it had the same issue. Reverting back to 1.9.4 brings back expected functionality. Thanks for responding.
I will pull 1.9.5 until I can figure out the issue. In the meantime, please stick with 1.9.4. I’ve already updated the download links.
as a side note I tried Ben’s version and did not experience the same issue. Version 2.0.6.
I released 1.9.6 earlier today. It should fix this issue.
Hi,
Firstly thank you SO much for all of your hard work on this lifesaving little app!
I have the following issue. Using ADPassMon it returns a result of, for example, 86 days remaining on a 90 day policy which is fine, but it does this for ever user I’m testing it with!
However, if I run the following code in Terminal…
#!/bin/bash
pwPolicy=90
user=`/usr/bin/who | /usr/bin/awk ‘/console/{ print $1 }’`
lastpwdMS=`dscl localhost read /Local/Default/Users/$user | grep SMBPasswordLastSet | cut -d’ ‘ -f 2`
todayUnix=`date “+%s”`
lastpwdUnix=`expr $lastpwdMS / 10000000 – 11644473600`
diffUnix=`expr $todayUnix – $lastpwdUnix`
diffdays=`expr $diffUnix / 86400`
daysremaining=`expr $pwPolicy – $diffdays`
osascript -e ‘display notification “Go to (site for pwmanagement) to change your password” with title “Password expires in ‘$daysremaining’ days” sound name “Hero”‘
It returns the correct expiry, usually around 22-26 days at the moment depending on the user.
Any ideas why that would be Sir?
Thanks.
How are you testing it with multiple accounts? Are they all logging in to the same computer or are you using separate computers? It should work properly in both cases, but it might help me figure out where to start looking.
Also, could you share the relevant ADPassMon log lines from Console.app when it reports the incorrect expiration date?
Hi,
Sorry I should have been clearer. Multiple Macs so different users.
Here you go…
13/08/2014 13:42:25.888 ADPassMon[6336]: selectedMethod: 1
13/08/2014 13:42:25.888 ADPassMon[6336]: Starting auto process…
13/08/2014 13:42:25.906 ADPassMon[6336]: myLDAP: 3.161.16.38
13/08/2014 13:42:26.379 ADPassMon[6336]: mySearchBase: DC=nbcuni,DC=ge,DC=com
13/08/2014 13:42:26.413 ADPassMon[6336]: Got expireAge: 91
13/08/2014 13:42:26.444 ADPassMon[6336]: The new pwdSetDate (16289.58)
13/08/2014 13:42:26.445 ADPassMon[6336]: is < value in plist (1.628958398438E+4) so we ignore it
13/08/2014 13:42:26.450 ADPassMon[6336]: daysUntilExp: 85.05452
13/08/2014 13:42:26.450 ADPassMon[6336]: daysUntilExpNice: 85
13/08/2014 13:42:26.451 ADPassMon[6336]: expirationDate: Thursday, 6 November 2014 15:00:57
13/08/2014 13:42:26.452 ADPassMon[6336]: Finished process
13/08/2014 13:42:29.093 ADPassMon[6336]: Starting auto process…
13/08/2014 13:42:29.094 ADPassMon[6336]: Found expireAge in plist: 91
13/08/2014 13:42:29.130 ADPassMon[6336]: The new pwdSetDate (16289.58)
13/08/2014 13:42:29.130 ADPassMon[6336]: is < value in plist (1.628958398438E+4) so we ignore it
13/08/2014 13:42:29.135 ADPassMon[6336]: daysUntilExp: 85.05448
13/08/2014 13:42:29.135 ADPassMon[6336]: daysUntilExpNice: 85
13/08/2014 13:42:29.136 ADPassMon[6336]: expirationDate: Thursday, 6 November 2014 15:00:56
13/08/2014 13:42:29.137 ADPassMon[6336]: Finished process
Thanks.
The pwdSetDate value in the log file looks really small. I do a calculation that compares a value in the plist to the new value. If the new value is less than the one in the plist, then it gets ignored. (A larger value means a more recent password set date.)
Do you push out a plist with this app? If so, try removing the pwdSetDate value from it. I think the issue is something else, though.
Still thinking.
Nope, no plist pushed out. Setup manually on each Mac for now whilst we are still testing. Thanks for looking into it, you rock!
Are you using the most recent version of ADPassMon (v1.9.6)? I changed the way the dates were handled in this version, so I think you’ve found a bug. I suspect the date that passwords at your site changed happen to fall near a date/time that result in a rounding error in my code. Please download this test version of ADPassMon and let me know if it fixes the issue. If it does, I’ll release it as v1.9.7.
https://dl.dropboxusercontent.com/u/3967964/ADPassMon_v1.9.7beta.zip
Damm you’re good! I’ll have to check tomorrow morning now as I’ll be back in the office then. I’ll report back.
I reset the prefs and it’s still appearing as 84 days I’m afraid :-(
And if it helps, under Auto, it gets a maximum password days of 91 and not 90 which is the actual password expiry.
Ok. I’ve put all the password data calculation logic into a script I’d like you to use for testing. Can you save this to your computer, run it, and let me know what the output is? (You can sanitize IP addresses if you like.) https://gist.github.com/pmbuko/e1989881d09f694d8d47
Sure… the myLDAP & mySearchBase are correct but for obvious reasons I can’t post them here!
expireAgeUnix: 7862400
expireAge: 91.00000000000000000000
pwdSetDateRaw: 130518936969025000
pwdSetDateUnix: 1407420096.90250000000000000000
pwdSetDate: 16289.58445489004629629629
todayUnix: 1408025407
today: 16296.59035879629629629629
daysUntilExp: 83.99409609375000000000
daysUntilExpNice: 83
Can we switch to email? Send me a note at gmail. Same account name I use here.
sure thing….
Great tool for the MAC, how about LINUX?
From what I saw it would be a perfect fit.
Could you give us any clue if this tool is available for Linux as well? It would be great to see this working in Ubuntu/Debian environments, too.
Many thanks
Joe
My tool would have to be completely rewritten to work on Linux. I have no plans to do so, as it wouldn’t solve any problems I currently have.
O.k. I understand. You would’t eventually publish the sources, would you?
The sources are available on GitHub. https://github.com/pmbuko/ADPassMon
I just downloaded ADPassMon to try out on our corporate network. When I double click on the application nothing happens. Absolutely nothing. No program window, no menubar changes – nothing. Our Macs are running OSX 10.9.4 and I made sure I downloaded the version for 10.8 and 10.9. After trying it, I restarted the computer and tried again. Once again nothing at all happens. I re-downloaded the program again with the same results. I have our Macs set to allow all apps to run in the Security preference pane. Any guidance would be appreciated.
After being able to spend more time on this, I discovered that I just had to wait a very long time before it did anything. Somewhere between 2 and 5 minutes. We’re also getting negative days reported for the password expiration when it does finally respond. I tried setting it to Manual mode, but it spins for anywhere from 2 to 5 minutes until it reverts to Auto mode and still reports negative days. Is there anything on the Active Directory servers I can have our Windows Server guys look at to improve this behavior? MS Outlook 2011 also reports that the password has expired in the past, but no one can seem to put their finger on what’s causing the wrong information.
Can you share with me the contents of Console.app (filtered for ‘ADPassMon’ entries) from the time you first launch ADPassMon to the time to you get some response? It should help identity where the slowdown is occurring.
Another thing you can do to help is save the script found here to one of your Macs: https://gist.github.com/pmbuko/e1989881d09f694d8d47.
Run the script and paste its output in a reply. You can remove IPs and domain information. The script contains the same commands that ADPassMon uses to get the info it needs from AD.
Just heard about this tool and very excited to get it to work for us! I do have one question maybe someone has experienced and answered.
We use fine grain passwords and I’ve noticed when I try to grab the maxPwdAge entry I get a consistent result across all accounts of 9.22337e+11 resulting in the tool saying there are 10675070 days to go.
Now I was able to fix this issue before in a PowerShell script but I’m unsure of how to make that translate to Apple Script. Below is an example of how I can get MaxPasswordAge out of the fine grain password policy per user:
$maxPasswordAge = (Get-ADUserResultantPasswordPolicy $user).MaxPasswordAge
Is anyone else running fine grain policies and possibly have a solution?
Wes, as you’ve seen, ADPassMon doesn’t know how to deal with fine grained password policies. I might be able to help you with this, but it depends upon whether the proper attribute is available to the Mac via the Active Directory plug-in. From the terminal app on a Mac, try running this command: dscl /Search read /Users/$USER | grep -v ‘^\W’
See if you can find any item that might hold the expiration value. The line may start with ‘dsAttrTypeNative’
Thanks for the reply! After looking through I realized I was going about this all the wrong way and all I needed was the group that is assigned to the user that assigns the password policy.
I replaced:
set my expireAgeUnix to (do shell script “/usr/bin/ldapsearch -LLL -Q -s base -H ldap://” & myLDAP & ” -b ” & mySearchBase & ” maxPwdAge | /usr/bin/awk -F- ‘/maxPwdAge/{print $2/10000000}'”) as integer
With:
set my expireAge to do shell script “if groups $USER | grep &>/dev/null ‘\\b6MonthExpiration\\b’;then echo 180;else echo 90;fi”
and now it works great!
Glad you were able to dig in and add the behavior you needed. Open source!
I have download the latest version of ADPassMon, but unfortunately it shows a wrong number of day. [-16302d]. Here is my logs from Console.
19/11/2014 2:20:52.252 pm ADPassMon[442]: *** -[ADPassMonAppDelegate applicationWillFinishLaunching:]: Can’t get character 1 of “”. (error -1728)
19/11/2014 2:23:43.808 pm ADPassMon[442]: Testing for Kerberos ticket presence…
19/11/2014 2:23:51.067 pm ADPassMon[442]: Ticket found and renewed
19/11/2014 2:23:51.070 pm ADPassMon[442]: Starting auto process…
19/11/2014 2:23:51.071 pm ADPassMon[442]: Found expireAge in plist: 91
19/11/2014 2:23:51.149 pm ADPassMon[442]: New pwdSetDate (-134774) is
19/11/2014 2:23:51.150 pm ADPassMon[442]: < plist value (0.0) so we ignore it
19/11/2014 2:23:51.158 pm ADPassMon[442]: daysUntilExp: -1.630227E+4
19/11/2014 2:23:51.159 pm ADPassMon[442]: daysUntilExpNice: -16302
19/11/2014 2:23:51.160 pm ADPassMon[442]: expirationDate: Thursday, 2 April 1970 7:55:03 am
19/11/2014 2:26:02.069 pm Console[594]: setPresentationOptions called with NSApplicationPresentationFullScreen when there is no visible fullscreen window; this call will be ignored.
19/11/2014 2:26:38.807 pm helpd[289]: CFPropertyListCreateFromXMLData(): Old-style plist parser: missing semicolon in dictionary on line 1. Parsing will be abandoned. Break on _CFPropertyListMissingSemicolon to debug.
19/11/2014 2:26:38.808 pm helpd[289]: CFPropertyListCreateFromXMLData(): Old-style plist parser: missing semicolon in dictionary on line 1. Parsing will be abandoned. Break on _CFPropertyListMissingSemicolon to debug.
19/11/2014 2:39:43.775 pm com.apple.preference.network.remoteservice[656]: Could not find image named 'InvalidDataIcon'.
19/11/2014 2:39:43.841 pm com.apple.preference.network.remoteservice[656]: *** WARNING: -[NSImage compositeToPoint:operation:fraction:] is deprecated in MacOSX 10.8 and later. Please use -[NSImage drawAtPoint:fromRect:operation:fraction:] instead.
19/11/2014 2:39:43.841 pm com.apple.preference.network.remoteservice[656]: *** WARNING: -[NSImage compositeToPoint:fromRect:operation:fraction:] is deprecated in MacOSX 10.8 and later. Please use -[NSImage drawAtPoint:fromRect:operation:fraction:] instead.
19/11/2014 2:49:37.576 pm com.apple.WebKit.Plugin.64[671]: CoreText performance note: Client called CTFontCreateWithName() using name "Arial Unicode MS" and got font with PostScript name "ArialUnicodeMS". For best performance, only use PostScript names when calling this API.
19/11/2014 2:49:37.576 pm com.apple.WebKit.Plugin.64[671]: CoreText performance note: Set a breakpoint on CTFontLogSuboptimalRequest to debug.
19/11/2014 2:49:38.307 pm com.apple.WebKit.Plugin.64[671]: CoreText performance note: Client called CTFontCreateWithName() using name "Times Roman" and got font with PostScript name "Times-Roman". For best performance, only use PostScript names when calling this API.
19/11/2014 2:51:00.156 pm com.apple.WebKit.WebContent[681]: NSURLConnection/CFURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9843)
19/11/2014 2:51:12.966 pm Safari[354]: *** -[IADomainCache init]: IA domains cache couldn't be read.
19/11/2014 2:55:31.207 pm ADPassMon[726]: Running on OS 10.9.x
19/11/2014 2:55:31.207 pm ADPassMon[726]: Testing Universal Access settings…
19/11/2014 2:55:31.347 pm ADPassMon[726]: *** -[ADPassMonAppDelegate applicationWillFinishLaunching:]: Can’t get character 1 of "". (error -1728)
19/11/2014 2:55:41.330 pm ADPassMon[733]: Running on OS 10.9.x
19/11/2014 2:55:41.331 pm ADPassMon[733]: Testing Universal Access settings…
19/11/2014 2:55:41.530 pm ADPassMon[733]: *** -[ADPassMonAppDelegate applicationWillFinishLaunching:]: Can’t get character 1 of "". (error -1728)
19/11/2014 2:55:55.234 pm ADPassMon[733]: Starting auto process…
19/11/2014 2:55:55.235 pm ADPassMon[733]: Found expireAge in plist: 91
19/11/2014 2:55:55.280 pm ADPassMon[733]: New pwdSetDate (-134774) is
19/11/2014 2:55:55.281 pm ADPassMon[733]: < plist value (0.0) so we ignore it
19/11/2014 2:55:55.287 pm ADPassMon[733]: daysUntilExp: -1.630229E+4
19/11/2014 2:55:55.287 pm ADPassMon[733]: daysUntilExpNice: -16302
19/11/2014 2:55:55.288 pm ADPassMon[733]: expirationDate: Thursday, 2 April 1970 7:58:19 am
rch, please run the troubleshooting script at the following link on your computer and paste the output here. Feel free to blank out IP addresses and domain names if you want. https://gist.github.com/pmbuko/e1989881d09f694d8d47
myLDAP: ...
mySearchBase: connect to my DC properly here.
uAC:
passExpires: yes
expireAgeUnix: 7862400
expireAge: 91.00000000000000000000
pwdSetDateRaw:
pwdSetDateUnix:
pwdSetDate:
todayUnix: 1416451226
today: 16394.11141203703703703703
daysUntilExp:
$ echo “daysUntilExpNice: $daysUntilExpNice” <- hangs here.
Looks like it’s actually failing higher up, at pwdSetDateRaw. Try running just this command and let me know the output:
dscl localhost read /Search/Users/$USER pwdLastSet | awk ‘/LastSet:/{print $2}’
the outcomes of that scripts are:
No such key: pwdLastSet
No such key: pwdLastSet
Btw, we are in Australia. Our dates are in DD/MM/YYYY format.
The date format doesn’t matter here since the system keeps track of time with seconds. I think your password set date is being stored elswwhere. Try this command:
dscl localhost read /Search/Users/$USER SMBPasswordLastSet | awk ‘/LastSet:/{print $2}’
If that comes back empty, then try this one:
dscl localhost read /Search/Users/$USER | awk ‘/LastSet:/{print $2}’
If that is also blank, then try this one and search for a line that might hold the password set date value:
dscl localhost read /Search/Users/$USER
Hi Peter,
I have run dscl localhost read /Search/Users/$USER and found out that there’s no Variable related to SMBPasswordLastSet.
Just give you a little bit background, I work at K-12 school and we have 25 imacs for media student. We use magic triangle setup for our mac lab. After a long test and trials, we have decided to delete all keychains on user’s logout. We have made a short custom script to do this, :
rm -rf /Users//Library/Keychains/
and then change mode to be able to run it, and add it to logout hook. it works fine now. Thank you for your help, Peter.
I have just installed ADPassMon and feel it may address a nagging issue with Kerberos ticket renewal in our environment. I was wondering if you could add an option for ADPassMon to automatically refresh the Kerberos Ticket on network state change “if” it can detect the domain controller. This would eliminate the need for end user training on ticket refresh.
FYI, I am thinking the network state “changes” upon a Cisco AnyConnect connection. The VPN is used for users working at home, which is where most users are running into expired Kerberos Tickets due to elongated times of no domain connectivity.
If you could make this tweak, we would be willing to pay for the utility if need be.
Hi Peter, I was also getting the negative number issue and all the suggestions above were returning nothing, however when I ran dscl localhost read /Search/Users/$USER and searched on pass I found the following along side the rest of my AD details:
PasswordPolicyOptions:
I’m not entirely sure how this data gets populated but It looks like the passwordLastSetTime is the data you need, is this something ADPassmon might support?
Those details are wrapped in xml plist tags, correct? That information doesn’t come from Active Directory but from the account that’s local to the computer. If you do
dscl /Search read /Users/$USER | grep 'LastSet:'
it should get you the Active Directory account expiration details if an AD domain is in your Directory Services search path.Correct, that info was wrapped in the xml plist tags. No such luck though looking for LastSet: and I swear to you, i’m attached to AD! :-) I see the rest of my AD details when I look at the output from dscl /Search read /Users/$USER
Does that value exist for any other users on the domain?
This was working until I updated my password. Now I’m getting the -1 day. Running OS X 10.9.5, here’s my output of the troubleshooting script.
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
myLDAP: x.x.x.x
mySearchBase:
uAC:
passExpires: yes
expireAgeUnix:
expireAge:
pwdSetDateRaw: 130559535714356662
pwdSetDateUnix: 1411479971.43566620000000000000
pwdSetDate: 16336.57374346835879629629
todayUnix: 1419358935
today: 16427.76545138888888888888
daysUntilExp: -91.19170792053009259259
daysUntilExpNice: -91
Is your primary DNS server (seen in the output of
scutil --dns | awk '/nameserver\[0\]/{print $3}' | head -1
) also an Active Directory server? If it is not, then you will not get to correct output. In that case, you can switch to manual mode, type in ’90’ and hit Tab or Enter to set the maximum password age manually.Added my ldap address manually, here is the updated output:
No such key: userAccountControl
myLDAP:
mySearchBase: DC=blah,DC=blah
uAC:
passExpires: yes
expireAgeUnix: 7776000
expireAge: 90.00000000000000000000
pwdSetDateRaw: 130559535714356662
pwdSetDateUnix: 1411479971.43566620000000000000
pwdSetDate: 16336.57374346835879629629
todayUnix: 1419359858
today: 16427.77613425925925925925
daysUntilExp: -1.20239079090046296296
daysUntilExpNice: -1
How recently have you changed your password? The pwdSetDateUnix line returned by the script corresponds to Tuesday, September 23, 2014. It looks like your domain account’s data is either being cached or has not been updated to reflect your most recent password change. Are you sure you changed the domain account password and not just your local account password?
I changed the password via System Preferences over VPN. Local and directory account passwords updated. I guess my local dscl attributes did not. Just updated again via the login screen and all is well. Thank you for your time and app!!!
I’m seeing that I know have 2 SMBPasswordLastSet in my DSCL attributes. Have you seen this before?
Yes I have. ADPassMon should ba able to handle it if it sees two values.
Thanks for the speedy reply! ADPassMon is handling it. Was just curious if this is normal. Thanks for confirming.
I’m trying to deploy ADPassMon with .plist and a LaunchAgent using Casper. I created the plist and launchagent files with TextWrangler and saved them as plain old text format. I packaged them up using Casper Composer in a .dmg file. When I deploy the .dmg none of the settings of the plist and launch agent work. When I double click on the files in the Finder, I can read them just fine and everything is exactly as I set them. HOWEVER, if I use the more command in Terminal to view the files, I get a message telling me the files are binary and asks me if I want to view them anyway. I tell it Yes I do want to view and it comes up as binary gibberish. If I take the text files I created and manually copy them to the locations they need to be in, it works just fine. So obviously something is happening to the plist and launchagent files that is changing it from text to binary and ADPassMon can’t read them. Does anyone have any tips for resolving this?
The system will sometimes convert plists to binary format. Try using the defaults command to read the plist to verify that it contains what you expect. I’m not sure why the installer isn’t working for you, though. Do you have a postinstall script that loads the LaunchAgent using the
launchctl load
command?I’m not doing a postinstall script to load the launchagent. I’m fine with just putting the files in place and then waiting for the users to reboot at their leisure. My suspicion is that something in Casper may be converting them to binary. I’ll post my query on the jamfnation site. I’ve read that some programs with fine with binary files and others prefer plain text. Unfortunately I don’t know enough about programming to know why there is a difference in the first place.
Any plans to leverage crankd/KerbMinder to detect on-network access and ungrey out the “Change Password…” menu item?
Actually yes. It’s been bugging me that ADPassMon is “dumb” about network state. I can’t tell you when it will happen, but it’s what I plan to work on next.
Hi Peter,
I am trying to get this going at my place of work but I do not see the SMBPasswordLastSet key for my user account. Looking at AD on the windows side from powershell, I see both PasswordLastSet and pwdLastSet.
I looked through the code and saw where you were previously using pwdLastSet.
Any idea why I would be missing SMBPasswordLastSet on 10.9?
Thanks.
Hi Jeff, running
dscl localhost read /Search/Users/$USER SMBPasswordLastSet
from your Mac gives you no results?Hello Peter
I have an issue with some users, they are unable to change there password, the mac gives a messages saying they do not have permission or rights to change there password even though they are admins to their machines, happens on all versions of OS Mountain Lion, do not use adpassmon on Yosemite yet. So its very random I can have user side by side with same set up but one can and one can’t change password, any help be much appreciated Thanks Nick
Hi. Can I please ask a very simple question. With regards to the pwPolicy message, how did you change it to say “I Understand”. I am very much a noob, so please forgive the simplicity of my question….Thanks..Roly.
Sorry for the misleading image. The current version uses “OK” for the button text and is not configurable. If you’d like, I can make the button text configurable with a defaults command — something like
defaults write org.pmbuko.ADPassMon pwPolicyButton "I understand"
Hi,
Firstly, thank you for your speedy reply.
I think it would be useful to have a configurable button. However, please only do this at your convenience. There is no rush. Thank you…Roly.
The new version is available now. https://dl.dropboxusercontent.com/u/3967964/ADPassMon.v1.10.1.zip
You Sir, are an absolute Star!. Thank you very much indeed. :)
This was definitely what I what is was looking for, thanks!!
i have a user with no pass expires, and menubar is showing [-385], when i tried to refresh kerberos ticket not work.
you have a fix? thanks!!
Can you quit ADPassMon, open up Console.app, then start ADPassMon again and let me know what the log output says?
Hi, I’m on a Mac running 10.10.3 (managed mobile user) in a pretty basic AD environment. The default install shows -354 days til expiration. If I manually change the setting in ADPassMon to 180 days, that changes to -719 days. Does your application look to the individual AD account expiration date, the AD password policy of the domain, or both? thanks.
Hi Matt,
ADPassMon queries AD with the following command to get the maximum password age for accounts:
ldapsearch -LLL -Q -s base -H ldap://w.x.y.z -b dc=example,dc=com maxPwdAge
. To calculate the remaining days for an individual user, it looks up the date that the user last changed their password with this command:dscl localhost read /Search/Users/$USER SMBPasswordLastSet
Then it does some date math using these two pieces of info to get the number of days remaining until the password expires.
Gotcha…perhaps my account (as a domain admin) isn’t the best to test with. If we are slowly rolling out a 180 day expiration to our standard AD users (as new accounts get created) it sounds like it makes sense to also deploy ADPassMon at that time – with the setting changed to 180 days.
Certainly, if it’s not auto-detecting the 180 day value, then pushing out a plist file with the manual value set is your best option.
My office AD environment is fairly complex, and our users do password resets through a tool that then syncs with various services – including AD. As a result, we’ve had to disable password changing in Mac OS X – as changing the password there does hit the other services in place, leaving the user with multiple passwords – and users have to change their password via a website. Using your tool, we’ve been able to add a button to the dialog box that directs the user to the password change page we use, but the ‘OK’ button is still present, and regardless of whether the OK button or URL button is pressed, the Users & Groups preference pane opens, which is an unnecessary operation in our environment. So my question is two-fold. Is there a way to remove the ‘OK’ button and leave only the URL button, and is there a way to make it so System Preferences doesn’t open at the button push event? In its current state, the tool does work, and we enjoy using it, but we haven’t been able to put it into production because of what I’ve stated above. Any insight would certainly be welcome. Thank you for your time.
Hi! And THANK YOU for this GREAT utility! One question… We’re noticing that our users who have a space between their AD account names get this crazy -151260 expiration date. Those who don’t are working as expected. Anyway to fix this?
I can probably fix this quickly. I’ll let you know. :)
EXCELLENT! Standing by…
Your long wait is over. :)
GREAT! Can’t wait to try it! I’ll report back as soon as I do.
Hello,
We recently updated our Windows Group Policy for password expiration time from 256 days to 320 days. Since we changed this I am still seeing AdPassMon keep the 256 and not the new. If I remove AdPassMon and re-install it then it shows 320. Is there anything I can do to get around a uninstall and reinstall?
Thanks in advance.
Blake, the expiration data gets saved to ADPassMon’s plist file. Clicking the “Revert to Defaults” button in the Reset tab of the preferences window should clear out the value and force it to look it up again. If that doesn’t work, you can delete the ~/Library/Preferences/org.pmbuko.ADPassMon.plist file.
@pmbuko
Thanks for the info. I have tried to delete plist file before but it doesn’t change the value – it keeps it at the 256 timeline not the 320. I reset my password in ADmon and it changed it to 256(old gpo timeline). I uninstalled and reinstalled and it changed it to 320(which is the new correct gpo). I also tried to replace the plist with a fresh one that had never been opend with no values in it and it re-wrote to 256 some how.
I could just do a uninstall and reinstall but this is currently used by a few hundred users and that is not the best solution or easiest solution.
Thanks,
Blake
Try running “sudo killall cfprefsd” on the computer after deleting the preferences file. Let me know if that makes a difference. I’ll also check to see what I can do in my code so that it can correctly detect password policy changes.
Could you push out the plist file of the Mac that has the right amount of days to others with ARD? Test with a couple machines first. If it works, deploy away.
Love the tool. But have just run into a slight issue since upgrading from 10.9 to Yosemite. MCX settings used to lockdown Preferences within the app but its stopped working. Using version 1.10.0 ADPassMon. Any ideas?
Tried refreshing mcx but no luck…
Myron, please give this fork of my project a try and let me know I it makes any difference. https://macmule.com/2014/04/01/announcing-adpassmon-v2-fork/
The v2 fork will be the best version to use going forward.
Hi Peter – still not working using mcx or defaults write org.pmbuko.ADPassMon prefsLocked true
Have you tried quitting and restarting ADPassMon after making the change? Prefs are read then the app loads so it won’t take effect right away. I just tried
defaults write org.pmbuko.ADPassMon prefsLocked true
on my Mac (10.10.3) with ADPassMon 1.10.2 and it worked after I quit and restarted ADPassMon.That works for me with your version but not using the forked version. MCX not working on either though since 10.10.3 upgrade…
Since MCX is deprecated in Yosemite, particularly user-level MCX, I’m not sure it’s something I can fix from the ADPassMon side.
I think I will have to script it or convince client to use config profiles. Having said that copying pmbuko plist from “/Library/Managed Preferences/legacy 10.9” user to “/Library/Managed Preferences/new 10.10 user” creates the desired result. I didn’t realise user-level MCX was deprecated in 10.10…
Even running the latest version 1.10.3 and 1.10.3 I’m still getting -151323 day expiration date
edit….1.10.2 and 1.10.3
A negative value means that ADPassMon wasn’t able to automatically determine the maximum password age by querying a domain controller. The command it uses to query AD is
ldapsearch -LLL -Q -s base -H ldap://dc.example.com -b dc=example,dc=com maxPwdAge
. If you run this on your computer (substituting in the correct values after -H and -b), what is the result? In any case, I suggest using Manual method in ADPassMon preferences and entering in the maximum password age there. Remember to press Enter after typing in the value.Interesting, my macPwdAge returns a -51840000000000
Even when I use manual mode it still shows a value of -151324
maxPwdAge*…wish I could edit my previous comments.
Hmmm. Your AD must be storing both the maxPwdAge and pwdLastSet values in a different format than what I’ve seen. There are three more significant digits than I’d expect. Let me see what I can learn about other ways AD can store time stamps.
Hi Peter
I’m very excited to get this working in our environment, thank you for all the hard work!!
Before we deploy the application I’d like to create an extension attribute in our JSS so i can confirm that all the expiry dates are correct for each Mac.
At the moment i’m using the script below as an attribute but i’m getting a lot of -negative values show up for the expiry date, i’ve checked SMBPasswordLastSet in AD for a few of the Macs that are reporting this negative value, i put the SMBPasswordLastSet timestamp into a converter and it does show the last password set date as being back in 2014 so i’m guessing that’s an issue with these AD records.
Does ADPassMon use the value from SMBPasswordLastSet to calculate the days left till expiry or something else?
If it does use something else, is it something i could use to make an extension attribute for our JSS ?
here’s the attribute i’m tetsing at the moment.
Thank you,
Andy
#!/bin/bash
pwPolicy=60
user=
/usr/bin/who | /usr/bin/awk '/console/{ print $1 }'
lastpwdMS=
dscl localhost read /Local/Default/Users/$user | grep SMBPasswordLastSet | cut -d' ' -f 2
todayUnix=
date "+%s"
lastpwdUnix=
expr $lastpwdMS / 10000000 - 11644473600
diffUnix=
expr $todayUnix - $lastpwdUnix
diffdays=
expr $diffUnix / 86400
daysremaining=
expr $pwPolicy - $diffdays
daysString=”in $daysremaining days”
echo “$daysremaining”
Andy,
You’re welcome! I posted a bash script here that contains shells commands similar to what ADPassMon uses internally. To specifically answer your question, look at line 18. I am using
dscl
to look up theSMBPasswordLastSet
value stored in AD.If your network advertises multiple AD servers (run the command found on line 5 without the
head -1
part), they can sometimes come up in different orders. If one or more of those AD servers doesn’t have adefaultNamingContext
value set, then part of the lookup will fail and you’ll end up seeing negative password values. I suggest downloading my script and running it a few times in a row to see if you get inconsistent results.Brilliant ! thanks for the details, i’ll test them out shortly.
Another quick question if you have the time,
is there any way to disable the message “No Kerberos ticket for Active Directory was found. Do you want to renew it?” or is there a way i could reword the “Password is incorrect – Please try again” message if the Mac can’t reach our network ?
We have a lot of external users who very rarely access the VPN and i think when they’re prompted to renew the kerberos ticket they’ll get confused when it tells them their password is incorrect.
Thank you,
Andy
When ADPassMon can’t reach Active Directory — when it runs
dscl localhost read /Search/Users/$USER SMBPasswordLastSet
and receives no result — then it should not prompt to renew the kerberos ticket. Is that happening?Yes, it is prompting to renew the key when the Mac is not connected to the VPN and can’t reach Active Directory.
The result from /Search/Users/$USER SMBPasswordLastSet is No Such Key,
(then i thought!) i am logged in as a local non AD user, would that cause this behaviour?
When i’m back in the office i’ll login as an AD user and test it again and confirm it.
Thanks again!
That might have something to do with it. If ADPassMon has never successfully contacted AD about a particular user (like your local one), then my code probably doesn’t catch that and should be fixed. :)
sorry for adding to your list!
i’ll let you know the outcome once i’ve tested it under an AD login
Cheers
Hi
I’ve just tested it within an Active Directory users login and it does not prompt to refresh the ticket if it can’t reach AD.
Though If manually ask it to Refresh Kerberos Ticket it does still display the password prompt, if i enter the AD password and is says it’s incorrect (if it can’t reach AD).
We can advise users not to manually refresh the ticket when out of the office.
Cheers,
Andy
If AD can’t be reached when ADPassMon starts up or when the computer comes out of sleep, the Refresh Kerberos Ticket menu item should be disabled. Also, are you trying this with the latest version, 1.10.3?
Yes it’s ADPAssMon version 1.10.3 on Yosemite 10.10.3, it’s not able to reach AD and all of the menu items are available.
I’m not managing the preferences, the only thing i’ve added is a ~/LaunchAgent to keep it open.
Prefs are
enableNotifications
expireAge
60
menu_title
[28d]
pwdSetDate
16587.76
tooltip
Password expires on Friday, July 31, 2015 at 1:14:24 PM
Does it write to a log file anywhere ?
It does write to the main system log. You can filter for ADPassMon in Console.app.
Thanks,
Just tested V1.10.3 on a 10.9.2 Mac within an AD Managed Mobile account and all the menu items are still available when AD can’t be reached. Tried quitting and re-opening it and also resetting it but still the same.
Console doesn’t show much when choosing to Refersh Kerberos Ticket:
7/2/15 4:10:37.050 PM ADPassMon[2415] Testing for Kerberos ticket presence…
7/2/15 4:10:37.073 PM ADPassMon[2415] No ticket found
7/2/15 4:11:07.526 PM ADPassMon[2415] Incorrect password. Skipping.
Cheers, Andy
Thanks for the additional info. It may take a few days but I’ll give it another look.
Running 10.10.4 with ADPassMon 1.10.3
On the network local to Domain Controllers the ADPassMon drop down greys out both “Refresh Kerberos Ticket” and “Change Password…”. However refreshing ticket through ticket viewer works fine so we know the client can’t find a domain controller. Nothing out of the ordinary in console logs.
Thoughts?
Can you paste what the log does show? The pwdLastSet value gets stored in the plist so ADPassMon can still show expiration info away from the network, but when it’s on the network it compares the stored value against AD. The result of that comparison should be logged.
I’ve noticed that the change password option will be greyed out unless your password is lower than the notification days.
That’s certainly not working as intended. I’ll rework the code that controls the availability of the change password item. Again, it may take a few days since I don’t plan on working this weekend. :)
Is there a way to have the app do a sanity check before asking if the user needs to enable Assistive Devices? I set this using a sqlite command and would rather not have a user presented with a dialog box. This worked up until the current version.
So one of the bugs I fixed was the code that sets up the accessibility portion. Turns out it was broken for quite some time. In fixing it, I exposed this bug that you discovered. (So goes software, I guess).
I’ve now added an “accTest” preference that you can set (globally or per-user) to disable the accessibility test, e.g.
defaults write org.pmbuko.ADPassMon accTest 0
Download the new build here and please test it out. It it works for you, I’ll release it officially.
I absolutely love ADPassMon, but i think i’ve found an issue with the latest version. I packaged ADPassMon for deployment with the previous version a while back and it was working great. I manually set the password expiration days to 180 since that is our policy. When i swapped out the ADPassMon app in the package payload everything seems to work, but it is adding a 0 to the days until password expires. For example my password expires in 91 days with the previous app, but with the new version it shows 910 days. It could be my configuration or something, but i figured i would let you know. Thanks again for such a great tool!
Hi Andy, have you tried using the reset button in the preferences, then quitting, restarting ADPassMon and reconfiguring it? Also, to help me troubleshoot, please open Console.app, add a search filter for ‘adpassmon’, and copy and paste what you see appear when you click ‘Test Settings’ in ADPassMon’s prefs window.
Thanks for the quick reply. Below is the log you requested.
7/21/15 10:32:35.630 AM ADPassMon[2151]: Running on OS 10.10.x
7/21/15 10:32:35.632 AM ADPassMon[2151]: Testing Universal Access settings…
7/21/15 10:32:35.633 AM ADPassMon[2151]: Enabled
7/21/15 10:32:35.642 AM ADPassMon[2151]: Loading prefs…
7/21/15 10:32:35.779 AM ADPassMon[2151]: Testing if password can expire…
7/21/15 10:32:35.826 AM ADPassMon[2151]: Password does expire.
7/21/15 10:32:35.860 AM ADPassMon[2151]: Starting auto process…
7/21/15 10:32:35.861 AM ADPassMon[2151]: Found expireDateUnix in plist: 1.516129745E+9
7/21/15 10:32:35.913 AM ADPassMon[2151]: Got expireDateUnix: 1516129745
7/21/15 10:32:35.914 AM ADPassMon[2151]: Using msDS method
7/21/15 10:32:35.926 AM ADPassMon[2151]: daysUntilExp: 910.150347222222
7/21/15 10:32:35.926 AM ADPassMon[2151]: daysUntilExpNice: 910
Can you tell me what version of Windows your AD servers are running? The “expireDateUnix” value is calculated from a value given by the AD server. The number 1516129745 corresponds to a date of Jan 16, 2018. Here’s a script that shows what ADPassMon is doing.
2012 R2
Can you try running the script I linked to in the previous comment? If it also returns the incorrect date, then try going back to using manual mode.
Yes it returned the same results. When i changed it back to manual 180 days it seems to be showing the correct days now. Thanks so much for your help!
With the latest version, 1.11.1, I and my users are seeing the ADPassMon Preferences window show up after every login. We can dismiss it, but the next time we log in to the computer, there it is again. Any way we can stop this from showing up at login? Thanks, love the app.
Thanks for letting me know. I’ll take a look.
Just tried v1.11.3 and I can confirm that this issue is fixed. Thank you!
Hi, is there a way to set the format that the day appears in in the menubar? Right now I’m seeing “[78d]”, but I don’t need the brackets to be there (it would look a little cleaner without them). Is there a way for me to take them out?
Not currently, but I can remove the brackets in the next release. If people miss them, I’ll add an option to the prefs that allows you to enable/disable them.
You make a great FREE product with amazing support and this is what people are concerned about?
It was just a question, I wasn’t being critical. It’s something I see on my screen all day so it’s not that out of the ordinary to wonder if I can change its appearance.
Thanks for offering to update it so quickly, @pmbuko.
I am not sure if I am missing a setting, but the notifications appear to not be working on any of the test systems we have it on. I could be completely wrong about how to set it. Current settings are;
1. I am on 10.10.4 on one system and 10.8.6 on another.
2. KerbMind is not installed. (Don’t know if I need this or not. From what I read, I don’t think so.)
3. My password will expire in 75 days. (I know this is accurate as I’m able to verify in Active Directory and also what ADPassMon is showing me.
4. AD user doesn’t have a Mobile Account. (Could this matter?)
5. User shows in Users & Groups and ADPassMon is set to run as a login item
6. ADPassMon is checked in Security & Privacy/Accessibility
7. ADPassMon is in the Notifications Center with all options checked and ‘alert style’ set to Banners.
8. ADPassMon preferences does have the “Use Notifications” box checked.
If I set this for 74 days, then tomorrow I should get a notification about my password getting ready to expire correct?
This is the problem I run into, as it doesn’t do that. Everything seems to work except for the notifications part.
Please let me know if my configuration is somehow lacking.
Thank you for this product! You have done an amazing job and this is SO needed.
Kris, thanks for letting me know about your notification issues. I’ll run some tests on various OSes and see if I can replicate it and fix it.
Kris, I verified in 10.10.4 that notifications were not appearing when they should. I added a small tweak to my code and also added a logging entry. Please download the pre-release of the the next version here. To test, please set your warning threshold higher than the number of remaining days and then choose “Re-check Expiration” from the menu. Also have Console.app open with a search filter of “ADPassMon” so you can see what it’s doing. You should see a “Triggering Notification…” line appear.
If you see the “Triggering Notification…” line but do not see a banner, then click the Notification Center icon in the menu bar and see if the notification is there. This happened to me a few times. I didn’t see a banner appear but the notification did make it into Notification Center. That may be an Apple bug.
With as quickly as you are responding, I certainly don’t mind being your beta tester. :)
Let me make sure I did this correct as well.
1. Exited ADPassMon
2. Trashed app
3. Trashed Preference file ~/Preferences/org.pmbuko.ADPassMon.plist
4. Copied the new ADPassMon.app to /Applications
5. Opened Console
6. Ran ADPassMon.
7. Gave me crap about the wrong AD password.
8. Trashed all the tickets in ticket viewer.
9. Trashed Preferences again.
10. Ran it.
11. Set threshold to 79 days (password will expire in 75 days).
12. Clicked “Test Settings”
13. Checked Console and got the following.
7/31/15 9:15:30.471 AM ADPassMon[72609]: Triggering notification…
7/31/15 9:16:51.622 AM com.apple.preference.notifications.remoteservice[72674]: Failed to connect (_okButton) outlet from (NCPrefAppDetailController) to (NSButton): missing setter or instance variable
14. Started typing this.
15. Per your instructions, clicked on “Re-Check Expiration”
16. Notification popped right up with the following information
7/31/15 9:29:31.394 AM ADPassMon[72609]: Starting auto process…
7/31/15 9:29:31.394 AM ADPassMon[72609]: Found expireDateUnix in plist: 1444844990
7/31/15 9:29:31.684 AM ADPassMon[72609]: Got expireDateUnix: 1444844990
7/31/15 9:29:31.685 AM ADPassMon[72609]: Using msDS method
7/31/15 9:29:31.724 AM ADPassMon[72609]: daysUntilExp: 75.055775462963
7/31/15 9:29:31.724 AM ADPassMon[72609]: daysUntilExpNice: 75
7/31/15 9:29:31.725 AM ADPassMon[72609]: Triggering notification…
17. Tried the ADPassMon pref “Test Settings” button again, appears to just sit at “Triggering notification…”
Did notice that when I click “Test Settings” it shows up right away in the Notification Panel, I just don’t get the pop up.
Let me know how else I might be able to help test this.
~Kris
Kris, I’ll try to see if I can figure out why the banners don’t appear all the time, but if you’re seeing the notification appear in the Notification Center, with or without the popup, then my code is behaving properly.
It appears to be working as advertised now. Thank you for getting to this so quickly. We are moving to a Citrix Identity solution to merge our AD and LDAP (yeah I know AD IS LDAP) passwords. I do not know if they offer a way to show on Mac when AD passwords will expire. If not, ADPassMon will be what I turn to.
Thank you again!
You’re welcome, and good luck with your merge. I was recently tasked with merge independent LDAP directories from two sites into one, but both were OpenLDAP. We still have a separate AD, though.
Hi Peter.
Looks to be working beautifully. One tweak if I might suggest? When a password is past the notification threshold and the notification appears, could the “Show” button on the notification take you to the change password box the same way “Change Password” does from the menu icon (I am using the “Alert” notification setting)? This way the users won’t need an extra step to change their password. Maybe even change the “Show” to “Change”?
Thanks again for all your hard work!
It’s an excellent suggestion and one I had explored previously, but I wasn’t able to get it working, then. I’ll add it to my to do list and have another crack at it.
Thanks Peter.
I only ask because the “Show” button at this point functions like the “Close” button.
This just feels like the final piece to make this truly functional (aside from maybe making it run as a LaunchAgents prog) and push able via DeployStudio or ARD.
Let me know if I can help.
Peter,
Have you ever seen this behavior in ADPassMon?
1) User is on the network with the AD and is successful in communicating with it.
2) The next time the user powers up the system, they are now remote to the network with the AD. The number of days until password expiration remains as it was when the system was last on the internal network. For this example, lets say this is over the weekend.
3) User comes back in to the office where the AD network is and successfully authenticates with AD. However the number of days until password expiration still has not changed since the last time they were on the network. In my example its been at least 2 days due to the weekend so the time to expiration “should” have decreased by 2.
This number will not change unless the user selects “Re-check Expiration” from the ADPassMon dropdown.
I’ve left the system on for consecutive days and it seems as if its not checking. However if I turn off a system that had last been on the AD network and leave it off for multiple days and then log back into it again while connected to the AD network it WILL show the correct password expiration.
This might be something easy but I have not been able to discover what the issue is. We are looking at the latest version of ADPassMon (1.11.4) and MacOS of 10.10.5.
We are really hoping to use this app in our environment to help with our AD deployment but want to clear this one up as I have a lot of users who travel frequently and are off the network for periods of time.
Thanks,
–Darren
Yup. I’ve seen that behavior and it has been fixed in the newest version. Please see my latest blog post and let me know if version 2.20 takes care of it. It did on my computer, but more testing is always appreciated.
I definitely will!
Thanks for the prompt reply!
Wanted to followup and say that the behavior that I was seeing before has been fixed.
I have not seen any other issues but there is a report of one. If it is I’ll report it in the other thread.
Thanks again for this!
–Darren