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

EDIT:

So after some past reading(responses to my own thread ironically), I now know that when using the enforce password history from AD option, we are not actually doing a password reset, but a password change.

So the system, unknown to the user, actually resets their password to a temporary password that only SSPlus knows.  It then hides(assuming you have that selected) the "Old Password" field, and only shows the user the new password and confirm password fields.

I also understand that the "Reset" password function is an elevated function of AD that only Admins have access to, thus the reason that the Group Policy password settings do not apply when using it, but knowing all that....How on earth are other organizations allowing users to select the "reset" password option, AND ENSURING that they are not resetting it to the same password, a previously used password, or a less complicated password that does not meet the AD password complexity rules while ALSO ENSURING that any 3rd party items, like Google mail in my case are not being changed before the user ever even sees a password change window?

Would using the ADSSPlus password synchronization tool with Google Apps resolve this issue or would we be facing the same issue if we chose to use the "Enforce Active Directory password history settings during password reset" option?

The issue we have with using it versus using the existing Google Apps Password sync(GAPS) tool, is that the GAPS is sitting in AD, and also affects newly created accounts(which we have automated processes to create new accounts), and the self service password sync tool appears to only affect password changes and resets from users that actually use the ADSSPlus tool.

In other words, if a newly created user logs into their machine for the first time, and is prompted to change their password, that password change is replicated to their Google account as well BECAUSE the tool resides in, and monitors AD.  Does this ADSSPlus password sync tool do the same thing?