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

ADPassMon icon

Click to download ADPassMon (930KB)

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.

menubar

Hovering your cursor over the icon reveals more precise information in a tooltip.

tooltip

Clicking on the menu item reveals some additional features, which I’ll discuss further below.

active menu

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.

prefs-settingsAuto 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:

growl alert

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.

change-pass

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.

prefs-reset

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.

117 Responses to ADPassMon

  1. Alan Yacavone says:

    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–

    • pmbuko says:

      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.

  2. Is there a way to set Add to Login Items to true through MCX?

  3. TGB says:

    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

  4. 32bit says:

    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?

  5. MaM says:

    I want this app, but …

    … keep on display “Working …”

    If I switch to “Manual”, app switch back to “Auto”.

    • pmbuko says:

      When you switch to manual, make sure you press Tab or Enter after inputting the maximum password age.

      • MaM says:

        Thanks.

        Now display “Your password will expire in -15079 days ….” :-)

        • pmbuko says:

          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.

          • MaM says:

            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

            • pmbuko says:

              What value are you putting in the maximum password age field?

            • pmbuko says:

              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}'

            • pmbuko says:

              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.

              • MaM says:

                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.

            • pmbuko says:

              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.

              • MaM says:

                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

              • MaM says:

                Domain controller runs on Windows SBS 2003, but Domain Functional Levels is Windows 2000 Native …

              • pmbuko says:

                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?

              • MaM says:

                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

              • Ben Naidus says:

                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.

              • pmbuko says:

                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.

              • Ben Naidus says:

                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.

              • pmbuko says:

                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.

              • MaM says:

                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.

              • Ben Naidus says:

                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!!

              • pmbuko says:

                Thanks so much for returning and letting us know how you resolved your issue.

  6. Jeff says:

    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.

    • pmbuko says:

      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.

  7. Jeff says:

    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.

  8. DO says:

    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?

    • pmbuko says:

      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?

      • DO says:

        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.

  9. Elvin says:

    Great program. I have a silly question. How can I push this out to all accounts on a mac?

    • pmbuko says:

      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";}'

  10. mreed911 says:

    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?

  11. nick says:

    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.

  12. chris says:

    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

  13. chris says:

    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

  14. chris says:

    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

  15. chris says:

    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

  16. Do you have any plan to support growl 1.3?

  17. Kevin says:

    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?

    • pmbuko says:

      Can you open up Console.app and let me know what ADPassMon is putting in the log?

      • Kevin says:

        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

      • Kevin says:

        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!

        • pmbuko says:

          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.

          • Perttu says:

            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?

            • pmbuko says:

              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.

  18. Pingback: Technology Short Take #18 - blog.scottlowe.org - The weblog of an IT pro specializing in virtualization, storage, and servers

  19. Perttu says:

    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?

    • pmbuko says:

      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?

  20. Perttu says:

    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.

    • pmbuko says:

      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’?

      • Perttu says:

        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!

  21. fracus84 says:

    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.

    • pmbuko says:

      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

      • fracus84 says:

        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.

        • pmbuko says:

          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.

  22. fracus84 says:

    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.

  23. Perttu says:

    Thanks! This seems to have fixed both issues.

  24. Steve Madel says:

    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?

    • pmbuko says:

      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?

  25. Steve Madel says:

    Yes, they get the same response either way.

    • pmbuko says:

      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.

  26. 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.

    • pmbuko says:

      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.

    • pmbuko says:

      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

  27. Kevin says:

    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?

    • pmbuko says:

      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.

      • Kevin says:

        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

        • pmbuko says:

          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.

          • Kevin says:

            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

            • pmbuko says:

              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.

              • Kevin says:

                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.

  28. Josh says:

    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?

    • pmbuko says:

      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.

      • Josh says:

        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.

        • pmbuko says:

          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.

          • Josh says:

            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$

            • pmbuko says:

              Your issue may be solved simply by ensuring that the Quest Authentication service binding is added to your search policy.

              • Josh says:

                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.

              • pmbuko says:

                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.

              • Josh says:

                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

  29. Josh says:

    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.

  30. Grant says:

    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.

    • pmbuko says:

      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.

      • Josh says:

        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.

        • pmbuko says:

          Sorry, Josh. I wasn’t able to get any further with Quest.

          • Josh says:

            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.

            • pmbuko says:

              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.

  31. DeepCrow says:

    Seems to be broken on Lion 10.7.4; reporting a -57 day password expiration. Standard Lion install bound against a 2003 domain.

    • DeepCrow says:

      Also reported that there wasn’t a ticket when the Ticket Viewer is showing a valid ticket.

    • pmbuko says:

      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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.