gMSAs are a Little Bit Weird

In my last post on retrieving the Group Managed Service Account password, I covered the fact that there is an old password value and a current password value. I have found no documentation on why they both exist. I did testing a while back and confirmed that only one was valid. This seemed odd and didn’t make sense in the context of a large enterprise. If a gMSA is used all over the globe in different AD sites, how do you make sure that all the services using the account rotate at the same moment. You don’t. While password changes use urgent replication and replicate to the PDCe immediately, this may still not be sufficient. There are two time intervals listed in the msDS-ManagedPassword explanation:

·         QueryPasswordInterval (8 bytes): A 64-bit unsigned integer containing the length of time, in units of 10^(-7) seconds, after which the receiver must requery the password. The QueryPasswordInterval field MUST be placed on a 64-bit boundary.

·         UnchangedPasswordInterval (8 bytes): A 64-bit unsigned integer containing the length of time, in units of 10^(-7) seconds, before which password queries will always return this password value. The UnchangedPasswordInterval field MUST be placed on a 64-bit boundary.

I was unable to decipher what exactly those mean, in terms of the password change, so I decided to see what happened by querying the blob repeatedly before, during, and after the change. While doing this, I tested LDAP binds for each password and recorded the results, as well as the key version number (KVNO). The KVNO is simply the version number for the password.

It is nearly impossible for the gMSA, and all the services running as it, to rotate at the same movement.  It is impossible, in an enterprise, to even get the new password everywhere instantly. Instead AD pre-stages the new password. This is why the “must requery” time is always 5 minutes before the password change and both passwords are accepted for 5 minutes after the change. The test data below shows exactly what happens.  

TestTime	OldPwd	NewPwd	KVNO	NextQuery	PwdGoodUntil
12/29/2016 19:53	FALSE	TRUE	2	12/29/2016 19:59	12/29/2016 19:54
12/29/2016 19:54	FALSE	TRUE	2	12/29/2016 19:59	12/29/2016 19:54
12/29/2016 19:54	FALSE	TRUE	2	12/29/2016 19:59	12/29/2016 19:54
12/29/2016 19:55	TRUE	FALSE	2	12/29/2016 19:59	12/30/2016 15:54
12/29/2016 19:55	TRUE	FALSE	2	12/29/2016 19:59	12/30/2016 15:54
12/29/2016 19:56	TRUE	FALSE	2	12/29/2016 19:59	12/30/2016 15:54
12/29/2016 19:57	TRUE	FALSE	2	12/29/2016 19:59	12/30/2016 15:54
12/29/2016 19:58	TRUE	FALSE	2	12/29/2016 19:59	12/30/2016 15:54
12/29/2016 19:59	TRUE	FALSE	2	12/29/2016 19:59	12/30/2016 15:54
12/29/2016 20:00	TRUE	TRUE	3	12/30/2016 15:59	12/30/2016 15:54
12/29/2016 20:00	TRUE	TRUE	3	12/30/2016 15:59	12/30/2016 15:54
12/29/2016 20:01	TRUE	TRUE	3	12/30/2016 15:59	12/30/2016 15:54
12/29/2016 20:02	TRUE	TRUE	3	12/30/2016 15:59	12/30/2016 15:54
12/29/2016 20:03	TRUE	TRUE	3	12/30/2016 15:59	12/30/2016 15:54
12/29/2016 20:04	TRUE	TRUE	3	12/30/2016 15:59	12/30/2016 15:54
12/29/2016 20:05	FALSE	TRUE	3	12/30/2016 15:59	12/30/2016 15:54
12/29/2016 20:05	FALSE	TRUE	3	12/30/2016 15:59	12/30/2016 15:54
12/29/2016 20:06	FALSE	TRUE	3	12/30/2016 15:59	12/30/2016 15:54
12/29/2016 20:06	FALSE	TRUE	3	12/30/2016 15:59	12/30/2016 15:54

This mostly makes sense, except that in the 5 minutes prior to the password change, the value clearly called CurrentPassword, is wrong. It has shifted to the PreviousPassword value. Also, the account is set to a one day password change interval, yet the next change is not in 24 hours, it is in 20 hours. If you decide to use the code to implement your own use of a gMSA it is vital to keep these things in mind.  I think this is all explained by Microsoft here, but it is hard to read.  It makes more sense after having run the test.