Using Active Directory Domain Services as the solid foundation of your Identity and Access Management (IAM) strategy, results in common challenges for most organizations I meet. While the first three parts of this series have focused on objects and links between objects in the Active Directory database. Today, I want to talk about more ethereal stuff, concerning your Active Directory: I want to discuss the value in the actual properties of the objects in your directory, their attributes.
About attribute integrity
When I talk about attribute integrity, the thing that matters most is the way Identity and Access is evolving from a group membership and user-based security solution for domain-joined computers inside (the physical locations of) organizations to a solution based on granular access to resources, information and apps, based on assertions on people and devices.
I’ve written about this trend in a blogpost roughly 6 months ago. In it, I talked about how ForeFront Identity Manager (FIM), Active Directory Federation Services (AD FS), Active Directory Rights Management Services (AD RMS), Dynamic Access Control (DAC), Azure Active Directory, Office 365 and DirSync all leverage properties of user and computer objects in Active Directory Domain Services.
My conclusion back then was that wise Active Directory admins begin now to take care of attribute consistency throughout the identity lifecycle. Fields like Department, Manager (for user objects) and Primary User (for computer objects) are essential. Your current provisioning tool should force you to provide these attributes, processes should be in place to modify the correct attributes in the right way when someone changes department, gets promoted, gets demoted, etc. Furthermore, I recommended frequent audits should take place to trace attribute inconsistencies and proactively solve them.
The Dawn of the BYO Era
At TechEd North America, last week, my feelings towards the importance of attribute integrity grew even stronger. Also, the urgency of having processes in place to guarantee attribute integrity dawned on my.
These two new Windows Server 2012 R2 technologies made me feel attribute integrity is now both important and urgent:
A new feature in Windows Server 2012 R2 is the ability to more loosely couple devices and computers to Active Directory. Next to the exclusive Active Directory domain join, a new join will become available: WorkPlace Join.
This new type of coupling allows for devices to attain a level of trust through a certificate, that allows single sign-on from the device to corporate resources, both on-premises and in the cloud. As an admin you can provide granular access to resources based on whether or not a WorkPlace Joined device is being used or not, whether the users primary device is used on or off the corporate network or whether an untrusted device is used.
I think you can guess where I’m heading with this: the relationships between devices and colleagues is based on object attributes.
Web Application Proxy
The Web Application Proxy allows admins to publish claims to the Internet through a secure proxy for cloud-based applications, partners and vendors. Whenever I read claims, I think of attributes.
When you want to take advantage of these new Bring Your Own (BYO)-inspired Microsoft technologies in Windows Server 2012 R2, attribute inconsistencies will stand in your way of adoption.
When attributes are inconsistent, access to files, apps, partners and cloud functionality becomes inconsistent. If you think it won’t happen to you, think twice. During the first internal Microsoft deployment of Dynamic Access Control, attribute inconsistency was the first encountered problem; in the past a user account was incorrectly changed from a temp to an FTE, resulting in Access-denied situations. You’d think Microsoft, of all companies, knows how to manage Active Directory.
(Part of) The Solution
Unfortunately, no turnkey solution exists to eradicate attribute inconsistency throughout your networking environment. However, the following pieces of action exist to remedy the situation:
First of all, your biggest problem is not that attributes for users and devices have become inconsistent, but the way these inconsistencies were (unnecessarily) introduced.
Before you can go and perform a meaningful and long lasting spring cleanup of the data in Active Directory, you will need to have a plan of what the information in Active Directory should look like and how to keep the information up to date. This should be captured in a design and corresponding policies with accompanying management procedures and auditing.
Needless to say, this design, the policies and procedures should be kept up to date and thus reviewed regularly
Use a (de)provisioning tool and/or script
Now, part of these procedures for optimizing communication, in some organizations Human Resource (HR) Departments are granted delegated control to create and/or manage objects. These colleagues should be provided with a tool and/or script to perform their management tasks. Whether you opt for a GUI on top of your PowerShell scripts or turnkey solutions like Z-Hire and Z-Term, is up to your needs.
Even if you’re not delegating control, one of the things we can learn from the management approaches for Online Services like Microsoft’s Office 365 is to use a script whenever possible. My rule of thumb has become to perform a repeatable action with a script the third time around.
Perform your attribute spring cleanup
With (naming) policies in place, attribute inconsistencies don’t magically disappear. You will need to actively search for these inconsistencies and solve them. The most straightforward way I know is to make an export from Active Directory with csvde.exe, open the export in Microsoft Excel (Web App) and search for inconsistencies by sorting in columns and/or validating data.
If you’re not into Microsoft Excel, you can also use Google Docs to this purpose. Spreadsheets in Google Docs allow for sorting and data validation. On the other hand, you’d probably want to keep the information on your colleagues on-premises instead of in a
After identifying the inconsistencies, target the specific rows (users, devices, groups) and change offending attributes to what they’re supposed to be, with scripts.
Audit attribute integrity
Don’t think, after you’ve performed a spring cleanup of your Active Directory, attributes will be fine for the rest of your career. You should perform regular sample surveys to proactively detect attribute (and thus process and/or policy) inconsistencies. Auditing changes to Active Directory objects might allow you to find offending colleagues who (unintentionally) specify inconsistent attributes.
Blocking and/or workflowing attribute changes
A more complete strategy to prevent attribute inconsistencies is to block or workflow changes to attributes. Solutions like Dell’s ActiveRoles, STEALTHbits’ StealthINTERCEPT might work wonders in your environment to prevent unintentional changes to attributes. Custom solutions based on System Center Orchestrator and/or the Windows WorkFlow Foundation in SharePoint, might also make for a more organization-friendly, but more labor-intensive solution.
Attributes integrity is getting more and more important in Identity and Access Management (IAM). When you want to take advantage of new Microsoft technologies, like the new Windows Server 2012 Dynamic Access Control, Office 365 single sign-on, or the BYO solutions in Windows Server 2012 R2, attribute inconsistencies will stand in your way of adoption.
Common Challenges when Managing AD DS, Part 1: Security
Common Challenges when Managing AD DS, Part 2: Unnecessary Complexity, Token Bloat
Common Challenges when Managing AD DS, Part 3: Performance
Why Active Directory attribute integrity is getting more important (and you should care)