ADPassMon
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 and 10.7
- optional Growl alerts with adjustable warning period
- integrated Kerberos ticket renewal
- change password menu item
- offline functionality via cached expiry information
- MCX support for ease of administration
This software is released under the MIT license.
Read enough? Download it here. If not, 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
05-17-2011 NOTE: ADPassMon v1.1 released, now supports 32-bit only Intel Macs.
10-12-2011 NOTE: ADPassMon v1.3 released with minor DNS bugfix.
11-3-2011 NOTE: ADPassMon v1.4 update for Growl 1.3 compatibility.
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 Support
If you have Growl installed and running, ADPassMon can optionally send you Growl notifications of impending password expirations. Check the Enable Growl Notifications box and enter the number of days before the password expires that you want the warnings to start appearing. (If you do not have Growl installed or it is not running, the Growl options will be disabled.) Warnings will appear every 12 hours after the threshold is reached. Each warning will resemble the following:

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 the “access for assistive devices” feature in the Universal Access pref pane be enabled. If it is not enabled, users with administrator access will be prompted to enable it when the program first launches.
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 let 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.
Lockable Preferences
If you’re a Mac 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 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 four beta testers: Brian LaShomb, Rusty Myers, 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) 2011 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 /SearchIf 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.
Pingback: Technology Short Take #18 - blog.scottlowe.org - The weblog of an IT pro specializing in virtualization, storage, and servers
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 pwdLastSetdscl /Search read /Users/$USER pwdLastSetAlso, 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.