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
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.
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!
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>"
Yep, there is a lot to take in.. but to help, below is an example populated plist:
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!
At some point, I would like to add the following:
- 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).
Allow expiry check to be set to a value in the preferences window, instead of the default 12 hours.In 2.0.5 release.
- Add “sparkle” updater support.
115 thoughts on “ANNOUNCING: ADPassmon v2 fork”
cool. Have you compiled it to an app?
Added a link to it now!
Just re-added it. Please check the post.
Awesome! Good job and can’t wait to play around with it!
I don’t suppose you have instructions on how to build this…I did the build in Xcode but it bombs out with mainmenu.xib…
Sorry John, I’ve updated the post with a link to a compiled version.
I only see the github link to the source. Sorry to be a pest.
got it now 🙂 thank you!
It’s back! Sorry but looks like something went screwy updating the post.
I haven’t been able to get the – sudo defaults write org.pmbuko.ADPassMon.plist pwPolicyURLButton – commands to work. They go into the plist, but they never activate. I had to use the commands from yourmacguy’s page to get the policy dialog box to appear as well. – defaults write org.pmbuko.ADPassMon pwPolicy “Your password requirement message goes here.”
Odd. Make sure you remove the .plist extension.
Are you setting some prefs via MCX? Also, please make sure the app is quit when using the defaults command.
No, defaults write. I tried quitting out and removing .plist, same results.
I’ve amended the command as I have left the extension. Doh!
Are you setting both the pwPolicyURLButton & pwPolicyURLButtonURL keys?
I am, yes.
I think I’ve found it. Please try pwPolicyURLButtonTitle & pwPolicyURLButtonURL. Just cocked up the commands.
Those worked, but I had to remove the sudo from the defaults write! Unfortunately it lead to another issue with the browser launch. It just goes to Choose Application window. I tried to use the above command and put in “Firefox.app” but it still returns Choose Application window.
Ah my silly commands. I’ll amend. Try just Firefox. Does Firefox have an second F in it?
I tried Firefox, Firefox.app, /Applications/Firefox, and /Applications/Firefox.app
The Plist shows the changes…
Ok let me check. I tested with Google Chrome & Safari.
This will hopefully remind me not to add things last minute!
err Safari didn’t launch either. If I do Safari.app nothing happens – console shows “File wasn’t found. (error -43). If I do Safari, then it prompts for the app selection. So close and yet so far. This is a killer feature that will help greatly – so I’m glad you chose to add it!
Right, as your being very helpful & I can’t yet get onto my computer.. Can you try the following in AppleScript?
tell application pwPolicyURLButtonBrowser to open location pwPolicyURLButtonURL
Substituting the variables for the values your passing. 1st without quotes, & then with quotes please.
With the “”‘s or without?
With quotes (“)
Awesome. So I’ll need to set my variable to quoted form of pwPolicyURLButtonBrowser.
I’ll fix that later. Thanks for persevering!
wanted to give you another heads up, when I use the pwPolicyURLButtnBrowser “Firefox” command it launches Safari and goes to the URL as well as Firefox which just sits there. I reset defaults and tried again… same results.
err, yeah, i didn’t have FF set as Default, once I set as default then it launched fine in FF only 🙂
I’ve corrected that just now. Having an issue with quoted form of in Xcode. 🙁
Done! Can you please try the newly linked 2.0.4 version in the article?
Thanks for your help with this.
it seems okay, 2.0.4 is loaded, didn’t need to change the plist or anything, i will reset everything and reconfigure it again in a few minutes. One thing I noticed, is that if I do the launch browser, and do the reset there, the dialog box goes away to change the login keychain. I think the expected (assuming the workflow in my mind is accurate) result, is that the user goes to change password, the dialog box appears with the OK and Launch Browser button (as they need to change there first), the user resets their password through the browser. They close teh browser and ADPassmon’s dialog box is closed. What directs the user to the next steps of changing their login keychain? I also tried the part in your doc that shows that if keychain access is open then it’s supposed to prompt to close it. It doesn’t do that either.
Ah, gotcha. It’s not a workflow I use so this is all great information.
I’d advise setting the pwPolicy to advise the user to select “Change Password” once updated via a password site. Like;
Click “change password” > prompt user via pwPolicy to change via web site & once changed click “change password” again to update macs pass & keychain.
Does that make sense?
The keychain access bit, I’ll revisit.
I’ve been working with MCX and 2.0.5, and I think I found a small bug. In 2.0.4, I added the pwpolicy setting to launch a browser. That works fine when I use that button and when I just choose OK (though it launches the local password change app as per your screenshot). However, in 2.0.5. The launch browser works, but the OK button does not. it just closes the dialog box.
I think i’ve found what I did wrong, please test the 2.0.6 version linked in the post.
same result 🙁 – btw using MCX now, if that makes a difference.
Sorry seeing it too. I’ll post a new 2.0.6 when corrected. Please delete the copy you have.
Try again please! Think it’s sorted now.
Less code is more.
that worked. err.. but found another one now. the detectkeychainlocked set to true, doesn’t seem to work either. I manually locked the login keychain through keychain access, but it never prompts like your screenshot shows.
You’ll need to quit & relaunch ADPassMon with the Keychain locked.
This should pick it up on launch.
It’s meant to be run @ login, which is when the keychain would be locked.
… you’re right. my bad. it’s working as expected 🙂 Thank you for all your help!
No thank you for the testing! Together, we’ve got it working. 🙂
well, I spoke too soon. soo close…. I noticed when I do the reset via browser, then go back and do the “OK” button it doens’t bring up the dialog box to change the login keychain. If I exit the app and go back in, then it does.
hmm.. so isn’t the keychain password being updated when the password is changed?
You shouldn’t be prompted to change the password & then the keychain, it should update both via the change password window.. you only see the keychain prompt when locked or it errors on updating the keychain password.
Well, see, we have 2 systems. LDAP and AD. If we change via LDAP it will replicate to AD, but if we change only the AD side, then LDAP doesn’t update. If we change the password when the Mac prompts to change it, then it only updates the AD side. That’s why we needed the web browser thing to work. However, keychain will update if the user logs out and logs back in. I guess I don’t need them to do it this way, the keychain lock would handle it I think…
either way, the app wont let me go to the browser then to the other one. Not sure if that’s by design..
As mentioned this is not a workflow I use, so thanks for all the detailed information.
I guess we could have another MCX key that will prompt for Keychain Update after clicking the button to open Safari.. would that work?
Sorry, I tried replying from my phone turned out to be too complicated. I believe the workflow in my mind is incorrect. The way you have it is correct, as when the user logs out and logs back in, they will use the new password and theoretically update their keychain passwords. So no changes needed. sorry about that.
Really thanks for persevering with this. Hope it comes in usual.
Drinks all round if we meet!
I really appreciate the work being put in here!
I’m running into an issue, though, where when I change the password (Version 2) I get the error “Keychain update failed. Please try again,” then the “Your Keychain is Locked!” window. If I just close that window, though, and open Keychain Access, it isn’t locked. Further, the keychain was in fact updated successfully.
Any idea what might be bringing up the keychain update error given the keychain was actually successfully updated?
Any help is appreciated,
That’s odd.. reset my own earlier & it worked..
Are you using the v2.0.7? Also, which OS?
Just got around to testing this out today after dealing with another situation of Keychain Apocalypse on a machine yesterday. This is *such* a huge problem for enterprise Mac usability so thanks for taking this on Ben!
That said, I’m seeing similar failures in updating passwords as I see when I trying to use the local Users/Groups PrefPane. In this case, the following entries dropped into Console:
4/29/14 12:56:01.243 PM ADPassMon: All password fields populated & new & verify match…
4/29/14 12:56:01.330 PM ADPassMon: Password change failed. Please try again.
Alternatively, I tried configuring the appropriate plist domain values to present a button to reset user’s password over the web, but when is that option presented? Specifically, how do I get the “Change Password…” option to present the dialog for the web link instead of the old/new password dialogs? For reference, here’s what I’ve got configured currently:
US-MAC-204804:~ mactest$ defaults read ~/Library/Preferences/org.pmbuko.ADPassMon
allowPasswordChange = 1;
enableKeychainLockCheck = 1;
enableNotifications = 1;
expireAge = 90;
isBehaviour2Enabled = 1;
keychainPolicy = “Keychain Policy text here.”;
“menu_title” = “[89d]”;
pwPolicyURLButtonTitle = “Login to Webmail to Change Password”;
pwPolicyURLButtonURL = “https://mail.myorg.com/ecp/?rfr=owa&p=PersonalSettings/Password.aspx”;
pwdSetDate = “16189.65033082116”;
selectedBehaviour = 2;
tooltip = “Password expires on Monday, July 28, 2014 at 11:36:34 AM”;
I am also having this same problem! I get ‘Password change failed. Please try again.’ with the only option of selecting ‘OK’. I would like to present the button to access the web as an alternative.
Sorry i’m away on a CCE in Amsterdam at the moment.. but are Cliff I can see you do not have the pwPolicy key configured too… can you please set that to some text.. then the change password function should move to the version that prompts the user to reset externally.
FWIW, I’m going to do an update that will add an extra menu to the preferences so the new “features” can be set there rather than the plist alone.. this will then show the dependencies to make it clearer.
Sorted, thanks mate!
@Cliff, I added (see below) which did the trick.
defaults write org.pmbuko.ADPassMon pwPolicy “The password requirement should be at least 14 characters long with numbers, lower case and uppercase letters.”
Odd. When I try to use the exact same pwPolicy default, I get the following error back:
defaults[57889:507] Unexpected argument password; leaving defaults unchanged.
Got the initial pwPolicy dialog presenting a dialog, but clicking OK button (which does not match designated text anyway) simply brings up the standard ADPassMon Change Password dialog I had before.
FWIW, here’s what I’m set at:
US-MAC-MYMAC:~ myname$ defaults read ~/Library/Preferences/org.pmbuko.ADPassMon
allowPasswordChange = 0;
enableKeychainLockCheck = 1;
enableNotifications = 1;
expireAge = 90;
growlEnabled = 1;
isBehaviour2Enabled = 1;
“menu_title” = “[40d]”;
pwPolicy = “Passwords should be include at least 8 characters, mixed case, numbers or special characters, and not have been used in the last year.”;
pwPolicyButtonTitle = “Login to WebMail”;
pwPolicyURLButtonURL = “https://mail.myorg.com/ecp/?rfr=owa&p=PersonalSettings/Password.aspx”;
pwdSetDate = “16147.86153487139”;
selectedBehaviour = 2;
tooltip = “Password expires on Monday, June 16, 2014 at 4:40:37 PM”;
warningDays = 14;
OK I’m getting far better results by simply managing MCX via Casper. Seems to be working now, though I do see some inconsistency in system vs user-level management of MCX values.
We use user level, do they work better?
great job on this! I would like to lock the preferences using an MCX (prefsLocked True) but at the same time allow the user to check or uncheck “Use Notifications”. Is there a way to do that?
Nope. But they should be able to hide the notifications from Notification Centre.
How could I check the add to login items via script? I am copying over the org.pmbuko.adpassmon.plist but this is the only box not carrying over.
Tbh, I launch it via a LaunchAgent. That LaunchAgent sits in /Library/LaunchAgents/
You can also use a configuration profile to add ADPassMon as a login item. You can’t create this within Casper, but you can create in Apple Profile Manager and then import it into Casper. This is what I’m doing.
Ben, I’m running into an issue where ADPassMon just doesn’t seem to function. v1 works fine in my environment. v2 (even with v1 behavior enabled) does not. It doesn’t seem to be pulling the expiration date correctly as it displays -162886d as the expiration, and then prompts me to change my password when it starts up. When I re-check password expiration, I either get no change or the app locks up. I have all the settings reset to default, just using v2 behavior. I’m running 10.9.4, and if there’s any other info I can provide that might help I will gladly do so. I’d love to get this up and running as it’s become a huge problem in our environment. Thanks!
Just to give you more detail, I just downloaded and compiled 2.0.9 and the days now display -169293d. I’ve refreshed the ticket in Ticket Viewer, and tried just about every combination of settings there is. Setting to manual just seems to subtract some interval of days (for example, if I set it to 90 days the number becomes -169293d). It looks like it isn’t pulling the correct date and time, either from AD or the local machine.
That should’ve said “the number becomes -169203d”.
Hmmm.. I’ve seen that when using a local account. Or an account with no password expiry.
How long is it before the password is due to expire?
Our AD policy is 90 days. It looks like I should have about 30 days before mine expires. I actually removed the domain and rejoined, and now I get -60 as a timer. The notifications say my password expires on the day I last changed it. Progress?
Hmm.. Are you manually setting the expiration days? If not, maybe give that a go.
We’re seeing the same large negative number issue on a number of AD accounts as well (it seems to be account-dependent), but can’t find anything different about them in ADSI Edit. They have a valid expiration date, they’re not set to never expire, and they share the same 60-day password expiration as the rest of our accounts. The problem persists with a build of 2.0.10 from the GitHub source, and actually persisted through a full re-image of one of the user’s machines.
Setting the expiration days does not resolve the issue; the number doesn’t change unless we set it to an incorrect value (and then it only changes by the difference between the value we set and the value that should be entered).
I’m convinced there must be something about those accounts that is causing the app to have trouble determining their expiration. I just have no idea what that would be. 🙂
Will you be releasing 2.0.9? 2.0.6 is the last compiled version…
Probably not, making some updates/fixes so will update further then compile.
— Amended password change to not give a false positive when changing
— Amended keychain update to create properly on 10.8
— Added re-check of expiration post change to update manubar
— Enabled return key on password change window
Ben – I’m seeing some odd behaviour in 2.0.9. I just installed it this morning on a freshly built iMac with 10.9.4 that was joined successfully to our AD domain. When I choose change password and fill out the appropriate information the OK button has no text in it and the password change doesn’t seem to actually work. After changing the password I did a restart of my mac then tried to login with the new password which failed. So I logged in with the old password and it worked. however after logging in my keychain was locked. Looks like the password was not updated in AD but was updated in the keychain when I used 2.0.9 to invoke the password change.
Update: I’m not sure why the above actually happened but after several more attempts it did start working correctly. Maybe there was a network glitch when the AD password was being changed… Not sure but all subsequent password changes on the iMac and a second computer were successful.
Thanks for your work on this tool!
great writeup! Is there away to turn off the menubar icon so that it’s as transparent as possible:?
Would implementing: https://github.com/macmule/ADPassMon/issues/2 work for you?
Yes that would be great! The goal would be to make as transparent and understandable to the user. The presence of language like kerberos has confused some users. Thank you so much for considering the request and for your work.
Love the idea, but I’m running into some trouble. Basically, the application takes about 4 or 5 minutes to start up and become responsive. By that point, folks have already clicked “cancel” a bunch of times and are already on the phone with me. Has anyone else run into this problem, and is there something I’m missing? Thanks!
4-5 minutes to startup where? At login? What OS? What settings have you set?
No worries, I figured out what was going on. Watching the Console on login (it was happening whenever I started up the application, not just on log in or start up) and it turns out it was trying to contact our DNS server to get to our AD, but the primary DNS was set incorrectly on the machine I was on. Fixing the primary DNS to point to the correct server made it work like a charm. I’m continuing to test implementation of this in our environment, but so far things are going very well and I look forward to rolling this out to our users. Hopefully no more frantic calls and e-mails about “that keychain thing again.”
It might be that my issue is just a matter of workflow, but I’m having a spot of trouble. With the assumption that my users will not be proactive about changing their password before the expiration date, users are prompted after attempting to log in with an old password to reset their password. By doing so, the OS changes their login keychain password to match without prompting the user, however it does not seem to be changing their local item keychain password to match. My understanding is that this fork will check to see if the login keychain password matches up with the login password, but does it check the local items keychain password? Is there something I’m forgetting?
Any chance this can be adapted to work with OS X Server’s OD? Apple doesn’t even provide decent notification to the users of it’s own server product, and the keychain updates are relevant to that environment as well. #pleasesayyes
Sorry I wouldn’t know as haven’t touched OD for around 4 years.
If you could get the password expiration via a script, then parts of this could certainly be ported over.
I have also been having a heck of a time with OD on server 3.2.2. AFAIK there is no way to get the password expiration from the OD server. I can live with that, the real pain I am seeing is that when a user updates their password from the login window the local items keychain is not being updated with the new password. I have found that if a user changes their password via the OD servers internal website and then logs back into the client computer they are prompted with the familiar update login keychain dialogue. If the user update the login keychain ( using their old password ) this seems to update the local items keychain. However if the network user uses more than one computer the other computer’s local items keychains are not updated. The only fix I have found so far is to follow apple’s kb article and nuke the keychain folders however, it appears in 10.10 at least that this would also nuke any saved web passwords in safari and of course mail.app’s passwords.
However, I believe that this may be fixable. I have been doing quite a bit of testing and it appears (at least on 10.10) after the password is changed via the login window if you lock then unlock the login keychain you will be prompted with a window to update the local items keychain. I am not very good at scripting at all, but I think it would be possible to take some parts of the code to accomplish this.
Basically check if the local items keychain is locked and if it is locked lock the login keychain then unlock the login keychain. This should bring up the dialogue to update the local items keychain. Then force a restart of the computer. That at least should fix the keychain issue. I am going to try to attempt to hack this together, however, help from anyone knowledgeable would be greatly appreciated!!
ive installed the Maclogon and ADpassmon on a fully updated 10.9.5 joined to my domain with centrify and cant get these tools to function properly. Ive tried both auto and manual mode hitting enter afterwards and i always get a number like -151204 days. any help would be greatly appreciated.
i also forgot to mention that when i get prompted to change my password. i change i, then try to login with the new password it says its incorrect. if i put the old password in again, i get the popup to change my password again.
Sounds like the app cannot get the correct information from the domain.
hmm ok. any suggestions?
Sorry I missed the Centrify bit. AFAIK this only works with the built in AD plugin.
did i miss something? was there an AD plugin i was supposed to setup on the server side to get your tools to work? if so then clearly i missed that part.
Nope. I meant that I have never used Centrify & have always bound my Macs using the built in plugin.
So, if you’re binding to AD using Centrify.. I very much doubt it will work.
I removed the centrify binding to AD, joined it back to the domain using the builtin method and it works like a charm. Thanks! FYI centrify sucks gorilla taint for anyone thinking about using it.
Does the fork support kerbminder?
Not yet. But there will be an attempt I merge the forks & then support will come.
& attempt started here.
Please test & log any issues on GitHub
I have a few clients whose ADPM is displaying a [ ? ] in the menubar instead of the number of days to expiration, and can’t for the life of me find out how to fix it. Deleted prefs. Rejoined to AD. Deleted app and reinstalled. Any ideas?
Edit… I remove the V2 fork and installed the latest v1.x version and the days til expiration displays correctly. Would rather use your version though…
I’ve started the work on merging my fork with main, can you test this version & advise on github is you have any issues?
I’m trying to find a solution that will work for our Macs that are outside of the company network and un-able to reach our Active Directory, some never get on the VPN so i’m guessing ADMonPass wouldn’t be able to update ?
Would it be possible to write the expiry date to the applications plist ?
i’m wondering if i could make an extension attribute on our JSS that would retrieve the expiry date from AD and then write that back to the external Mac, (the Macs can reach the JSS externally)
i could scope that to happen on only Macs outside of out network ?
Maybe i need more coffee ? or less ??
Thanks for all your work on this!!
so after less coffee i’ve pondered the idea again and i guess there is no way for the JSS to directly access AD to retrieve the SMBPasswordLastSet LDAP attribute, it can only be retrieved between the Mac and AD.
What’s the behaviour of ADPassMon if it can’t reach AD for a long time ? i really want to use it as it will help remove the word Keychain from our daily vocabulary! though we have a good quantity of Macs outside of our network that rarely go on the VPN.
ADPassMon will not really help with limited domain connectivity.. In fact, I’d question why those that are so infrequently on the domain are domain bound.
Have you had any luck using this version with fine-grained password policy? I have not been able to.
any plans to include the kerbminder functionality of the current adpassmon 🙂
We’re working on it: https://yourmacguy.wordpress.com/2015/09/09/adpassmon-is-de-forking/
Has anyone figured out a way to suppress the repeated system notifications that the local items keychain is locked? ADpassmon helps, but the local items keychain prompts still appear repeatedly in front of the window asking the user to change their password.
Hi Ben, I am digging ADPassmon, great utility. Do you have a compiled version of the latest ADPassmon available please ??
Ignore that 🙂
Oh. Haha. 🙂
Hi i am trying to implement this software using jams software, but overtime i run it on the machine it doesn’t show up on the toolbar, and when i run the exec i get
Manual override not enabled
I have tried using the runIfLocal set to true but I am still getting this notification on a couple of my macs. If that doesn’t show up them i am getting a negative value(-17038) on the toolbar. Any ideas what we can do to fix this? I have been scouring the web. Hopefully this is the right place to ask this question.