Identity and Access Management Transformation

By Ryan Ward

Organizations that have grown through acquisitions often accumulate a great deal of IAM debt
if a solid M&A playbook is not in place to efficiently consolidate environments. This leads to
inefficient operations, security gaps, audit findings and the inability to execute on core goals.
This playbook provides a cheat-sheet of tactical and strategic plans of attack to stabilize and
mature an ailing or inefficient IAM function. The successful execution of the concepts within
this manifesto require a transformational and influential leader who understands the business
along with all technologies that touch the identity landscape.

Resist the urge to focus on technology

Throwing technology on top of poorly managed IAM processes and dirty directories will only
mask the core problems and those problems will most likely creep back into the environment
and disrupt technology implementations. The better approach is to clean the environment
first to solve account issues and unify common policies across multiple directories. Yes, con-
solidation should be a long-term goal, but trying to consolidate when policies differ and there
is no linkage of authoritative data will derail technology deployments.

Close Open Audit Findings

Entering into an IAM transformational phase requires the ability to execute the concepts be-
low without being driven by outside forces such as Internal or External Audit. Whenever pos-
sible, strive to close any/all open audit findings early in the process. Closing these findings
can often be accomplished by addressing the next few sections.

Directory Cleanup/Optimization/Alignment
This phase of work is critical and often overlooked, but all these directory cleanup concepts
help set the foundation for a solid directory consolidation. Plus, these items help to prepare
for an improved end-user experience. The work here is substantial and requires an analytic
mindset in many situations to analyze the data to make the correct decisions.
• Orphan account cleanup: A common audit finding and security gap relates to or-
phaned accounts, therefore analytics should be performed to reduce this risk immedi-
ately. Run Powershell scripts to pull ALL account data from ALL directories into a nor-
malized SQL database. Establish a recurring feed of authoritative HR and Contractor
data and pull that into a table for analysis against the directory data. If no unique
identifier exists across all the domains see the next bullet point. Match user data
against the authoritative HR user data to find active accounts. Script this process so it
is run regularly.
o Link HR unique ID to the same unique ID stored within account attributes
o If no unique ID linkage, start with common naming convention formats (i.e.
first letter first name, last name username format on samAccountName)
o If email is stored in HR, align to email
• Authoritative Unique ID: If a unique key is not present on every user account across
all domains, begin the process to establish this standard. A solid approach is to use
the AD employeeID attribute to store the unique HR key of the user. Put effort into
establishing this linkage on every account across every domain. This allows for user
mapping to help with orphan account cleanup as well as establish a foundation for
password synchronization to help with consolidation efforts. AD consolidation will also
need a mapping mechanism depending on the technology approach selected.
• Primary Domain Assignment: Tied to the item above, a user’s PRIMARY AD domain
should be identified and stored as an authoritative attribute. Having this process
baked into the IAM landscape is needed throughout any consolidation activities be-
cause it will be key to quickly identify which Domain a user leverages to login. Plus,
the authoritative domain will drive the direction of password synch if synchronization
is established. For instance, if a
• Policy Alignment: Pull password policies from ALL directory systems (including ap-
plications) and create a matrix to determine a single authoritative password policy
across all systems. Keep in mind that certain applications may not offer all the capa-
bilities of other directories. If a security upgrade within the application will allow for
greater flexibility, start that process early on. Gain consensus on the common pass-
word settings across all systems and then rapidly pursue alignment of that policy
across domains. A single password policy will make it easy for users to know their
password and it will prime the ability to synchronize passwords later. Password syn-
chronization will break if policies differ.
o Password Length
o Password Expiration duration
o Character requirements
o Administrative lock vs. unlock timeouts (keep in mind administrative lock caus-
es more support pain)
o Minimum password age
o Lockout settings

• UserAccountControl Cleanup: Run Powershell scripts to pull ALL user account data
across all domains and look for issues. Resolve issues and continue to leverage this
data over time. A solid goal would be to have the Powershell script pipe this data to a
central SQL database so all account info (including all account profile attributes) are
available via query. This will also help with unifying attribute information later.
o PASSWD_NOTREQD
o PASSWD_CANT_CHANGE
o DONT_EXPIRE_PASSWORD
o ACCOUNTDISABLE
o PASSWORD_EXPIRED
 o ENCRYPTED_TEXT_PWD_ALLOWED
• Service Account Cleanup: Identify service accounts and begin the process to limit
interactive use on those accounts. This is a setting within AD. Service accounts often
do not have expiring passwords, so they can be compromised to attack the environ-
ment. Start to align on service account naming standards and OU structures. Estab-
lish exception policy for service accounts that require interactive use. If a service ac-
count requires interactive use, adopt the compensating control to limit login from only
specific workstations (AD feature).
• Privileged ID Foundation: Since privileged IDs pose the greatest risk to the organiza-
tion, adopt an account tiering approach where all these IDs are unique and NOT the
standard user account the user leverages for day-to-day activities. Tiering can simply
be a unique naming convention such as username_tr1 or username_adm. Normal user
accounts should not possess elevated privileges, and the admin accounts should have a
stronger password policy (find-grained policy). Ideally, deploying a PAM solution is de-
sired, but keep in mind the user admin onboarding processes of this tool and automate
as much as possible with the IGA platform and server build activities. As Tiered ac-
counts are rolled out, REMOVE admin rights from the standard accounts.
• Single Target Directory: If a global master directory has been identified as the target
for all users long-term, ensure all policies and management practices are solidified
before moving data into it. Clean this directory if it has already inherited garbage
from other domains. Of course, it is critical to establish the ideas above within this
domain. The unique ID is needed to link users between domains.
• User Attribute Standards: When dealing with the challenge of multiple domains,
adopt standard attribute formats wherever possible and perform updates from author-
itative data to align across domains. Of key interest should be attributes visible in
Global Address Books (i.e. Names, Display name format, department, company, loca-
tions, etc.). For instance, when one company has a mail display name of First Last
and another uses Last, First, it can be confusing for users to find someone. Aligning
this data will create the feel of a unified organization as address book data is synced
across mail environments. Plus, it will make it easier for people to find the right re-
source.

O365/Azure AD Challenges
If Azure AD is leveraged along with O365, ensure the core synchronization process is rock solid
and migrate federation to Microsoft’s modern auth approach. AAD Connect and Modern Auth
are key components of this. Decoupling ADFS is ideal. With multiple O365 tenants, a consoli-
dation project should be considered, but that will require substantial thought around the end
user’s primary AD domain, workstation domain and Azure AD structure because the on-prem
trust environment may not align to what is synced to AAD.
Multiple domains and email environments will require special attention in terms of how Azure
AD and O365 is architected and user migrations can be challenging. Also, Skype poses other
challenges since it does not support modern auth. This means the UPN/SIP format decision
could cause pain.
If Azure AD SSO is being leveraged, all identities must reside in the primary AAD Connect do-
main (with synced passwords to the user’s primary domain). This will allow these users to au-
thenticate with the primary AD Domain username/password, BUT seamless (Kerberos) SSO will
not be enabled for users who do NOT login to that domain on their workstation. Password
synchronization is very important in this situation since if they user is used to logging into
their legacy domain with their legacy username/password, they will need their new domain
username/password to match or support tickets will be considerable.
..Many hurdles exist with O365/Azure/AD Consolidation, so that requires a project to identify
the best approach for an organization.

Domain Trusts (2-way/1-way)

AD Domain trusts can help support consolidation efforts, so a full mapping of these trusts
should be created to understand the trust landscape. While wide open trusts across every
domain may not be required/needed, user experience impacts can occur if a trust is not in
place. Security architecture should validate the security posture of environments and AD Do-
mains before establishing new trusts. If a trust is needed, and the security posture of the
source environment is lacking, remediation should occur to help support the IAM needs. If
users from one BU/AD Domain environment need to access applications in another BU/AD Do-
main, trusts can help ease that access. A balance of security risks should be evaluated when
standing up domain trusts because it is often not ideal to create new accounts for users in
multiple domains. Password management becomes a challenge in this scenario as well.

Password Management
Getting a handle on password management and providing easy-to-use self-service password
management capabilities is a big win for an organization since this capability cuts down ser-
vice desk calls and improves uptime for users. A Password Management solution implementa-
tion can often be cost-justified quickly if support agreements are based on ticket totals.
However, self-service password management just include enterprise features to help support
some of the items above.
o Intuitive UI
o Internationalization/Localization
o Full branding of all Text throughout the interface
o Gina/Credential Provider hooks
o Password mapping database to support synchronization
o Mobile interface
o Flexible connector integration
o MFA capability
o Help Desk module
o Potentially delegated help desk capabilities if multiple support groups need to manage
different user groups
Implementing this solution is a project, but synchronization should be carefully thought out to
ease broader access issues during consolidation efforts. Linking all user accounts to a specific
identity (i.e. via employeeID attribute) is a prerequisite. Plus, knowing a users primary do-
main is critical to ensure password mappings are always accurate for synchronization. The
population of the password mapping system must be automated with authoritative data or
passwords will become out of sync. Password policies must align or password sync may not
work.

Single Sign On
Single Sign On not only makes it easier for users to access the applications, it also provides an
added level of security. When a user’s account is terminated, SSO access is then blocked
since the source of authentication is the internal domain. This prevents terminated users
from accessing SaaS apps after they leave the company. A formalized move to SSO should be
orchestrated to improve security and promote ease-of-use. This should become an opera-
tionalized service and security architects should ensure all new apps request SSO as they are
purchased or built.
In situations where there are multiple AD domains, SSO can become challenging depending on
the solution. Robust platforms such as Oracle OAM can mask the domain complexity to allow
seamless SSO via Kerberos, but many other platforms may require unique implementations
per directory.

Other Directory Considerations

While Virtual Directory solutions can mask a complex directory environment, be cautious of
trying to leverage a Virtual Directory to hide underlying technology gaps. If possible, apply
effort to reducing legacy debt rather than maintaining complexity in your environment. Elim-
inating AD domains and the corresponding accounts within those domains should be the first
goal because that will ease support and limit the attack footprint of an organization.

Multi-factor Authentication
If an MFA solution is not deployed, one must be implemented to protect the environment (es-
pecially for Internet-facing services). Pay close attention to selecting a modern solution that
offers intuitive, mobile-based capabilities with a SIMPLE enrollment process. The solution
must also offer flexibility to integrate with a variety of platforms. A solution that only works
with specific operating systems or their own products should be avoided.
PRotect critical Internet-facing services with a risk-based prioritized approach. For instance,
O365/email and VPN should be protected ASAP.

IGA Platform
Depending on the maturity of the current IGA platform, a number of enhancements can occur
as the items above are matured. Detailed enhancements are not detailed in this document as
they will depend on the maturity of the overall IAM landscape. Key priorities of a maturing
IGA platform should be the account provisioning and deprovisioning features and ensuring
many of the data element issues described above are addressed and automated in an IGA
platform.
Phase 2 maturity should focus on robust application provisioning, a focus on standards-based
protocols (SCIM) and Identity Analytics. Do not assume the IGA platform can solve all the or-
ganization’s needs. Sometimes it is wiser to find a niche product to complement the solution
rather than try to use immature/poor features embedded in the IGA platform. For instance,
many IGA platforms have poor UIs, cumbersome access certification engines or lack a solid
identity analytics capability. If switching platforms is not desired, offload your critical needs
to a solution that works. Always focus on API-based approaches so your tools can integrate
easily as the landscape changes.