We have been using Group Managed Service Accounts (gMSAs) in our environment without issues until recently. We deployed several apps to production where the gMSAs had been created about 60 days ago but had not yet been used. On the gMSA's attributes, the default value of msDS-ManagedPasswordInterval is 30 days.
When install-adserviceaccount was ran as part of the deployment script the pwdLastSet, msDS-ManagedPasswordId and msDS-ManagedPasswordPreviousId attributes were updated but then the app pool kept failing to start and we saw the badPasswordTime update with every attempted start. The issue was fixed by running install-adserviceaccount again, which presumably retrieved the correct password from AD. We observed this behavior with multiple accounts where the number of days when it was first used was greater than 30 days. We have not seen this issue where the account has been used within 30 days of creation (over 150 accounts).
Another variable is that we are deploying to a load balanced environment, so the gMSA could be installing on multiple servers at the same time. Not all servers had the issue with the same gMSA.
We have not been able to reproduce this issue with manual testing outside of running our scripts so I am wondering if there is a race condition between the password being changed and the password being retrieved from active directory before the change has fully synced. Is there any way to check whether this is the case?
Has anyone else encountered this behavior?
The target servers and domain controllers (5) are all running Windows Server 2012 R2 and are fully patched. The domain functional level is Windows Server 2012 R2 as well.
