(2015-12-17) The “Get-ADPermission” CMDlet Reports A Corrupted ACE

You are managing Exchange through PowerShell and this time you are checking the AD permissions on a user account with a mailbox. For that you use the following PwoerShell command line:

Get-Mailbox -identity "<identity value>" | Get-ADPermission | Sort user | FT –AutoSize

The “<identity value>” specifies the mailbox that you want to view. You can use any value that uniquely identifies the mailbox. Values of example are:

• Name
• Display name
• Alias
• Distinguished name (DN)
• Canonical DN
• <domain name>\<account name>
• Email address
• GUID
• LegacyExchangeDN
• SamAccountName
• User ID or user principal name (UPN)

–

The command executes and you are confronted with the following, or similar, error:

WARNING: The object IAMTEC.NET/Org-Users/EMPLOYEES/Users/ICT/Jorge.deAlmeidaPint has been corrupted, and it’s in an inconsistent state. The following validation errors happened:

WARNING: The access control entry defines the ObjectType ’18d30bdd-e673-6047-b13c-cffee0abb929′ that can’t be resolved..

Figure 1: The PowerShell CMDlet “Get-ADPermission” Throws Error About Corrupted ACE

–

After seeing this error you may think about incorrect ordering of ACEs, as explained in the blog post (2014-08-04) Incorrectly Ordered Permissions After Removing ACE With LDP, or might even think your AD schema is in a bad shape.

This time, that is not the case.

–

Let’s investigate this step by step and see where the so called corruption came from!

–

When an ACE is defined, the specified security principal (user, group or computer) is assigned the specified permissions for an objectClass or for an attributeClass within a objectClass. In either case the specified objectClass or attributeClass is always translated under the hood to its corresponding schemaIDGUID. Every objectClass and attributeClass in the AD schema must have and has a unique schemaIDGUID value. When extending the AD schema it is not mandatory to specify a schemaIDGUID value in base64 format. If you do not specify a schemaIDGUID value, AD will generate a unique value for you. However, that is NOT a best practice. When extending the AD schema you should always specify a unique schemaIDGUID value. If you intend to deploy your schema extension to multiple AD forests, then the schemaIDGUID for the extended objectClass or attributeClass across all AD forest is preferably the same schemaIDGUID value.

–

The error mentions “ObjectType ’18d30bdd-e673-6047-b13c-cffee0abb929’”. The specified GUID value is NOT the objectGUID, it is the schemaIDGUID value of the objectClass or attributeClass that is causing the error. So, let’s search using the specified schemaIDGUID value.

For I’m going to use PowerShell through the following command to find the objectClass or attributeClass:

$rawGuid = ([guid]’18d30bdd-e673-6047-b13c-cffee0abb929′).toByteArray();

Get-ADObject -Filter {schemaIDGUID -eq $rawGuid} -SearchBase (Get-ADRootDSE).schemaNamingContext -Properties * | FL

The query result is:

Figure 2: Result Of The PowerShell Query In Searching For An objectClass Or attributeClass Through The schemaIDGUID

–

The name of the attributeClass already tells you how special it is, but that’s because I named it like that. In reality you will not see that. The real answer is hidden in the searchFlags property. If you look above you will 904, and that does not tell you much, unless you decode it yourself, or use ADFIND from joeware.net. (@joe: stop laughing!)

Now let’s use ADFIND through the following command to find the objectClass or attributeClass:

adfind -schema -f "schemaIDGUID={{GUID:18d30bdd-e673-6047-b13c-cffee0abb929}}" -binenc –flagdc

The query result is

Figure 3: Result Of The ADFIND Query In Searching For An objectClass Or attributeClass Through The schemaIDGUID

–

Of course ADFIND will return the same attributeClass, but at the same time it decoded searchFlags and systemFlags. When looking at the searchFlags property you will see the attribute has been configured with the confidentiality bit. Now, what’s special about that? You may remember it or not, but to be able to read the data in a confidential attribute, you must be either a member of “Domain Admins” or a member of “Account Operators” or a member of any other group that has Full Control on the corresponding object, or you must have at least the “Control Access” extended right.

–

Now the ONLY tools, I know of, that can both read (interpreter) and set the “Control Access” extended right, are DSACLS, LDP and ADFIND/ADMOD. Any other tools, may not process/interpreter it correctly. Those tools then either do not display the “Control Access” extended right or throw some weird error, like the PowerShell CMDet “Get-ADPermission”.

–

Now you might think “Yeah right. Your attribute is a custom AD schema extension and its has been implemented/designed in a bad way!”. Again, that’s not the case. This AD schema extension or any other AD schema I have ever designed has followed best practices! By default, the AD schema also contains attributeClasses that have been configured with the confidentiality bit. To find those attributeClasses, read the (2014-12-19) Finding Attributes Marked As Confidential. Now choose an attribute you like, and configure it with the “Control Access” extended right (do this in a TEST environment).

To configure the “Control Access” extended right for the confidential attribute on an OU that targets user objects, execute the following command:

DSACLS "<DN of OU>" /G "<Security Pincipal>:CA;<Confidential Attribute>;user" /I:S

Now, execute the Get-ADPermission CMDlet as specified at the beginning of this blog post. You should see a similar error about a corrupted ACE.

–

Therefore the conclusion is, that this is caused by the GET-ADPermission CMDlet (bug!) that misinterpreters the “Control Access” extended right. I know this occurs in Exchange Server 2010 and Exchange Server 2013, and most likely also in Exchange Server 2016. The Exchange Product Team, most likely, will never fix this as it is very low priority and there is no real issue here. If you really want to change the behavior of the GET-ADPermission CMDlet, then you need to submit a Design Change Request (DCR) will and impact analysis, including any monetary harm or loss you have due to this behavior. Good luck in trying to do that! You are better off ignoring this and paying real attention to some other stuff that’s more important!

–

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Advertisement