It’s 2020, why are we still talking about a product that was launched in 2000? Aren’t we 2 decades behind the times? People are moving to the Cloud man!
You are not wrong. Cloud is the first word and last word on many businesses’ IT roadmap. There are a lot of advantages for new businesses to jump straight into Cloud. However, for many other businesses that started before the year 2000 (think, all your big banks, infrastructure services like gas and power), chances are they have adopted Microsoft’s flagship enterprise identity management platform – Active Directory Domain Services. Or simply know as Active Directory. In reality, the Active Directory umbrella contains many other directory services. However, AD DS is the most widely known, and for simplicity, abbreviated to AD. This causes additional confusion when moving to the Cloud as there are now products called Azure Active Directory (AAD), Azure Active Directory Domain Services (AADDS), and none of them are the same. But that’s a topic for a different conversation.
Let’s get back to our on-premise identity management platform – AD DS.
Active Directory was introduced during a time where Microsoft was undergoing its “Active” phase. You had your ActiveX, ActiveSync, Active Server Pages (ASP), Active Movie, Active Messaging… you get the picture. As such, the “Active” part of the name is really rather meaningless.
What do we have left then? Well, Directory.
At its core, Active Directory is a Directory...However, almost all organizations fail to realize that AD is a directory.
At its core, Active Directory is a Directory. In every organization we’ve come across, AD is used as an identity authentication service. You get an account as a user. You join a computer to the AD Domain; and both pieces are then authenticated against the domain to provide you as a user, and the computer you’re using, access to other resources on the Domain, such as files.
However, almost all organizations fail to realize that AD is a directory. Have you looked inside an AD object and realized it has many attributes such as “Title”, “Department”, “Telephone”? Why is someone’s title and department important if I only want to authenticate the user? It’s not. So why are the attributes there?
AD object attributes can be leveraged to store information about each specific object that can later be consumed by downstream systems. For instance, an end user may choose to construct an Org chart in SharePoint using AD as the data source. This requires primarily the manager attribute to be populated, but also any other organizational information the consumer may be interested in. Contact information available in the Exchange address book is another example of a downstream system consuming AD data. It should be noted that certain AD user attributes can be synced with Azure AD so there can be a further downstream benefit for your cloud enabled applications.
As noted previously, all AD objects have attributes. Computers are another example of an AD object that can have useful information stored in its attributes. For instance, the computer's serial number can be written to the “serialNumber” attribute. Additional unused generic attributes such as “info” can be used to hold all sorts of useful computer inventory information such as Make, Model, CPU, RAM, etc. Once this information is populated automatically via start-up scripts run by each computer as it boots, you suddenly have a dynamic, up- to-date inventory of every Windows computer joined to the domain. Reports can easily be generated from this information to provide you actionable insights. If an organization already has an inventory solution such as SCCM, this real time AD information can still complement that solution. For organizations that haven’t invested in a more sophisticated, and expensive inventory solution, AD can be used as a free solution, taking advantage of your existing investment.
We’ve talked a lot about populating AD attributes, but the question arises, where does the data come from? In the case of computers, it’s easy; the computer self reports via WMI. For users, on the other hand, we need a reliable “record of truth”. The logical source for this is Human Resources. This business functional group maintains information about employees, and potentially contractors/consultants as well. If we implement an automated process that links the HR system with AD we can easily populate the most useful user attributes. By automating this process we tie user lifecycle in Active Directory to the HR system. If a person is hired, an account is provisioned in AD along with the various attributes. If their role changes, this information flows once again through the HR system. When the user is terminated, their account is disabled in AD and a deprovisioning process is initiated. Having a predictable user lifecycle adds an additional layer into your environment's overall security practice.
Aside from the obvious benefit of having additional information about the various objects in AD, another enormous plus is the potential for automation.
Aside from the obvious benefit of having additional information about the various objects in AD, another enormous plus is the potential for automation. For instance, role information for a user can flow directly from the HR system into AD or it can be deduced based on the available attributes (e.g. company, division, department, title, etc.). Automation can be implemented that manages authorization to resources in the environment via group membership. In other words, if a user works in department X, they can automatically be added to a security group that has access to department X’s file share. The same thing applies to email distribution lists. Any AD group that only contains members based on consistent identifiable criteria can be automated. This has significant security implications as user access is based on their role in the organization as determined by HR. This reduces the potential for users to have excessive privileges as they move between roles in the organization, and reduces the administrative overhead for your IT Help Desk. In the case or computer objects, automation can be implemented that leverages a meaningful computer naming convention in conjunction to attributes in AD, to manage computer group membership.
To conclude, our observations regarding Active Directory is that there is considerable misunderstanding about its holistic purpose. It is so much more than an authentication system, but should be leveraged to provide significant insights and manageability to your IT infrastructure.
If you would like to initiate a conversation on a comprehensive AD Assessment for your environment please contact us.