Logging into term serve via remote desktop from a non-binded mac resets AD password and locks account

I have a user connecting to a windows 2012 R2 TermServ from a MacBook, non VPN non server bind, mac is not in active directory and is logged into as a local account. But as soon as RDP connection is established, OWA kicks out that pw has been changed and account has to be unlocked. As long as mac then stays on, account is fine but once rebooted and RDP established again, same thing.

Does the mac rdp have some kind of caching pseudo-binding from a long ago password change?
Who is Participating?

It sounds like there may be a stale password in the mac keychain.  You can try opening the Keychain Access app on the mac under Utilities to see if there is an RDP entry for your windows server.  If not, you can try resetting the keychain which generates a new one.  This will likely clear out any other passwords stored in it as well though.

But if you want to proceed with keychain reset from apple support:

    Open Keychain Access, which is in the Utilities folder within the Applications folder.
    From the Keychain Access menu, choose Preferences.
    Click General, then click Reset My Default Keychain.
    Authenticate with your account login password.
    Quit Keychain Access.
    Restart your computer.
acdevadminAuthor Commented:
What would be pushing the info to AD though and making it require an unlock? A failed login attempt with the bad pw in the keychain? It's not set to do that with 1 failed attempt.
My thought is that it may be trying 3 times back to back with RDP.  Since the RDP program is made by Microsoft, it could be trying multiple logins behind the scenes.  I have seen this happen with Lync so I figured that the RDP program may be trying it too.

Another thing that comes to mind, have you tried logging in with RDP using a different user account?  Setup another domain account that has remote access to the server and see if that account gets locked out.
Cloud Class® Course: CompTIA Healthcare IT Tech

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.

acdevadminAuthor Commented:
Thanks. The challenge is I wont have oft access to this mac. So I need to prepare a bevy of possible solutions for the small window of opportunity I will have access to it. I in fact haven't had access to it yet at all, just a report of the issue. Will hopefully get in front of it this week. I did also think and hoped that maybe there was a rapid fire retry causing the issue, not being to familiar with mac rdp clients. I will be looking at that first with the alternate account login and take it from there. Will report back, Thanks.
Sounds good, thanks for the update.
acdevadminAuthor Commented:
OK  I was able to get in front of the MacBook today.
The issue was in fact stale passwords in the keychain. But theres a little more to it to clarify the situation, if not only for curiosity sake, but also because what I found out may have implications in similar and even non similar situations for others.

First the issue was a little different than I first reported. The lockout wasn't occurring when logging into RDP but rather as soon as you logged into the mac itself. Again it was not bound to AD so were talking about logging into the local mac account.  We watched in AD as seconds after login, the account would show as needing to be unlocked.

I first checked all the startup services to see if there was anything creating some kind of AD bind, whether it be VPN, outlook, a mapped network drive or any other network based service. There was nothing. I then checked the outlook/exchange keychain entry and it was blank, therefore triggering the outlook storage I suppose.

Poking around some more I came across 3 entries for browser based OWA keychain items. This fit with the 3 attempts and you're locked GP rule and sure enough all 3 had stale passwords. I updated the PW and sure enough no more lockouts.

So what is really strange and noteworthy here then is the fact that logging into the profile, triggers these and I guess other(all?) keychain item authentication attempts at startup??? This seems really odd to me but that is what was clearly happening. I don't know mac under the hood enough to decide whether to call this a feature, a bug or a bad idea. Additionally new keychain items appear to not overwrite the old ones in this case, which is creating 3 failed attempts instead of 1 which would at least be easy to overcome, albeit transparently, without discovering this. Maybe someone can shed some light on what this process looks like behind the scenes because I would imagine this could be the source of many troubles related to similar situations with domain logins that could go unnoticed. Could even be exploited I suppose as a pseudo denial of login type of thing. Though I suppose if you know someone's OWA link and username you could do this from any machine.
Great, glad you found the issue in keychain.  I agree that the setup is a bit odd, I couldnt even begin to explain how apple configures there stuff so you might be right on all 3 - feature, bug and bad idea.  What I do know is there is a long history of complications with Mac and AD accounts.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.