Protected Users – Account Operators

Where I work, we don’t use Account Operators. We have a security group that has rights to our “accounts” OU. This OU is dedicated to, you guessed it, all of our user accounts. This includes service accounts, managed service accounts, end user accounts, test accounts, workstation admin accounts, you get the idea. This is important because I placed our account admins into the protected users group and we found two things. One, Microsoft could not duplicate.

First, the Kerberos ticket times out after 4 hours so when the AO’s come in each morning, they will open ADUC with “RunAs” and use their AO account to run it. They leave ADUC up throughout the day so they can work. Come lunch time, they get an error that the account cannot be found and was probably deleted. They click OK, then they close ADUC and perform another RunAs so that it works fine. This behavior does not exist on a remote desktop where I log in and run ADUC without the RunAs.

Second, we have a multilevel AD. Think forest, domain1, domain2, domain3, etc. 9 domains in our forest. When the AO goes into ADUC, it defaults to the domain the AO’s workstation belongs to. When they do a find on a user account, they select “Entire Directory” for the search scope and then hits find. The account comes back, they right click on it and attempt to change the password, unlock the account, modify an attribute, whatever. When they do that they get an error that the account does not exist and may have been deleted. If they switch to the domain the account is in and try again, it works fine.

What I’ve found is, if they switch to the parent domain, i.e. Forest in my model above, then it works just fine. They don’t have to switch to the domain the account is in or anything else. Again, Microsoft can’t duplicate this behavior because we don’t use the built-in AO group so permissions are funny between our production domain and Microsoft’s test lab.

~Ron

Leave a Reply