Today is data privacy day. Today, I’d like to talk about Active Directory and data privacy, because it is an issue that is looming on the horizon for many organizations.

I won’t be talking about Domain Controllers getting popped all around the globe, not about the various attacks against Active Directory and how to detect, protect and response to these. There’s more knowledgeable people around to do that.

Instead, I want to discuss the fundamental differences in terms of privacy between Active Directory Domain Services (AD DS) on one side and Active Directory Federation Services (AD FS) and Azure AD on the other side.

Active Directory Domain Services

Active Directory has been around for quite some time. Next month, on February 17th 2020, It’ll celebrate its official 20th birthday as we commemorate the release of Windows 2000 Server. Before the release, Active Directory was developed and tested within Microsoft, using the state of the art protocols available then, like LDAP and Kerberos.

Kerberos and LDAP are great protocols, but…

Kerberos has its specifics and flaws. Microsoft has added function to address some of these shortcomings, only to introduce the situation where Microsoft’s Kerberos implementation is no longer compatible. LDAP, originally designed as a lightweight protocol is now one of the heavy weights in its category as admins, users, systems, services and applications alike use it to query the contents of Active Directory.

When using LDAP, an Active Directory-integrated application, service and system can see all information on every object, except (by default) for passwords. This includes the Active Directory topology, (stale) computer objects, and, yes; user objects.

User objects may contain personal data

When a system, service or application is able to query user objects, it may be (ab)used to query sensitive information, too. By default, Active Directory provides information on:

• Name
• E-mail address(es).

By default, however, Active Directory doesn’t include fields for gender, race or favorite drink. Many organizations I’ve come across, however, have extended the user class in the Active Directory schema to include such attributes.

All this information is readily available to any Active Directory-integrated system, service or application and to every user that is capable of copying and running ldp.exe. Even over Active Directory trusts. It is a data leak waiting to happen.

Recommended practices for Active Directory for data privacy

For the privacy of your colleagues, please consider:

• Implementing the Active Directory Administrative Tiering model and PAWs. Block and/or filter access to Domain Controllers for systems, services and applications that do not have to interact with Active Directory directly.
• Removing information from Active Directory, that is not strictly needed for the purpose of authentication, authorization and auditing access to Active Directory-integrated resources.
• When using an identity synchronization solution, like ForeFront Identity Manager (FIM) and Microsoft Identity Manager (MIM), making sure that the source anchor is not something conveniently immutable like a social security number (SSN).

Active Directory Federation Services

In sharp contrast to Active Directory Domain Services, Active Directory Federation Services (AD FS) and the open protocols it offers (including WS-Federation, SAML, OAuth2, Open ID Connect and SCIM) were designed for the Internet. The information exchanged consists of claim tokens.

Data privacy by default

In a Relying Party Trust (RPT), the relationship between multiple AD FS implementations and/or other endpoints for the aforementioned protocols only consists of mechanical values, by default; A timestamp, an instance GUID, information on the certificate used to sign the information in it. Only when an admin adds claim types to claim tokens, is there the possibility to add personal data to the data exchange. Luckily, claim tokens can optionally be encrypted. Luckily, claims are exchanged using https, by default.

Recommended practices for AD FS for data privacy

For the privacy of your colleagues, please consider:

• Disabling and ultimately removing relying party trusts for applications, services and systems that are no longer in use.
• Reviewing the claims issuance rules in Active Directory Federation Services (AD FS) for the applications, services and systems in use, regularly.
• Consulting with your organization’s workers council to get pre-approval on personal data that is exchanged with applications, services and systems outside of your organization. Within the GDPR you may claim that the applications are needed for people to perform their jobs, and thus the information needs to be transmitted. However, an organization where people engage each other without reservations and in each others’ best interest is a nicer environment to work in.
• Consulting with your organization’s CISO and data privacy officer regularly on the claim types and the information therein towards applications, services and systems. This way, they can get a head start at classifying applications, services and systems in regards to the personal data they have access to.
• Taking care of proper encryption of traffic by changing the AD FS token-signing hash algorithm for all capable AD FS relying party trusts to SHA256 and disabling weak protocols, cipher suites and hashing algorithms on Web Application Proxies and AD FS Servers.

Azure Active Directory

Azure Active Directory (Azure AD) is Microsoft’s cloud-based identity platform. In many organizations, their Azure Active Directory tenant is connected to the on-premises Active Directory Domain Services environment using Azure AD Connect. 3rd-Party identity solutions, like Okta and One Identity can also be encountered.

Filtering objects and attributes

All of these solutions allow filtering on the objects and attributes that are synchronized to Azure AD from the on-premises Active Directory environment. This way, when an object or attribute is not strictly needed for Azure AD-integrated applications, services and systems, it can be omitted from the synchronization scope.

Recommended practices for Azure AD for data privacy

For the privacy of your colleagues, please consider:

• Limiting the objects of your colleagues that are synchronized from Active Directory to Azure AD through Domain and OU Filtering in Azure AD Connect.
• Limiting the personal data of your colleagues that is synchronized from Active Directory to Azure AD through Azure AD App Filtering in Azure AD Connect.
• Enabling Azure AD’s Security Defaults feature, or creating the same Conditional Access policies with exceptions. Requires Azure AD Premium P1
• Taking care of proper encryption of traffic by enforcing Azure AD Connect to use TLS 1.2 only and disabling weak protocols, cipher suites and hashing algorithms on Windows Servers running Azure AD Connect.

Concluding

Have a nice data privacy day!