Skip to main content

PowerShell + Exchange : Checkbox of Doom

Many of the Exchange Admins might already be familiar with the dreaded checkbox of doom, which causes issues with move request and Mobile devices. Post by MVP Tony Redmond here explains this in detail.

Scenario & the Problem at hand :

When a User connects to the Exchange Server using his Mobile device, then after the authentication the Exchange Trusted Subsystem creates msExchActiveSyncDevices Objects for the User. This will be evident from the below screenshot for one of the User in ADSI edit.



Now what if the Exchange Trusted Subsystem doesn't have permissions on the AD User to create those Objects , all hell is let loose. This was the case I was tackling recently and searching each User in the Directory which had this checkbox of doom unchecked manually is not feasible (am lazy).



Exploration :

This lead me to try out various ways in which I could hunt for the User Accounts (not the protected ones) which had this check box of Doom unmarked. 

Using Active Directory PowerShell Module :


PS C:\> Get-ADUser -Identity dexterposh -Properties NTSecurityDescriptor,Admincount     
                                                                                                                        
                                                                                                                        
Admincount           : 1                                                                                                
DistinguishedName    : CN=DexterPOSH,OU=ExchangeUsers,DC=dex,DC=com                                                     
Enabled              : True                                                                                             
GivenName            : dexter                                                                                           
Name                 : DexterPOSH                                                                                       
NTSecurityDescriptor : System.DirectoryServices.ActiveDirectorySecurity                                                 
ObjectClass          : user                                                                                             
ObjectGUID           : e43a0d6a-52ae-4f3a-99f2-26668a5c4f5f                                                             
SamAccountName       : DexterPOSH                                                                                       
SID                  : S-1-5-21-3807823927-4164601362-1794616738-500                                                    
Surname              :                                                                                                  
UserPrincipalName    : DexterPOSH@dex.com                                                                               

So the logic of searching for Non protected accounts having the CheckBox of Doom unchecked is below:





  • Property named AdminCount should be equal to 0 (zero) or should not be set on the ADUser.
  • AreAccessRulesProtected property should be set to False for the NTSecurityDescriptor on the ADUser
  • I have 2 accounts to demonstrate this scenario: DexterPOSH (Domain Admin) & another test account named test123
    PS C:\> 'dexterposh','test123' | Get-ADUser -Properties NTSecurityDescriptor,Admincount |           
    >>>     Select-Object -Property Name,AdminCount,UserPrincipalName,@{L='AreAccessRulesProtected';E={$_.NTSecurityDescriptor.AreAccessRulesProtected} }                                                                                                                  
                                                                                                                                        
    Name                            AdminCount UserPrincipalName                        AreAccessRulesProtected 
    ----                            ---------- -----------------                        ------------------------ 
    DexterPOSH                               1 DexterPOSH@dex.com                                           True 
    test 123                                   test123@dex.com                                              True 
                                                                                                                                        


    Note that AreAccessRulesProtected property is set to True which means that the Inheritance is blocked for the User as seen in the below screenshot.




    Now let's write PowerShell code snippet which will again check this box for test123 user.


    One of they ways is already shown in the post here, but I tried a different way using the PSProvider for ActiveDirectory :) (many ways to skin the cat ).
    Nothing fancy but used Get-ACL & Set-ACL to modify the permissions.

    Below it is in action :


    PS AD:\OU=AirWatchTest,OU=ExchangeUsers,DC=dex,DC=com> ls
    
    Name                 ObjectClass          DistinguishedName
    ----                 -----------          -----------------
    Abdul.Yanwube        user                 CN=Abdul.Yanwube,OU=AirWatchTest,OU=ExchangeUsers,DC=dex,DC=com
    test 123             user                 CN=test 123,OU=AirWatchTest,OU=ExchangeUsers,DC=dex,DC=com
    xyz abc              user                 CN=xyz abc,OU=AirWatchTest,OU=ExchangeUsers,DC=dex,DC=com
    
    
    PS AD:\OU=AirWatchTest,OU=ExchangeUsers,DC=dex,DC=com> $ACL = Get-Acl -Path '.\CN=test 123'
    PS AD:\OU=AirWatchTest,OU=ExchangeUsers,DC=dex,DC=com> $ACL.SetAccessRuleProtection
    
    
    MemberType          : Method
    OverloadDefinitions : {System.Void SetAccessRuleProtection(bool isProtected, bool preserveInheritance)}
    TypeNameOfValue     : System.Management.Automation.PSMethod
    Value               : System.Void SetAccessRuleProtection(bool isProtected, bool preserveInheritance)
    Name                : SetAccessRuleProtection
    IsInstance          : True
    
    
    
    PS AD:\OU=AirWatchTest,OU=ExchangeUsers,DC=dex,DC=com> $ACL.SetAccessRuleProtection($False,$true)
    PS AD:\OU=AirWatchTest,OU=ExchangeUsers,DC=dex,DC=com> Set-Acl -AclObject $ACL -Path '.\CN=test 123' -ver
    VERBOSE: Performing operation "Set-Acl" on Target "AD:\CN=test 123,OU=AirWatchTest,OU=ExchangeUsers,DC=dex,DC=com".
    VERBOSE: Performing operation "Set" on Target "CN=test 123,OU=AirWatchTest,OU=ExchangeUsers,DC=dex,DC=com".
    PS AD:\OU=AirWatchTest,OU=ExchangeUsers,DC=dex,DC=com>
    

    Now one can verify the changes in the AD Users & Computers console.




    This can easily be scripted using either the AD PowerShell Module or using ADSI (check out the below links).

    Happy Scripting!
    Resources :


    Exchange 2010 problems due to insufficient access to Active Directory
    http://thoughtsofanidlemind.com/2010/10/08/ex2010-insufficient-access/

    CheckBox of Doom
    http://enterpriseit.co/microsoft-exchange/checkbox-of-doom/


    enable inheritance on all AD user accounts

    http://enterpriseit.co/microsoft-active-directory/enable-inheritance-ad-user-accounts/


    Checking For Protected ACLs In Active Directory (using ADSI )
    http://blogs.technet.com/b/bill_long/archive/2010/04/13/checking-for-protected-acls-in-active-directory.aspx

    Issues With AdminSDholder
    https://social.technet.microsoft.com/Forums/en-US/269e0ab2-6e65-4001-abcb-3c89f6f938fd/issues-with-adminsdholder?forum=winserverDS

    Popular posts from this blog

    Test connectivity via a specific network interface

    Recently while working on a Private cloud implementation, I came across a scenario where I needed to test connectivity of a node to the AD/DNS via multiple network adapters.  Many of us would know that having multiple network routes is usually done to take care of redundancy. So that if a network adapter goes down, one can use the other network interface to reach out to the node. In order to make it easy for everyone to follow along, below is an analogy for the above scenario: My laptop has multiple network adapters (say Wi-Fi and Ethernet) connected to the same network. Now how do I test connectivity to a Server on the network only over say Wi-Fi network adapter?

    PowerShell + SCCM : Run CM cmdlets remotely

    Today I saw a tweet about using implicit remoting to load the Configuration Manager on my machine by Justin Mathews . It caught my eye as I have never really tried it, but theoretically it can be done. Note - The second tweet says "Cannot find a provider with the name CMSite", resolution to which is in the Troubleshooting section at the end.

    PowerShell : Trust network share to load modules & ps1

    Problem Do you have a central network share, where you store all the scripts or PowerShell modules ? What happens if you try to run the script from a network share ? or if you have scripts (local) which invoke scripts or import PowerShell modules stored on this network share ? Well you would see a security warning like below (Note - I have set execution policy as 'Unrestricted' not 'bypass' here): Run a .ps1 from the network share Well this is a similar warning, which you get when you download scripts from Internet. As the message says run Unblock-File cmdlet to unblock the script and then run it, let's try it.