Active Directory: LDIF, An Extraction to Rule Them All

Extracting data from a Microsoft Active Directory (Microsoft’s LDAP directory for Windows), enables a multitude of controls that are easily automated, and helps establish a primary defense for access governance across your Windows systems.

The objective of this article is to introduce you to the “LDAP Data Interchange Format” (LDIF) extraction from an AD  and the series of available controls based on ANSSI recommendations.

1 – LDIF Extraction: Which Format for Which Data?

LDIF is a standardized format designed to facilitate the exchange of data from an LDAP directory. It not only represents directory data but also enables actions on a directory (adding, modifying, deleting data). The LDIF extraction is a text file (with the extension .ldif or .ldf) and can be read or edited using a simple text editor.

2 – How to Obtain LDIF Extraction from an Active Directory

Microsoft has provided a dedicated AD extraction tool. Its full name is “Lightweight Directory Access Protocol Data Interchange Format Directory Exchange,” and commonly known as LDIFDE. It’s a command-line tool used for importing or exporting LDIF files. This tool is available on Windows servers when the “Active Directory Domain Services” (AD DS) or “Active Directory Lightweight Directory Services” (AD LDS) server roles are installed on the machine.

3 – What to Do with My Extraction?

Now that we have a proper LDIF extraction of our AD, we should focus on the Controls! WALLIX offers you 23 unique controls which may be performed on your extraction to identify anomalies in your identity and access governance, and to avoid vulnerabilities in your IT system.

Control 1: A Significant Number of Privileged Group Members

Privileged Groups are administrative and operational groups that have ALL rights and privileges on the domain, or are able to assign them. The following groups are included:

• Account Operators
• Administrators
• Backup Operators
• Domain Admins
• Enterprise Admins
• Print Operators
• Schema Admins
• Server Operators

Assigning these Groups should be avoided, or only done if all permissions are genuinely necessary. It’s generally preferable to use Custom Groups and apply the principle of ”Least Privilege” access.

Control 2: Inconsistent Domain Controllers

A domain controller is a server that authenticates a user to the domain and validates their network access. It’s important that its User Account Control (UAC) attributes are correctly set. Therefore, it’s necessary to check if the domain controller has the attributes SERVER_TRUST_ACCOUNT and TRUSTED_FOR_DELEGATION and no others. Additional attributes can apply to “Read Only Domain Controllers” (RODC).

Control 3: Privileged Accounts without Kerberos Pre-Authentication

Kerberos is an authentication protocol that enables strong authentication using secret keys. Privileged accounts (accounts with all or the potential to have all rights on the domain) should not have the “DONT_REQUIRE_PREAUTH” attribute.

Control 4: Privileged Accounts with SPN

The ServicePrincipalName (SPN) attribute is set by default on machine accounts. This attribute should NEVER be set on a privileged account because a “brute force” attack could retrieve the password of the privileged account through the ticket issued by Kerberos.

Control 5: Privileged Accounts with Passwords that Never Expire

The countless risks associated with this anomaly don’t need listing. The “DONT_EXPIRE” attribute should never be set on a privileged account. Compromising the entire domain could be made easy (e.g., by a former employee).

Control 6: Privileged Accounts with Unchanged Passwords for a Certain Period

To mitigate the risks associated with password theft, it’s crucial to have frequent password rotations. This applies to all users but is even more critical for privileged accounts.

Control 7: Domain Controllers with Unchanged Computer Account Passwords for Over 45 Days

By default, password rotation occurs every 30 days. If this cannot be achieved, it’s important to promptly investigate the cause.

Control 8: Inactive Domain Controllers

A domain controller typically connects every 30 days to change its password. Absence of authentication can result from desynchronization. In such cases, the domain controller needs to be reinstalled or removed.

Control 9: Accounts with a primaryGroupId Less Than 1,000

This attribute associates a user with a group implicitly. Some interfaces do not display this relationship in the list of group members. Therefore, it’s important to leave the default value: 513 for a user, 514 for a guest, and 515 for a computer.

Control 10: Accounts Members of the DnsAdmins Group

It’s recommended NOT to use the DnsAdmins group. This group allows code execution through the DNS service, typically hosted on the domain controller.

Control 11: High Number of Unused Active Accounts

A dormant account is one that hasn’t logged into the domain for a certain period. It could be an account rarely used (or whose owner is on leave) or an obsolete account (associated with a former employee). Efficient categorization of dormant accounts is important to disable obsolete accounts, reducing both the attack surface and the workload during rights reviews.

Control 12: Unconstrained Delegation of Authentication

The “TRUSTED_FOR_DELGATION” property should only be present in domain controllers. If another account has this attribute, it could authenticate to a Kerberos service with the identity of another account that has authenticated to the first account.

Control 13: Accounts Without Kerberos Pre-Authentication

The “DONT_REQUIRE_PREAUTH” attribute should NOTbe present in an account.

Control 14: User Accounts with Weak Kerberos Encryption

Kerberos can use the DES encryption algorithm to issue tickets. However, this algorithm is considered obsolete, so the “USE_DES_KEY_ONLY” attribute should be removed from accounts in the AD.

Control 15: Accounts with Passwords that Never Expire

A second control on password expiration, but this time the criterion applies to all users in the AD, not just privileged accounts.

Control 16: Incorrect Version of Active Directory

In certain versions of Active Directory, the Key Admins and Enterprise Key Admins groups have overly permissive Access Control Entries (ACE). The Windows Server 1709 versions fix this issue, so it’s important to update. Check the “ActiveDirectoryUpdate” value in the LDIF file. If the version is 15, it’s recommended to perform the update.

Control 17: The “Pre-Windows 2000 Compatible Access” Group Contains “Anonymous”

This group should only contain “Authenticated Users” (S-1-5-11) and not “Anonymous” (S-1-5-7). Otherwise, anonymous enumeration of certain elements is possible from the domain controller.

Control 18: krbtgt Account Password Unchanged for Over a Year

Compromising the “krbtgt” account would allow an attacker to forge Kerberos tickets and authenticate with Administrative rights across the entire domain.

Control 19: Account with Modified primaryGroupID

Earlier, we recommended prohibiting primaryGroupIDs less than 1,000 (excluding the default value). Now we advise against modifying this property, which implies implicit group membership. Explicit declaration via the “MemberOf” property is preferred.

Control 20: Accounts or Groups Members of “Pre-Windows 2000 Compatible Access”

Same explanations as Control 17, but this time, we broaden the control scope to prevent Anonymous from being a member of this group through an intermediary.

Control 21: Privileged Accounts Not Members of the “Protected Users” Group

The “Protected Users” group establishes barriers for member users:

• Forcing Kerberos authentication
• Reducing the lifetime of Kerberos tickets
• Enforcing strong encryption algorithm usage (e.g., AES)
• Disabling password caching on workstations
• Prohibiting any form of delegation

Control 22: Accounts with Reversible Password Storage

If the “ENCRYPTED_TEXT_PASSWORD_ALLOWED” attribute is set on an account, the password for that account can be retrieved in plain text.

Control 23: Accounts or Groups with SID History

The sIDHistory attribute must be empty for all users and groups in the domain. If it’s populated, it generates logs that clutter event logs and can be exploited by an attacker to gain unauthorized rights to resources.

Conclusion

We’ve listed a few important controls that can be easily reviewed to get an overview of your Active Directory’s compliance with ANSSI best practices. These controls may be automated using PowerShell scripts. Once the controls are in place, anomalies need to be reported on a timely basis so they can be swiftly remediated. WALLIX offers a “One Shot” approach to conduct a review for a quick overview of initial actions, or to integrate these controls into a broader identity and access governance policy which covers the entire IT system. This can all be viewed from a web interface for precise and clear reports.