/long rant incoming
We rolled out AD SSPlus to our campus(about 16k total users) and all seemed to be going well for the most part. However, we started getting calls that some users were unable to get into their email accounts AFTER they tried to reset their password, but they were able to log in to any site that used Active Directory authentication.
This was very strange to hear and I will explain why.
We use Google Business for our email, and we utilize Google Apps Password Synchronizer (GAPS) in our Active Directory environment. For those not familiar with it, GAPS monitors active directory for any password changes, and then replicates those changes to Google. This way if a user does a password reset, or a password change to their AD account, that change will also apply to their email login with Google.
So what we discovered was that if a users attempts to "RESET" their password to the same password they already had, they would get an error in Self Service Plus that they were violating the password history rules and that the password reset was unsuccessful. This is something we wanted to happen.
Here is the issue though:
Once the user received that error message, their email account password with google was actually changed to who knows what, but their AD account password was not changed at all. So the users were able to use all services that relied on AD authentication, but would not be able to log into their gmail accounts unless they called the help desk, and one of the Administrators performed another password reset with AD Users and Groups.
Now, we obviously realize that if the student simply selected "Change Password" in SSPlus, this would not have been an issue. We also realized that if the user selected "Reset" password, and used a totally different password, they would not have had an issue either.
That being said, I was not able to find any option any where in the documentation of AD Self Service plus that stated that on a failed password reset, that it would temporarily change any password in AD to anything for any amount of time, yet this is what appears to have happened(at least for a second or two), and we were able to replicate it.
So in my testing, I determined that although my AD user account password would remain unchanged after a failed password reset, and I would still be able to log in to all AD authenticated services, I would see that a password change was successful using the automated Google Apps Password Synchronization tool, but we had no idea what the password was actually changed to, so I would then be unable to get into my email.
This was clear in the Google logs. It was evident that there was indeed a successful password change occurred and it matched the time stamp of the SSPlus audit logs for the failed user attempt.
So I started digging around the AD SSPlus logs and ultimately found the following line in the serverOut log:
"[13:30:58:653]|[02-16-2017]|[com.adventnet.sym.adsm.common.webclient.accounts.Result]|[INFO]|[86]: Reset with tempPwd is trueisUserCantCP false|"
What caught my eye was the line "Reset with tempPwd is true"
I knew that my google password WAS indeed being changed to something other than what I was typing, and I also knew that my AD access would still work, so clearly something was causing GAPS to change my password for Google.
So I started doing manual resets with my Domain Admin account and started watching the log files for GAPS and I noticed a couple of things.
1, There were far less log entries when I used my elevated account to reset my test accounts password.
2. There seemed to be two duplicated function sets when doing the same password reset, but with AD SSPlus
So I suspect that AD SSPlus is actually making a quick change in AD, and then possible reversing that change when a user tries to reset to the same password, but for some reason, GAPS is only being triggered the first time?, thus the reason it actually changes the gmail password at all.
I opened a ticket on the matter and spoke with Prashaanth via online chat. He was very quick to ask if I had selected the "Enforce Active Directory password history settings during password reset" option under Configuration-> Policy Configuration -> Advanced -> Reset and unlock .
I did indeed have that option selected. He told me to uncheck it and test again, and all was good in the world as far as users being locked out of their google accounts, so kudos to him, but this leaves me with some questions.
1: Why is there any change being made at all that GAPS would be acting on to change the google account password?
2: If AD SSPlus is indeed using a temp password during resets, how come GAPS is not seeing the second change so that the account would stay in sync?
3: If there are settings somewhere that uses a temp password at all during a password reset, where are they and why can't I find them.
4: If we are forced to uncheck "Enforce Active Directory password history settings during password reset" in order to avoid this situation in the future, how are we supposed to prevent the users from simply using password resets to keep using the same password over and over again.
5: Even if we modify our group policy settings to limit the password history(currently at 5), it appears as though it is totally irrelevant if they just reset to the same password, versus a previously used password.
6: What do we need to do to ensure that our users can not abuse the password reset function like this, and that they get an error when they try, but they do not get locked out of their google account, thus prompting a call into the help desk.
7: If you are still reading this far, Kudos to you!!!