Property set Personal Information and Active Directory security and governance

Active Directory (AD) is an essential tool for organizations to manage user access and authorization to various resources.

When it comes to Active Directory, there are many features that are well-known and well-documented.

Do you know that by default any user can modify some specific Active Directory attributes they belong? This feature is not well-known and has little documentation available online, leaving your organization vulnerable to security risks.

In this article, we will explore the details of this feature and provide you with mitigation strategies to keep your organization safe.

Active Directory allows modifications by the users

Let's start with the problem:

By default, users can edit specific AD attributes of their account.

Microsoft probably considers the user as the "owner" of specific information, especially details related to mobility like office number, address, and phone number.

I might be mistaken, but when I first looked into this topic a few years ago, I found very little information on the Internet.

Property Set and Personal-Information

The problem

By default, any Active Directory has some Property set (full list here : https://learn.microsoft.com/en-us/windows/win32/adschema/property-sets).

AD Property Set are groupings of object attributes (properties). Any AD attribute can belong to zero or one Property Set. The belonging is set by attributeSecurityGUID which matches the attribute rightsGUID of the property set.

The "problem" is for Personal-Information; it allows SELF to change attributes.

It means any authenticated user can modify these attributes.

Oh, and if you think you're secure because "your users have not administrator rights on the workstation so they can't install tool to modify AD attribute". you're wrong. There is a LOT of tools on the Internet to modify AD attribute (Apache Directory Studio, ADExplorer, PowerShell, LDAP query, etc.).

There's also a convenient built-in tool available in every version of Windows:

C:\windows\system32\rundll32.exe dsquery,OpenQueryWindow

There are a lot of custom scripts nowadays using these kind of attributes. Even a official documentation of Microsoft on Microsoft Cycle Work (hireDate, etc.) use these attributes!

Identity and governance issues:

There are scenarios where this can be problematic. Here's a quick rundown:

• If you rely on scripts that use these attributes,
• The same goes for if you have an identity management application.
• If you're into identity federation and use these attributes to assign rights, you'll face issues as well.
• If you use Active Directory synchronization from AD to EntraID (Azure AD) Microsoft 365
• If you follow Microsoft documentation for Microsoft Cycle Work because their documentation use a modifiable attribute for hireDate.

List of attributes in Personal-Information

Note : If you want to find the attribute in any Property Set, you can check my other blog post.

Find below a table (best with Desktop view) with all attributes within the Personal-Information property set. If your AD schema has been extended with the Exchange schema, please also check the Exchange attributes.

There is a lot of common attribute in there : streetAddress, l (location/city), c (country), st, msDS-cloudExtensionAttributeX, etc.

To sum up, a user can modify more than 70 attributes in their own AD user account.

This is due to the ACE Write Personal Information on Authority SELF:

Note : Write ACE exists for Phone and Mail Options (Property Set name is Email-Information, it's empty by default) and Web Information (attributes : wWWWHomePage and url) so I won't dig into these two Property Sets.

Problem with Exchange Online / Exchange on-premise

Let's take the following common scenario:

• The Personal-Information Property Set is set by default
• You synchronize your AD to Microsoft Entra ID (Azure AD)
• You have some dynamic distribution groups based on Personal-Information attributes

Get info with regular user about dynamic distribution group and add yourself as member

By default, any user with Exchange Online license can access Exchange Online with PowerShell.

To connect to ExchangeOnline, user needs ExchangeOnlineManagement.

Connect-ExchangeOnline

User has read acces by default but Get-DynamicDistributionGroup is not available with user rights so we can't get the attribute(s) used in the filter.
But, we can get member from a Dynamic Distribution Group with

Get-DynamicDistributionGroupMember -Identity xxx

After getting the members, you can dig into these users' attributes and try to find the attributes in common for this user. If attributes used is in Personal-Information Set, the user can modify it and be part of this group.

Mitigation for Exchange Online/Exchange on-premise

Deny Exchange Online PowerShell access to prevent user to be able to check dynamic distribution group.
CAREFUL TO NOT DENY ACCESS FOR ADMINS !

However, as you can see, this isn't a complete solution because the issue persists. The optimal approach is to prevent the modification of these attributes directly at the AD level (refer to the final section of this blog).

Problem with Microsoft Entra ID (Azure AD)

Let's take the similarly scenario:

• The Personal-Information Property Set is set by default
• You synchronize your AD to Microsoft Entra ID (Azure AD)
• You have some dynamic Microsoft Entra ID AD groups attributes-based

Get info with regular user about Microsoft Entra IDdynamic groups

The users can either uses Microsoft Entra ID admin portal (if not blocked) or other tools.
For this example, I use Azure Hound (none rights needed).

.\azurehound.exe list -u "[email protected]" -p "xxx" -t "domain.onmicrosoft.com" -o mytenant.json

The results is a json file.
Instead of Bloodhound's cyphers, you can use jq (https://jqlang.github.io/jq/download/) to parse json.

jq '.data[] | select(.kind == "AZGroup" and .data.membershipRule != null)' mytenant.json

If you want only name and membership Rule:

jq '.data[] | select(.kind == "AZGroup" and .data.membershipRule != null) | .data.displayName, .data.membershipRule' mytenant.json

Note: for Windows, use CMD and escape quotes:

jq ".data[] | select(.kind == \"AZGroup\" and .data.membershipRule != null)" mytenant.json

jq ".data[] | select(.kind == \"AZGroup\" and .data.membershipRule != null) | .data.displayName, .data.membershipRule" mytenant.json

Mitigation for Microsoft Entra ID

Restrict access to Microsoft Entra admin portal won't help (as Microsoft said in this doc) because Azure Hound does not use GUI. So it's hard to mitigate this problem only from a Microsoft Entra ID point of view.

Same as before, the optimal approach is to prevent the modification of these attributes directly at the AD level (refer to the final section of this blog).

Remove attributes from a Property Set

There are workarounds involving ACE modifications, deny ACE, and so on. In my opinion, the best approach is to address the root of the problem: the Property Set.

One solution is to remove the AD attribute from the Personal-Information Property Set. By doing this, the issue is resolved.

It's important to note that some AD attributes in Personal-Information should legitimately be modified by users. Therefore, it's your decision to remove only the attributes you deem necessary.

You can use my script containing Remove-ADAttributeFromPropertySet. The script simply deletes the attribute attributeSecurityGUID on the attributeSchema object.

ActiveDirectory-Toolbox/Attributes/PropertySet at master · itpro-tips/ActiveDirectory-Toolbox

Contribute to itpro-tips/ActiveDirectory-Toolbox development by creating an account on GitHub.

GitHubitpro-tips

For example, if you want to remove msDS-cloudExtensionAttribute1 :

Remove-ADAttributeFromPropertySet -ADProperties msDS-cloudExtensionAttribute1

You can also specify multiple attributes:

Remove-ADAttributeFromPropertySet -ADProperties msDS-cloudExtensionAttribute1,msDS-cloudExtensionAttribute2,msDS-cloudExtensionAttribute3