Active Directory : LDIF, one extraction to rule them all

The extraction of an Active Directory, LDAP directory by Microsoft for Windows OS, allows you to perform many controls. It is simple to implement, automatable and thus allows you to create the first bulwark in your access governance on your Windows systems.

The objective of this article is to present you the LDIF extraction of an AD, how it is obtained and a list of controls based on ANSSI recommendations.

1 – LDIF extraction, which format for which data?

LDIF (« LDAP Data Interchange Format ») is a standardized format to exchange data from an LDAP directory to another system. It represents the data of a directory but it also allows actions to be performed on a directory (addition, modification, deletion of a data). The LDIF extraction is a text file (with the extension ldif or ldf) and can therefore be read or modified using a simple text editor.

Inside, the data is formatted as an object or record, each record is separated by an empty line. The end of the file is marked by two empty lines. Records are composed of one or more attributes represented by a “name : value” pair.

dn: cn=The Postmaster,dc=example,dc=com
objectClass: organizationalRole
cn: The Postmaster

2 – How to get the LDIF extraction from an Active Directory

Microsoft has published a dedicated extraction tool. Its full name is “Lightweight Directory Access Protocol Data Interchange Format Directory Exchange”, but more commonly known as LDIFDE, it is a command line tool that allows you to import or export LDIF files. This tool is available on Windows servers when the AD DS or AD LDS (Active Directory Lightweight Directory Services) server role is set on the machine.

3 – What to do with my extraction?

Now that we have a proper LDIF extraction of our AD, it’s time to move on to the part that interests us here: the controls!

We propose 23 controls to be performed on your extraction to identify anomalies in your identity and access governance and to avoid the risks of vulnerabilities in your IS.

Control 1 : Large privileged group member count

Privileged groups are the administrative and operational groups that have all the rights and privileges on the domain or can assign them to themselves. We have the following groups:

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

The assignment of these groups should be avoided, or only if the full set of permissions is really needed. The use of custom groups applying the least privilege policy should be preferred.

Control 2 : Domain controllers in inconsistent state

A Domain Controller is a server that allows a user to authenticate on the domain and validate their access to the network. It is therefore important that its UAC attributes (User Account Control) are correctly set. It is therefore necessary to verify that the domain controller has the attributes SERVER_TRUST_ACCOUNT and TRUSTED_FOR_DELEGATION and no other. Additional attributes can be applied to the “Read Only Domain Controller” (RODC)

Control 3 : Kerberos pre-authentication disabled for privileged accounts

Kerberos is an authentication protocol that allows the use of strong authentication through secret keys. Privileged accounts (accounts that have or can have all rights on the domain) must not have the “DONT_REQUIRE_PREAUTH” attribute.

Control 4 : Privileged accounts with SPN

The servicePrincipalName attribute is set by default on machine accounts. This attribute must never be set on a privileged account because a “brute force” attack could find the password of the privileged account through the ticket issued by Kerberos.

Control 5 : Privileged accounts with never-expiring passwords

There is no need to list the countless risks associated with this anomaly. The “DONT_EXPIRE” attribute should never be set on a privileged account. The whole domain could easily be compromised (by a former employee for example).

Control 6 : Privileged accounts passwords age too old

In order to limit the risks of password theft, it is important to have a frequent rotation. This is true for all users but even more important for privileged accounts.

Control 7 : Domain controllers with password unchanged for more than 45 days

By default, the rotation is done every 30 days. If this has not been done, it is important to investigate the cause as soon as possible.

Control 8 : Inactive Domain Controllers

By default, a domain controller logs in every 30 days to change its password. The lack of authentication may be caused by an out-of-sync condition. In this case, the Domain Controller must be reinstalled or deleted.

Control 9 : Accounts with primarygroupid lower than 1000

This attribute allows to associate a user to a group in an implicit way. Some interfaces do not display this relationship in the list of group members. It is therefore important to leave this default value 513 for a user, 514 for a guest, 515 for a computer.

Control 10 : Dnsadmins group members

It is recommended not to use the DnsAdmins group. This group allows code to be executed by the DNS service which is usually hosted on the domain controller.

Control 11 : Dormant accounts

A dormant account is an account that has not logged on to the domain for some time. This can be an account that is rarely used (or its owner has gone on vacation) or an account that is obsolete (an account attached to an employee who has left the organization). It is important to be able to effectively categorize dormant accounts in order to deactivate obsolete accounts. This action reduces the attack surface but also reduces the workload during a rights review.

Control 12 : Unconstrained authentication delegation

The “TRUSTED_FOR_DELEGATION” property should only be carried by Domain Controllers. If another account has this attribute, then that account will be able to authenticate to a Kerberos service using the identity of another account that has already authenticated to the first account.

Control 13 : Kerberos pre-authentication disabled

The attribute “DONT_REQUIRE_PREAUTH” must not be carried by an account.

Control 14 : Use of Kerberos with weak encryption

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

Control 15 : Accounts with never-expiring passwords

Second control on password expiration, but this time the criterion is not limited to privileged accounts but to all users of the AD.

Control 16 : bad Active Directory versions

In some versions of Active Directory, the Key Admins and Enterprise Key Admins groups have too permissive Access Control Entries (ACE). Windows Server 1709 versions fix this problem, so it is important to update. Just check the “ActiveDirectoryUpdate” value in the LDIF file. If the version is equal to 15, it is recommended to update.

Control 17 : The “Pre-Windows 2000 Compatible Access” group includes “Anonymous”

This group should contain only “Authenticated Users” (S-1-5-11) and not “Anonymous” (S-1-5-7). Otherwise, an anonymous enumeration of certain items is possible with the Domain Controller.

Control 18 : krbtgt account password unchanged for more than a year

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

Control 19 : Accounts with modified primarygroupid

Earlier we advised to forbid primaryGroupId lower than 1 000 (out of default value). We now advise to forbid the modification of this property which allows the membership to a group in an implicit way. It is better to declare it explicitly through the “MemberOf” property.

Control 20 : Use of the “Pre-Windows 2000 Compatible Access” group

Same explanations as for Control 17, but this time the scope of Control is extended to avoid that Anonymous can still be a member of this group through an intermediary.

Control 21 : Privileged accounts outside of the protected users group

The “Protected Users” group allows you to set up certain barriers to user members:

• Force Kerberos authentication
• Reduce the lifetime of Kerberos tickets
• Force the use of strong encryption algorithms (e.g. AES)
• Prohibit password caching on workstations
• Prohibit any form of delegation

Control 22 : Accounts with passwords stored using reversible encryption

If the attribute “ENCRYPTED_TEXT_PASSWORD_ALLOWED” is set on an account then the password of this account can be recovered in clear text.

Control 23 : Accounts or groups with SID History set

The sIDHistory attribute must be empty for all the users and groups of the domain. If it is filled, it generates lines that pollute the log files and it can be used by an attacker to give himself illegitimate rights on resources.

Conclusion

We have just listed a few controls that can be easily executed for an overview of the compliance of your Active Directory with the ANSSI best practices. Moreover, these Controls are easily automated through a PowerShell script.

Once the controls are set up, it is necessary to be able to report anomalies in a clear way so that they can be managed quickly.

Kleverware offers to conduct these controls in a “One Shot” manner to have a quick overview of the first actions to be taken or to integrate these controls into a much broader identity and access governance policy that covers the entire Information System, all of which can be consulted from a web interface for clear and precise reports.