UPDATE: My fork of ADPassMon has now been merged with main & many changes have been made, for more information follow this link. The Wiki on the GitHub project replaces the details below.

Over the past two posts, I have detailed two issues with 10.9

1. No Password Expiration Warning At The Login Window
2. The “Local Items” keychain

In looking at resolving issue 1, I revisited Peter Bukowinski’s excellent ADPassMon. This is a great app, but has never quite suited my environment, as such I grabbed the code off of GitHub & got stuck in.

This has resulted in me, on this most foolish of days & with a nervous excitement, announcing my ADPassMon fork. In time I hope this fork joins the is committed to the main release.

So why did I go to all this trouble? What does it do? Read below.

Same old, brand new.

One of the main goals I set out with, was to keep as much of the existing behaviour of ADPassMon. Therefore you should be able to install this new fork & neither you, nor your users will see much of a difference.

To download the latest version of the app & to view the source, click the button below.

The source is on GitHub here, or you can grab a compiled version of 2.0.9 from here.

Well, until you open ADPassMon’s Preferences:If you’re not aquatinted with ADPassMon, the changes are the “ADPassMon Behaviour”, “Perform Keychain Lock check at launch?”  & the “Password Expiration Check Interval” options. The rest is as-is.

In-Accessibility Access

One of the things that has always made me shy away from ADPassMon is it’s reliance on Accessibility Access being enabled, & users having access to the “Users & Groups” pref pane.

In almost all environments I have worked in, access to the “Users & Groups” pref pane has been greyed out as per the below.

If you enable “Version 2” behaviour, either through the preferences window, MCX or the following defaults command:

defaults write org.pmbuko.ADPassMon selectedBehaviour -int 2

Not much will yet change, when you select “Change Password” from ADPassMon:

If you have set the pwPolicy key, you’ll still be presented with it (as per my poorly written example below):

However, on clicking “OK” the user will not be taken to the “Users & Groups” pref pane. Instead they will be taken be presented with the below window. This is as “Version 2” behaviour bypasses the requirement for Accessibility Access.

This window will check that all fields have been filled out, & that the new & verify fields will match. If these checks are passed the following is run:

do shell script "dscl . -passwd /Users/$USER " & quoted form of enteredOldPassword & " " & quoted form of enteredNewPassword

If this errors with: “eDSServiceUnavailable” it is the user cannot connect to the domain & are then prompted with the below:

And if it errors with “eDSAuthMethodNotSupported” this is due to the wrong credentials being passed with the users being advised accordingly:

Keychain Minder is dead, long live ADPassMon!

“Perform Keychain Lock check at launch?” can be enabled via the preferences window, MCX or the following defaults command. This option works whichever behaviour is chosen:

defaults write org.pmbuko.ADPassMon enableKeychainLockCheck -bool true

On launch, ADPassMon then checks to see if the users keychain is locked. This is performed but trying to unlock the users keychain, if it errors, then the keychain is locked. The commands are below:

If the login keychain is found to be locked, the user is then prompted to update with the following window:

When a user is changing their password using the v2 behaviour as mentioned in the last section, or clicks “Update” at the window above. The login keychain is also updated via the following:

do shell script "security set-keychain-password -o " & quoted form of enteredOldPassword & " -p " & quoted form of enteredNewPassword & " ~/Library/Keychains/login.keychain"

If “Keychain Access” happens to be open before any of this, the user is asked to close the app as it can cause issues:

As detailed in my post, The “Local Items” keychain. If creating a new keychain on 10.9 we’ll want to restart after deleting the old keychain as well as the old “Local Items” keychain. The user is prompted to do this as per the below:There has also been a little error handling incase we’ve tried to create a new login keychain, but deleted it:Lastly, when successful.. we let the user join in in our success!

Added Extras

The next section details some last minutes additions I added.

If you’ve used Keychain Minder, but changed the displayed text. You can set a dialog box to appear before the keychain lock page by MCX, or via the below defaults command:

defaults write org.pmbuko.ADPassMon keychainPolicy "<some text>"

In some environments, you may need your users to change their passwords 1st via a website before updating their Macs password. There are two keys you need to enable for this in addition to the pwPolicy key, again this can be done via MCX or the following defaults commands:

defaults write org.pmbuko.ADPassMon pwPolicyURLButtonTitle "<button title>"
defaults write org.pmbuko.ADPassMon pwPolicyURLButtonURL "<some url>"

The user will then see a dialog box with whatever text you set via pwPolicy, & a button titled with what you set pwPolicyURLButton too. This will then launch pwPolicyURLButtonURL in the users default browser. An example is below:

If your password change site requires a certain browser, then this can be passed via MCX or the below defaults command. NOTE: Check the apps name, especially if containing spaces:

defaults write org.pmbuko.ADPassMon pwPolicyURLBrowser "<browser name>"

This will then load the URL passed to pwPolicyURLButtonURL in the browser set to pwPolicyURLButtonBrowser.

When using an external website, you may not wish the user to change their password via ADPassMon at all. You can set this with the following command or via MCX. This will still show the above dialog boxes, but when the user clicks “OK” the dialog box is dismissed & not further action is taken.

defaults write org.pmbuko.ADPassMon allowPasswordChange -bool "<boolean value>"

Lastly, as seen in the Preferences window, there is an option to set the “Password Check Interval.” By default, & on v1.x of ADPassMon, this is set to every 12 hours. But you may require this set to another value if your users AD passwords are changed externally. Below is the command to change this value, but it can be done via the preferences window & can also be set via MCX:

defaults write org.pmbuko.ADPassMon passwordCheckInterval -int "<interval in hours>"

Phew!

Yep, there is a lot to take in.. but to help, below is an example populated plist:

Conclusion

I hope this fork does all that I have promised, & please advise if not! This took me about 3 weeks to amend, whilst wearing my many hats of Infrastructure Analyst (well.. Senior Infrastructure Analyst as of today), Dad & husband.

Thanks to Allen Golbig & Richard for the pwPolicyURL section. It’s not a use case I’ve had in any environment, so happy to try & help.

Thanks to Patrick Fergus for pointing me in the direction of how to check keychain lock.

Thanks to Joel Rennich for Keychain Minder & it’s many faithful years of service.

Lastly, to Peter Bukowinski. Thanks for ADPassMon & for dealing with my prattling on over email & twitter!

Enhancements

At some point, I would like to add the following:

1. Change the pwPolicy & keychainPolicy variables to update the new change password XIB. Including a way to auto resize that XIB based on the string passed & add the pwPolicyURL options to that window. With a new tab in the preferences window for people to set their own messages (incl. buttons.. for localisation too).
2. Allow expiry check to be set to a value in the preferences window, instead of the default 12 hours. In 2.0.5 release.
3. Add “sparkle” updater support.