Identity Administration: AD Identity operations and the link to the Identity cube

Let’s look at this use case and its fairly common in organizations. There is an IGA product that handles provision and deprovision of HR joined users to various down stream systems such as Active Directory (AD). Now I am going to talk specifically about AD because that is the security directory of most organizations. In these organizations, AD account operations is mostly done via an AD management product (there are several out there, I will not call them out). I have always wondered why organizations have this setup. Some argue that

1. HR does not have all identities. We need to create application accounts, generic accounts etc.
   
2. AD Management products provide more easy operations with several options.
   
3. Bulk changes in AD are easier in the AD product.
   
4. There are some user operations that only an AD product can handle.
   

Let’s discuss each one

HR does not have all Identities. That is true and I have seen organizations that actually feed everything via HR including application and test accounts. It’s a mess and it is not the right location. HR should Not have all Identities and HR is Not an Identity management product.

Easy Operations: I do agree with this but most of these options can be customized into the IGA product.

Bulk Changes: The IGA products treat each change as a trackable request that must be logged for audit. Convenience should not supersede traceability.

AD User operations that only AD product can handle: Name a few I ask, when I have drilled down on this statement, I have found it incorrect, it just requires some customization on IGA product.

Identity in AD

Every account in AD should be taken as an Identity with properties. If that identity is not from the authoritative identity source (HR Joined) then that identity should be a derivative of an HR Joined Identity. Since the HR Joined identity is managed in the IGA product then the creation of that derivative identity must be in the IGA product so that the relationships are created and maintained in the IGA.

The end goal should be that all AD objects should be derivatives of the HR Joined identity. Any object that is not a link to an HR Joined object will be regarded as orphaned and you should have policy to find a home (an -HR-joined identity) for the orphaned objects so that they become derivatives.

Where does Identity start

Identity starts in HR. Some organizations have told me that identity can start anywhere. The excuse is that HR records are not organized (alarmingly, mostly true) and so they cannot use the data as a true source. I disagree with that; data can be organized but it takes a buy-in from upper management (unfortunately this “buy-in” comes when there is a major audit finding report to the board of Directors) and it takes time. In the meantime, your IGA will become the source of truth and will handle the integration of employee data with derivative creation of objects in AD.

An IGA product is a relationship-based database where there is a primary IGA identity and there are links to this primary identity. By establishing these links, changes to the primary identity will affect the linked identity. These could be life changes (marriage, divorce, name change etc.) or organization changes (promotion, demotion, reassignment, layoffs etc.). Identities become real and moving entities and not static, siloed and orphaned.

Here is a view of the IGA identity and related AD objects

In the diagram I have also shown accounts that are not directly linked to HR. For instance, most organizations do not manage contractor accounts in their HR system, they may use a system that is connected to their finance requisition system. These contractor accounts should be created and managed by the IGA system and linked to an HR joined identity.

End state-Stable, secure, consistent directory

1. No orphaned objects in your Active Directory. All objects can be accounted for and activity reports can be generated and verified (by an HR joined person) on these objects.
   
2. Objects in AD are created by one tool and one account in a consistent manner.
   
3. There is one place (IGA tool) to apply all user related security policies.
   
4. All direct access to AD can be removed for individuals. This moves the organization to a more secure privileged access operation where such access will be only to make AD system changes and can be requested, tracked and approved each time.
   
5. Attestation and certification can be done on all objects in the directory. I find it interesting that some accounts e.g., shared mailbox and conference room accounts are often ignored in organizations because they are created “disabled” and no access is given to these accounts. They really become siloed and orphaned objects which is a security gap.
   

Moving ahead

1/ Audit all AD user and group Operations. Document what AD operations staff currently does directly in AD.

2/ Categorize the different types of AD accounts and the different types of user related operations. Categories like pre-creation requirements, post-creation, normal BAU and on-demand.

3/ Create forms or a form for AD group management in the IGA. Move all AD group management to the IGA.

4/ Create forms or a form in the IGA to create an AD link in the IGA which will trigger an identity creation in AD. Move all AD account creation to the IGA.

5/ Create forms or a form in the IGA for AD identity edit, these are for AD attributes that HR is not responsible for direct change due to their impact in AD e.g samaccountname, UPN. Move all AD account edit to the IGA.

6/ Remove all direct user privileged access to AD. Create roles in the IGA and assign privileged groups to it. Users can be assigned to these roles on approved demand. A PAM tool can also be used for this.

7/ Audit all applications that perform any type of AD user and group operation. Document what do they currently do directly in AD.

8/ Integrate the application with the IGA so that all AD related operations are sent to the IGA via an API request. Alternatively, the IGA can also pull AD requests from the application via the applications API and execute on the IGA AD User identity.

9/ Update your IGA AD user and group management system to include what is done by these applications. Not all operations may be transfer possible but do as much as possible.

10/ Remove all application accounts direct privileged access to perform AD activity. All privileged groups should have zero members by default. Specific AD ACL rights required by applications can be given to AD groups, these groups are associated with Roles in the IGA and the application accounts assigned to these roles. A PAM tool can also be used for this.

11/ Create form or forms for bulk AD identity creation or edit in the IGA tool. Move all bulk AD operations to the IGA tool.

12/ Setup periodic attestation and certification of AD objects in the IGA tool. I am not talking about just access or entitlement attestation but also an existence attestation. Is this resource object still needed? The HR joined owner or manager will complete the campaign.