Hiding Data in Active Directory

I have a bit of a reputation as an expert on hiding data in Active Directory. So I often get questions about how to hide X, where X changes a bit depending on the scenario. Lately I’ve gotten a flurry of such questions, and it’s become obvious to me that I should blog about this.

The key to all of these questions is understanding a few key Active Directory concepts. After you understand these few things, you can quickly find a solution for whatever your X is.

Outside of understanding how to achieve your goal, you also need to understand the implications or consequences. Sometimes those consequences are enough that you may decide not to implement.

This post is divided into 3 sections:

  1. Explaining background concepts needed to craft a solution
  2. Describing potential consequences
  3. Describing some real-world examples & the specific solutions

Background AD Security concepts

There are three methods or approaches to hiding things in AD.

Let’s agree to throw out one out of consideration straight out of the gate. AD supports marking an attribute as confidential (see http://support.microsoft.com/kb/922836). But it doesn’t only allows this to happen on attributes which are part of the base schema. So this solution is only valid for custom attributes you’ve added, and in my experience, no one really cares about hiding their custom attributes—it’s the base ones they are interested in.

The other two involve getting a lot more familiar with AD security descriptors. As background, you have to must know where every AD object gets the ACEs it has. There are three sources:

a) inherited ACEs from objects “above” it
b) explicit ACEs that have been added to that object
c) explicit ACEs that are set upon object creation from the default security descriptor defined by the object’s schema

You are in control of all three of these sources.

To my knowledge, Stanford is the only AD implementation which has changed c). Incidentally, if you have an AD implementation that has done this I’d love to hear about it. Stanford removed the default security descriptor from the user objectclass. They’ve set some inherited ACEs, and their provisioning then adds any explicit ACEs that they desire. With the exception of domain admin accounts, they don’t hide users.

I’d encourage you to take a close look at the default security descriptor on the user objectclass. You’ll see that a group called “Pre-Windows 2000 Compatible Access” is granted Read access. This ACE and the membership of this group is therefore critical to whether or not someone can see a given user. You’ll find this is also true for computers and groups.

Another point of background. You need to understand the order of permission processing for AD. This is:

  1. Explicit Deny ‘Owner Rights’
  2. Implicit Allow Owner (change permissions + change ownership)
  3. Explicit Deny
  4. Explicit Allow
  5. Inherited Deny
  6. Inherited Allow

Note that an explicit allow overrides an inherited deny. This means that if you want to either hide an AD object or hide attributes on an AD object, you must get into the business of managing explicit ACEs–there is no easy solution of setting a single inherited ACE that will achieve your aim.

Once you understand this background, the rest is usually just implementation details. Most solutions involve:

a) either remove the troublesome explicit allow ACEs or empty the membership of the groups referenced
b) add an inherited deny ACE

Working within this framework is the usual approach most AD implementations take when they need to hide information in AD,and it’s what I’ll focus on in the other sections. I should probably also mention that back in 2005/2006 timeframe I opened a very lengthy PSS engagement to validate that there were no APIs that didn’t respect the AD ACLs.

But there is one other approach (the third I mentioned earlier). That’s to turn on the “List Object” permission in AD (see http://technet.microsoft.com/en-us/library/cc546864.aspx on how to do this). I am not as familiar with how you’d use this approach, and whether it reduces the consequences. The “List Object” permission is not on by default, and information from Microsoft indicates this is because they thought there might be performance impacts to using it at larger scales (see http://msdn.microsoft.com/en-us/library/windows/desktop/ms675746(v=vs.85).aspx for that warning). More can said about List Object mode and using this approach, but in general I don’t know about many ADs that have used it, and have no direct experience to share. If you do have experience to share, let me know and I’ll share it here. 🙂

Potential Consequences

If you start to make changes to your AD ACLs, there are some consequences which you may not have anticipated.

For example, if you hide an object such as I mentioned Stanford does with its domain admin accounts, except for the AD itself, nothing can find that object. This means that others can *not* grant that account permissions to almost anything–about the only exceptions are granting access to AD objects or membership in AD based groups. This is because as soon as the object is hidden, the “behind the scenes” username -> objectSID operation that is required for almost all Windows access control changes fails.

The University of Washington (and many other universities) hide the member attribute on some groups, and the memberOf attribute on all users. You can see what we specifically did to achieve this documented at: https://itconnect.uw.edu/wares/msinf/design/arch/group-member-privacy/. I should probably mention that we have a C# code sample (and PowerShell–which is using the same stuff) of what’s there. There are a bunch of consequences that we have to live with, and find workarounds for.

The key issue for any scenario where you hide something in AD is that applications that integrate with AD may expect that they have read access to whatever you’ve hidden.

In our case, since we’ve hidden memberOf across all users and member on some groups, we sometimes run into applications that have problems doing access control. But there are obviously options you can implement to address it. For example for our scenario, assuming you do due diligence in evaluating whether that application “leaks” PII or only uses that group membership information for access decisions, you can grant the user account running that application the permissions to read the AD groups with private membership (and/or the user objects memberOf and tokenGroupsGlobalAndUniversal attributes).

But you’ll need a process to evaluate and approve granting that access. And the process will need to somehow take into account {getting permission/letting know} the owners of the membership private groups that application X can read their info.

More recently, we’ve been struggling with the tokenGroupsGlobalAndUniversal attribute (and its partner the Windows Authorization Access Group) since Microsoft seems to be leveraging it with greater frequency in its products, but not doing a very good job documenting this dependency in product documentation. Exchange 2007+, Sharepoint 2007+ (Search security trimming), SCOM (reporting services), and maybe SCVMM all make some use of this mechanism. In some cases, for certain user attributes, you can just add an ACE granting access to whatever the special application or need is. For example, for Likewise (a unix/mac AD integration solution) we opened up the userAccountControl attribute to all computer objects. Nothing really earth shattering about that, but you do have to be willing to do a little extra work to find out what these applications need. And that may introduce unexpected friction between your AD team and project teams. And it often doesn’t help to be proactive–many times I’ve been in the situation where I was explaining to highly-paid consultants that when I previously asked them if this new application they were deploying needed read access, I was referring to the critical problem their application was now experiencing. This gets back to lack of deep understanding of how a given application makes authorization decisions.

Unfortunately, when you do want to authorize an application, there aren’t many good fine-grain solutions within AD for making that happen. For example, we end up granting an application account permissions to read all user accounts, even if that application only has a user population that is a small fraction of all of our users. We hope that Microsoft will eventually extend its Dynamic Access control capabilities to Active Directory resources to help solve this problem of granularity of access control, but that hasn’t happened yet.

In terms of hiding entire objects, I generally try to discourage others from doing it. There are alternatives. For example, while I was at Stanford, Chelsea Clinton was a student. She had a user account, but the name associated with it was not her actual name. So obfuscation. We do something similar here at the UW. A key thing to keep in mind is that you generally aren’t obligated to hide an entire object—it’s generally the case that what is considered sensitive data is a combination of attribute values in conjunction with each other. For example, in our case it’s the ability to tie a course name with a person. If there is no public way to determine that a given person has a given user account, then we wouldn’t need to hide the course group membership at all.

Real World Examples

I’ve already mentioned the UW solution. But I didn’t really explain much of the business reason behind it. So let me backtrack a bit. The US government has this law called FERPA. It allows students to control who has access to their student records. Whether a given student is taking a course or not is considered part of their student record. So group membership in a group that represent a specific course are FERPA protected information. We are obligated to limit access to business functions. Beyond this, we believe that other group memberships are confidential in nature. The nice thing about hiding the membership of groups is that they can still be referenced in ACLs and many Windows security processes work just fine without any need to directly read the membership of the relevant group or user objects. I’ve already mentioned the consequences we deal with, and there are applications that we do need to help to enable.

I’m aware of several universities in Canada which have interpreted FIPPA legislation (which is similar to FERPA) to mean that they must hide user objects. I advised against this, but I believe some of them proceeded. I haven’t heard how that worked out for them, but I’ll update this if I do.

I’ve heard from someone wanting to hide the mail attribute on a specific user. Here’s what I told them:

The mail attribute is part of the property set called “Public-Information”. An explicit ‘allow Authenticated Users: Public-Information’ is granted by default as part of the defaultSecurityDescriptor from the schema definition of the user object class. If you want to hide mail, in addition to emptying the ‘pre-windows 2000 compatible access’ group (or just removing the explicit ACE on that one user object), you’ll also need to remove the explicit Public-Information allow ACE from the relevant user object. But Public-Information includes a whole slew of attributes that frankly are really important to have read access to. So you’ll then need to re-add explicit allow ACEs to each of the attributes in that property set except for mail. That’s like 63 ACEs or so (I’m a bit behind on AD schema analysis, so that number is only good circa 2010 schema). And you’ll need to watch all future Microsoft schema changes to find new attributes they add to Public-Information and manually add those too. Doable, but yucky.

Wrap Up

So as you can see, you can hide information in AD. There is a cost to doing so that you will continue to pay beyond implementation. You’ll need to make a decision whether the value you get is worth that cost.

Some presentations I’ve given about this topic:


Digging into the Windows Servers 2012 R2 AD Schema Changes

After I download any new server OS release, the first place I go is to take a look at the AD schema. Conveniently, this doesn’t require me to install the OS (and I can even peruse it while I’m getting the OS setup). You can find the AD schema LDF files on each server ISO at:


I do something like this:

E:\support\adprep>copy sch57.ldf+sch58.ldf+sch59.ldf+sch60.ldf+sch61.ldf

And then I’ve got a single file with all the schema for a given release to browse.

I’m probably a schema geek for doing this, but I always find that I learn about new features and things Microsoft and no one else hasn’t yet written about before everyone else does. 😉

Each AD schema version number corresponds to a separate LDF file used to update the AD schema. Over the 6 server OS releases that included schema, they amounted to 56 files.

2000: 13
2003: 30
2003R2: 31
2008: 44
2008R2: 47
2012: 56
2012R2 (preview): 69

So this is one of the bigger jumps, which in the past has only happened with a major OS release, not an R2 release.

Of course, what’s really interesting is what is in each of those LDF files. A given file might have only a single schema change or it might have dozens.

OK, that’s enough babble about the background, now let’s jump into the new schema!

From a big picture perspective, almost all of the changes are to support the BYOD enhancements you may have heard Microsoft talk about at TechEd 2013. These include a device objectclass (msDS-Device) to support the workplace join functionality, as well as various other classes to support the infrastructure behind that workplace join functionality.

Here’s a redacted excerpt of the new msDS-Device class:

dn: CN=ms-DS-Device,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-Device
systemMustContain: 1.2.840.113556.1.4.2248
systemMustContain: 1.2.840.113556.1.4.2252
systemMustContain: 1.2.840.113556.1.2.13
systemMustContain: 1.2.840.113556.1.4.867
systemMayContain: 1.2.840.113556.1.4.2249
systemMayContain: 1.2.840.113556.1.4.2250
systemMayContain: 1.2.840.113556.1.4.2251
systemMayContain: 1.2.840.113556.1.4.2257
systemMayContain: 1.2.840.113556.1.4.2258
systemMayContain: 1.2.840.113556.1.4.2262
systemMayContain: 1.2.840.113556.1.4.2263
systemMayContain: 1.2.840.113556.1.4.2270
systemMayContain: 1.2.840.113556.1.4.2271
systemMayContain: 1.2.840.113556.1.4.2273

Pretty ugly, huh?

Well, that’s really just a set of optional attributes and required attributes. That means these attributes …

msDS-IsEnabled: This attribute is used to enable or disable the user-device
msDS-DeviceID: This attribute stores the ID of the device.
altSecurityIdentities: Likely that this contains a X509 certificate.

msDS-DeviceOSType: This attribute is used to track the type of device based on the OS.
msDS-DeviceOSVersion: This attribute is used to track the OS version of the device.
msDS-DevicePhysicalIDs: This attribute is used to store identifiers of the physical device.
msDS-DeviceObjectVersion: This attribute is used to identify the schema version of the device.
msDS-RegisteredOwner: Single valued binary attribute containing the primary SID referencing the first user to register the device. The value is not removed during de-registration, but could be managed by an administrator.
msDS-ApproximateLastLogonTimeStamp: The approximate time a user last logged on with from the device.
msDS-RegisteredUsers: Contains the list of users that have registered the device. Users in this list have all of the features provided by the “Company Portal” app. And they have SSO to company resources.
msDS-IsManaged: This attribute is used to indicate the device is managed by a on-premises MDM.
msDS-CloudIsManaged: This attribute is used to indicate the device is managed by a cloud MDM.
msDS-CloudAnchor: This attribute is used by the DirSync engine to indicate the object SOA and to maintain the relationship between the on-premises and cloud object.

There’s lot of interesting details there, including the fact that multiple users can be registered for the same device, and the last two attributes imply that you will be able to workplace join a device to either your on-premise AD or your Azure Active Directory and a future unreleased version the Azure DirSync will sync devices between AD-DS and AAD. This would represent a change in the nature of the Azure DirSync product, which currently claims it doesn’t sync any objects back to on-premise and only does a handful of attributes back when you enable Exchange hybrid. Note that you wouldn’t know this without looking at the schema

Related to the BYOD enhancements a lot of the changes are to provide a new authentication policy feature, which hasn’t gotten much, if any, demo time in TechEd sessions.

I find that class pretty interesting, so here’s a partially redacted excerpt of it with some further simplification to make it easier to read:

dn: CN=ms-DS-AuthN-Policy,CN=Schema,CN=Configuration,DC=X
adminDescription: An instance of this class defines authentication policy behaviors for assigned principals.
systemmaycontain: msDS-UserAllowedToAuthenticateTo
systemmaycontain: msDS-UserAllowedToAuthenticateFrom
systemmaycontain: msDS-UserTGTLifetime
systemmaycontain: msDS-ComputerAllowedToAuthenticateTo
systemmaycontain: msDS-ComputerTGTLifetime
systemmaycontain: msDS-ServiceAllowedToAuthenticateTo
systemmaycontain: msDS-ServiceAllowedToAuthenticateFrom
systemmaycontain: msDS-ServiceTGTLifetime
systemmaycontain: msDS-UserAuthNPolicyBL
systemmaycontain: msDS-ComputerAuthNPolicyBL
systemmaycontain: msDS-ServiceAuthNPolicyBL
systemmaycontain: msDS-AssignedAuthNPolicyBL
systemmaycontain: msDS-AuthNPolicyEnforced

Note that there appear to be multiple new authentication controls here, which personally make me very eager to discover the details.

One gem in those controls is it appears that there is now support for *per user* Kerberos ticket lifetimes. This would be useful for combatting pass the ticket Kerberos attacks (like pass the hash), where you might give sensitive accounts (think domain admins) a much lower ticket lifetime than other accounts.

Other gems in the schema are 4 new extended rights supported by AD:

dn: CN=DS-Set-Owner,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Set Owner of an object during creation.

dn: CN=DS-Bypass-Quota,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Bypass the quota restrictions during creation.

dn: CN=DS-Read-Partition-Secrets,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Read secret attributes of objects in a Partition

dn: CN=DS-Write-Partition-Secrets,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Write secret attributes of objects in a Partition

I’m not sure what to make of these yet (I have a few thoughts), but they are intriguing.

One thing that is always interesting to carefully note is when an existing class is modified. This is especially true when the user class or the granddaddy of all the classes, top, is modified. And in this case, the top objectclass is modified:

dn: cn=Top,cn=Schema,cn=Configuration,dc=X
changetype: ntdsschemamodify
add: systemMayContain
systemMayContain: msds-memberTransitive
# This constructed attribute transitively expands the linked attribute “member”
systemMayContain: msds-memberOfTransitive
# This constructed attribute transitively expands the linked attribute “isMemberOfDL”
systemMayContain: msDS-parentdistname
# No help text, but probably the object’s parent DN
systemMayContain: msDS-ReplValueMetaDataExt
# No help text, your guess is as good as mine

I’m not sure what to make of these changes, but since the member attribute is a highly controlled attribute in my AD environment, I’m glad to know about this, so I can dig deeper to uncover what this is all about.

Well, that’s it for now. I’ll probably keep digging into the new schema to see if I can’t find any more gems like these, but even if I stop here, I have some great details to help guide my explorations of the WS2012R2 Preview and I know something about a future Azure DirSync release that most everyone else doesn’t yet know.

Azure Active Authentication

Details about Azure Active Authentication were released June 12th, 2013:

-Overview on the Azure Identity page: http://www.windowsazure.com/en-us/services/identity/

-Pricing: http://www.windowsazure.com/en-us/pricing/details/active-directory/

-How to manage: http://technet.microsoft.com/library/dn249466.aspx

-How to integrate with your own applications: http://technet.microsoft.com/en-us/library/dn249464.aspx

Excerpt from the last page:

“The Windows Azure Active Authentication SDK allows for you to directly integrate the features of Windows Azure Active Authentication. You can build Active Authentication phone call and text message verifications directly into your applications sign-in or transaction processes. To get started with the Windows Azure Active Authentication SDK see Download”

Azure and Microsoft cloud developments announced at TechEd 2013

Here’s a round-up of various new developments announced at TechEd 2013:

-Azure Active Authentication is being launched. This is the PhoneFactor acquisition re-branded and deployed as part of the Azure Active Directory ecosystem. See http://blog.phonefactor.com/2013/06/03/phonefactor-windows-azure-active-authentication/ for something about that. I believe you can deploy this today via the Azure Service portal (with some kind of subscription required), and Office 365 plans to roll it out in the next 3 months. O365 will require it for all “admin” accounts with a free license for them, and they are still working out the licensing details for other O365 users. I haven’t yet heard any plans to allow this service to be integrated with on-premise solutions, but it was a question at one of the sessions and the speaker noted they were thinking about that.

-Azure Authentication Library is being launched. This is a new library that allows you to easily integrate your on-premise or cloud based web application with Azure Active Directory. See http://www.cloudidentity.com/blog/2013/04/22/windows-azure-authentication-library-aal-for-windows-store-a-deep-dive/ for something about that. Note support for OAuth2.

-BYOD enhancements for AD-DS and Azure Active Directory (AAD). Later this year, AAD and WS2012R2 will provide a way for you to “workplace join” personally owned devices from iOS to Android based. On premise, a new component in ADFS facilitates this and issues a long-lived certificate to the device which provides a SSO like experience to the device user. There is good support for deprovisioning the device, with additional selective wipe capabilities dependent on various other Microsoft product integrations. One of those integration points is Microsoft InTune in concert with SCCM. InTune is a cloud-based device management service. We own InTune licenses, but don’t yet have any service leveraging it …

-Along with the BYOD enhancement, Microsoft is enabling per SP multifactor support in ADFS. 3rd party providers can leverage a new multi-factor authentication (MFA) provider capability in ADFS to integrate their authentication methods. As an example of this, SafeNet has been working with Microsoft to provide one of these MFA providers using their hardware/software OTP, SMS, and GrIDSure options as a strong authentication as a service via a cloud based service. Whether cloud-based multi-factor services emerge might be something interesting to keep an eye on.

-I expect most folks saw that Microsoft slashed Azure VM rates 8 days ago to match Amazon EC2 rates, as well as announcing they won’t charge for stopped VMs, and moving to a per-minute charge model. Microsoft had several sessions promoting using Azure VMs for pre-prod/product evaluation/development purposes because you don’t sink costs into a physical on-premise box–and you only pay for the actual time you need the VM.

-Microsoft revealed a strategy to provide a consistent management interface for private cloud and Azure based services. For those that missed it, back in January Microsoft released the Azure Services for Windows  Server, so you can deploy private cloud capabilities on-premise just like Microsoft’s. Last week, this release was renamed the “Azure pack” and a number of enhancements were revealed that will come with Windows Server 2012 R2 planned for release this year. Among the various announcements are System Center capabilities that make it very easy to migrate VMs between on-premise HyperV and Azure, and enhancements to the HyperV Replica features that include using Azure as a HA failover for your on-premise HyperV VMs.

Lots more, but my memory is running dry. 😉

I expect that we’ll learn more details about these new capabilities in a couple weeks when Microsoft holds its annual conference for developers and the Windows 8.1, Windows Server 2012 R2, and System Center preview bits are likely to be released.