I recently completed a Mobile Device Management proof of concept for a medium sized Financial firm with about 500 users. I ran into an issue that I’ve seen before where the Good Messaging server would place some handhelds in a paused state therefore stopping the flow of all email to said devices. A very interesting and relatively unknown process in Active Directory is thought to be the culprit.
Naturally, when rolling out a new piece of technology the IT department will be the first one to get upgraded and test everything out. Well, that’s exactly what we did here and everything went smooth except for many handhelds that were used by the in-house IT folks. One of the pre-requisites required before installing Good Messaging Control or Blackberry Enterprise Server is to grant the respective software’s AD service account the ‘Send-As” permission to all domain users. I usually call Good’s account ‘Goodadmin’, and the BES account ‘Besadmin”.
Now, in the Good Messaging Installation guide a clear warning is stated that if you have a Good Messaging enabled user that belongs to a Active Directory Protected Group the user will experience mail flow issues to/from the handheld. Below is a list of the built in AD groups that are considered protected in Windows Server 2000 SP4 all the way through Server 2008.
• Account Operators
• Server Operators
• Print Operators
• Backup Operators
• Domain Admins
• Schema Admins
• Enterprise Admins
• Cert Publishers
Now, as we rolled out Good’s software to my client’s IT department we noticed that everything would work, but only for a few minutes, which is obviously due to the aforementioned warning. Many of them were indeed in protected groups or used to be. The Good Messaging installation guide’s suggestion to resolving this issue is to simply remove the user from the protected group. In a smaller environment this would be something that could possibly be done on the fly but in a firm with a dozen administrators this can be a long tedious process. Since many admins create critical dependencies to their account removing them from one of these protected groups can break one or more critical functions.
At this point it is important to understand why and how the Active Directory process strips off the ‘Send-as’ permission on user accounts in these groups. Well, the “why” was easily accepted and understood. These groups grant “God mode” to many of the critical functions in a Forest/Domain privilege to any users that become a member. Also, without this process it could be possible under several scenarios for a non-elevated user to grant themselves elevated privileges. With that being said protecting these groups from unauthorized users should also involve a human effort with standard approval and audit process to catch any mistakes. To answer the “how” this all works we have to look at a few things that run under the covers.
First, when you add a user to one of the stated protected groups an attribute named “AdminCount” on the user object is changed to the value of “1” from “Null”. Now, a task named Security Description Propagator (SDProp) that runs every 60 minutes in the lsass.exe process becomes the “bouncer” of the club and ejects any extra ACL changes that aren’t on the “master list”. This task is owned and run by the PDC Emulator in the domain. The “master list” is owned by the object “adminSDHolder” locted at CN=adminSDHolder, CN=System, DC=example, DC=com. This process will also uncheck the Enable Inheritance option that you would find under the NTFS security section. There are a few workarounds to avoid losing your permissions and the solution will depend on your firm’s policy. Obviously the “right” way to solve this is to remove a user’s account for the protected groups and create them a supplemental admin account. It is important to note that even if you remove a users from the protected group the “AdminCount” value will NOT change from “1” back to “Null” (which is why users who were removed months ago were still having the issue). You will have to manually go into ADSIedit and manually change the attribute back to “0”. So, if you can’t remove the user from the protected group in a pinch the one solution I like is to modify the “adminSDHolder” object’s permissions in ADSIedit so the changes propagate to anyone in the protected group. This will prevent my “send-as” permissions from being overwritten. Now, let’s sum up the process in a bulleted list.
1. Aligned with the pre-reqs of the Good Messaging software we have granted the GoodAdmin AD service account ‘Send-As’ rights to all domain users.
2. User “John” is activated on the Good Messaging or Blackberry server and everything is working great.
3. John is added to one of the “protected” AD groups, let’s say Domain Admins.
4. Now, because of his newly granted elevated privilege in the background the “AdminCount” attribute on John’s account has changed from ‘Null’ to ‘1’. Now, when the PDC starts the SDProp task it will know to check his account against ‘adminSDHolder’s ACL’s (master list).
5. Since adminSDHolder’s ACL has been pre-populated by MS with bare minimum permissions which of course do not include Send-As rights for GoodAdmin John’s ACL’s will be overwritten and inheritance will be turned off. Good Messaging (Goodadmin) will now notice that it is not able to send an email for John and will place his account in a paused state and completely interrupt all sending and receiving.
6. To resolve this issue we go directly into ‘adminSDholder’ properties via ADSIedit and client on the ‘Security’ tab. From there we add Goodadmin and grand ‘Send-as’ rights. When the SDProp process runs again in 60 minutes you will notice that all of your users in any of the protected groups will now keep the “Send-as” ACL and everything will start working again.
This solution should be executed with caution and align with your security team’s policies. For an administrator you should always keep the daily used account out of these protected groups. If elevated access is needed create a secondary account specifically for that administrator.
-Justin Vashisht (3cVguy)