Identity and the Cloud: Introduction
Your Active Directory is a mess. 15 years rolling down a slope of changing best practices, slamming through new features, and collecting forest trusts from company mergers, demergers and resource forests has left it a complex landscape of duplicate users and disparate management.
In the distance you see the cloud, the crystal castle of fixed-cost services. You start along the road – only to be stopped at the first gate. The guard cocks an eyebrow and looks over your shoulder, you look back too as he breaths the word, “Identity.”
Too dramatic? Perhaps, but many large companies are standing at this gate. Without solving the problem of Identity, the path to the cloud demands you to go through the mountains.
Cloud services are designed around a flat identity structure with sanitized data. When you try to push unmanaged Active Directory data into the cloud, you’ll stumble. If the cloud service you are leveraging is critical to your business you might even fall.
Once, while working with a very large company, I saw firsthand a migration to Exchange Online Protection (EOP) go horribly wrong due to Active Directory data cleanliness issues. Active Directory Connect (formerly DirSync) doesn’t synchronize data from your on-premises Active Directory directly into the cloud. Office 365 will automatically stamp your UPN as a valid mail address for each synchronized user. Because EOP uses Azure Active Directory data as its source, this company found that mail destined for one user was sent to another user whose UPN matched their email address.
The result? Around 500 users didn’t receive external mail, rollback was not an option and a large environment meant long delays between synchronizations. Days passed before the company resolved all the problems.
Don’t let this situation happen to you. This blog post discusses data sanitation and object life cycle in Active Directory and offers practical solutions so you can reach the cloud with less hassle.
Identity and the Cloud: Aiming Higher
Active Directory has matured a lot since 2000, and best practices have changed as the feature set and security options have evolved. Before beginning your cleanup, assess your current design and determine if some big changes should be made before focusing on the details.
Stick With a Single-Forest, Single-Domain Model
In a modern Active Directory environment, there are very few reasons to have multiple domains and even fewer reasons to have multiple forests. There was a time when a new domain was required for a different password policy, and schema updates were so scary that a resource forest was considered the critical for an Exchange deployment. Those days have passed, now we want a simple-to-manage environment with as few administrators as possible.
There are only two reasons why you might expand beyond a single-forest, single-domain model:
- Strict security boundaries:
- Active Directory’s real security boundary is at the domain level. If you have a set of resources that absolutely must not be impacted by external administrators, you will need a separate domain.
- Replication links:
- If you have network links stuck in the 1980s – think satlink on an off-shore vessel or at a mine in the middle of the jungle – you might need a separate domain. Check out the comprehensive article at , get out your calculator and see what can be done.
In the past you would have needed a custom FIM implementation and/or an intermediate AD forest to even leverage a multiforest environment with Office 365. Active Directory Connect now supports multiforest replication (https://msdn.microsoft.com/library/azure/dn510976.aspx), but it isn’t without its challenges – namely, conflicting usernames and duplicate user identities. If you don’t fit into one or both of the scenarios described above, get out your Active Directory migration toolset and get rationalizing.
Use a Publicly Routed Forest Name
Is your forest DNS name Corp.Local? Stop it now! Microsoft has recommended since 2007 that you use a publicly routed (and owned) domain for your DNS domain (https://technet.microsoft.com/en-us/library/cc772970%28v=ws.10%29.aspx). The problems with this type of forest name are numerous, and now that global top-level domains are being sold to the highest bidder, someone else could own your domain and divert your authentication traffic to his or her own servers – accidentally or intentionally. With cloud comes mobility, and with mobility comes an increasingly high risk that someone else can control the gateway between your users and your servers. If you are designing a new Active Directory, put a publicly routed and owned forest name on the must-have list.
Use an Email Address to Log On
Despite being considered a legacy format, DOMAIN\Username has managed to hang around as the default log-in format for Outlook on the web (formerly OWA; ), workstations and many legacy apps. With the advent of the cloud, it is time to let go of the DOMAIN\Username format. Populate your users’ UPN values with their email addresses, and encourage the UPN format wherever possible. Email addresses are already unique in the world, so they are a safe choice.
Assign Each User a Single Active Directory User Object
Resolving the issue of duplicate identities can be challenging, but it’s a necessary task. User accounts have a real cost in a Software-as-a-Service scenario. That duplicate identity problem is feeding the lazy monkey $10 a month per user, so solve it.
Set Active Directory Data Standards
If you want the best experience for the cloud, document how your Active Directory data should be used. Consider the following factors:
- Attribute data:
- Do you want your GAL to contain a phone number in the global dialing format? We get the data we deserve. Document the requirement, and search for and remediate the data.
- Custom attributes:
- Do you use extensionAttribute15 to filter users from Office 365 (https://msdn.microsoft.com/en-us/library/azure/jj710171.aspx)? Document the usage.
- Username format:
- Choose a naming standard that will prevent duplicates.
- Flat structure:
- Remember, you really need OUs only when you have a specific group policy or security delegation requirement. Most of your OUs are unnecessary.
Automate and Remove Delegations
Identity management may have lost some of its shine, but it is as important as ever. If you are opening up your Active Directory Users and Computers console every time someone needs their phone number updated, or access to a file, you’re doing it wrong.
Automation is the only way to standardize and achieve a clean user identity landscape. The price tag on top-shelf identity management suites can be steep, but there are some (almost) free options as well.
Once you have automated the majority of your access requests, you’ll delegate access to less people. Fewer admins translate into fewer unmanaged changes and, in turn, higher security. The outcome: a cleaner environment.
Identity and the Cloud: The Identity Life Cycle
Users are born into the data world and affixed with employee IDs, telephone numbers, middle names and titles. They get access to resources, they move positions and offices – and then they accidentally hit the big red button that shuts down the data center. So they’re fired, leaving you scrambling to find the delete button to revoke their access before more bad things happen. This is the identity life cycle, albeit a particularly eventful version.
Provisioning occurs when we grant the first IT resource: the user account. This should never be a manual process. Employee churn averages around 10% (http://www.compensationforce.com/2014/02/2013-turnover-rates-by-industry.html), manual provisioning usually runs at least two hours per user. Back-of-the-napkin calculations show that manual provisioning requires a full-time IT admin for every 10,000 employees. A well implemented identity solution will eat IT costs and fund itself.
For the cloud, each provisioned user has a direct monthly cost; within large companies, such individualization makes it easier to understand each user’s cost. Identity management solutions typically allow tracking of requests with the opportunity for a successful back-charge model so that your business units can account for the true cost of an employee, including licensing, IT management, etc.
Granting access to network resources and updating users’ contact details are tedious tasks. Delegate and automate as much as possible. Push the hard work, to the end users with self service solutions.
Revoking access to resources is critical to security. This is especially true for cloud services, because often the user can access services from anywhere. Plus, the number of users generally defines how much you pay.
Be aware that modern authentication models are susceptible to continued credential use after accounts are disabled (http://blogs.technet.com/b/messaging_with_communications/archive/2012/06/27/part-ii-outlook-amp-owa-disabled-accounts-and-users-still-being-able-to-access.aspx). A malicious employee who is logged in to his or her Office 365 email on a mobile phone is still likely to have access for eight hours after you disable his or her account in Active Directory. It’s not possible to invalidate a live SAML token, but you can reduce the SAML token expiry period by manipulating the web SSO token lifetime and the relying party token lifetime on the ADFS server. Remember, this needs to be done before you fire a malicious employee.
When you remove a user from the cloud, often his or her data will disappear too. Test your SaaS systems, and come up with a plan to retain any user data you don’t want to lose to digital heaven.
For Office 365, consider what you will need to happen to the user’s mailbox once their account is removed and license reclaimed. After the 30-day soft delete period, that mailbox will be gone unless you enable legal/litigation hold (https://technet.microsoft.com/en-us/library/ff637980%28v=exchg.160%29.aspx) or convert it into a shared mailbox ).
Identity and the Cloud: Active Directory Data Sanitation
To enter the cloud – and prevent problems while you’re there – you’ll need to manage users throughout their life cycle to ensure your data becomes clean and stays clean.
Active Directory Data Cleanup
The low-hanging fruit in your Active Directory data sanitation project should be the stale objects. These are typically built into enterprise data analysis and reporting tools, but something that appropriately matches your needs should be easy to assemble with PowerShell.
Take a look at your OU structure. Do you have more than three levels? If so, you probably have OUs you don’t need. Follow the KISS principle: Keep it simple, stupid. You need a new OU only when you want to do one of the following two things:
- Assign a group policy to a subset of users/computers only
- Delegate permissions to a subset of objects only
If you have OUs that exist for different departments or geographical regions, there is a good chance your structure is more complicated than it needs to be. The simpler your OU structure, the easier it will be to understand where each object should go.
If you haven’t already, seriously investigate your options in terms of identity management products. If your HR system could automatically create and update a standards-compliant user object, you wouldn’t be reading this. After all, standards compliance is the promise of identity management.
I’ve seen a few of these products in my time: Dell One Identity Manager, Forefront Identity Manager, NetIQ Identity Manager, Tivoli Identity Manager. Choosing a product that meets your specific needs is beyond the scope of this blog post, but if you haven’t yet looked at what these products can do, you should.
Even if you aren’t playing with the big boys, at least write a PowerShell script to provision users in a consistent way (http://blogs.technet.com/b/heyscriptingguy/archive/2014/05/31/weekend-scripter-use-powershell-to-automate-active-directory-accounts.aspx).
Something else to keep in mind is the Exchange Scripting Agent, an option available with your Exchange on-premises deployment (https://technet.microsoft.com/en-us/library/dd335054%28v=exchg.150%29.aspx). The Scripting Agent allows you to insert a layer of validation before cmdlets run using the Exchange Management Shell or the Exchange Management Console. It can be used to enforce Active Directory data standards when your administrators are creating user accounts.
The standard event log-based auditing tool set will get the job done in a small environment. Consider using event log collection services to aggregate your logs into a centralized console. Many vendors offer auditing tools as well, so look into the options available to you. Knowing when and where a change is made will help educate your team and allow you to manage unscheduled changes.
Keeping your Active Directory data clean is a never-ending challenge. The more automated your processes are, the cleaner your environment will ultimately be. I hope this blog post has been helpful. Please feel free to leave feedback.