Identity Management: Manage the identity lifecycle
There are a number of solutions and strategies for managing identity in your organization, and it’s essential that you have the right controls in place.
Adapted from “Protecting Critical Data by Managing the Active Directory Identity Lifecycle” (Realtime Publishers)
Managing identity is ultimately about managing access to your corporate resources. Users authenticate to resources with their identity, then use the properties of that identity (for example, group membership) to get authorized access to resources.
In a typical midsize-to-large organization, you might find the following identity sources:
- Active Directory
- Other directory services
- HR systems
- Custom line-of-business (LOB) applications
- Third-party Software as a Service (SaaS) Web applications
- Local system accounts on Windows, Linux or Unix
All of these identity stores present challenges. Each one requires its own provisioning event (and de-provisioning event, as well) into what are usually disparate data stores: directories, databases, flat files or, in some cases, proprietary formats. Each one has its own set of authorization mechanisms and unique ways of granting access.
Windows uses security groups, databases such as Oracle use custom roles built-in to the database, and other LOB applications use different mechanisms. More recently, SaaS applications are becoming prevalent, which means you’re now required to provision access to both internal and external applications.
It’s important to not blur the lines between authentication and authorization. Some products can integrate into Active Directory for authentication (for example, through Kerberos), but still keep their own authorization mechanisms that don’t directly leverage Active Directory ones such as security groups. This kind of mixed integration may or may not help your provisioning processes.
This mix of identity stores increases the complexity around ensuring the right users are provisioned into your environment, and de-provisioned when the time comes. It also increases the importance of having lifecycle management in place because it becomes a lot easier to “lose track” of identities if they’re not all knitted together using a common framework. Many organizations have had far more identities stored in a system than they had users. When asked why that was, the response was usually something like, “Oh, those are old users who are no longer here.” That kind of poor identity management is a recipe for unauthorized access, failed audits or both.
Reduce identity stores
If you’re in one of those organizations with a wide variety of identity stores, you already know you have your work cut out for you in terms of managing all of those identities within a cohesive framework. But there’s another point to consider. One option is to reduce the number of identity stores by finding common identity systems into which you can collapse other standalone systems. Active Directory is increasingly becoming that common identity system for more systems and applications.
There are third-party and built-in products that let you use Active Directory as the primary authentication mechanism for Linux, Unix and Mac. These solutions typically leverage the Pluggable Authentication Modules (PAM) architecture within these OSes to let Active Directory act as a Kerberos authentication realm for these systems, almost the same way that Windows systems do.
In fact, with many of these mechanisms, you can “join” Linux, Unix or Mac computers to Active Directory just as you would Windows desktops or servers. Instead of logging into Unix or Linux systems using a local account, you can now use an Active Directory account to authenticate your users and ultimately authorize them to Unix resources using Active Directory groups.
Any applications running on those non-Windows boxes that use PAM to authenticate and authorize users to local accounts can now use Active Directory integration to support Active Directory account authentication and authorization. Again, this situation will be application-dependent, but it means you may get some Active Directory integration “for free” once you integrate the base OS.
Also, many third-party applications and application platforms support authentication and authorization using Active Directory in some form, including packaged apps such as SAP and Java Web application servers from Oracle Corp. and IBM Corp. Even Oracle databases support authentication and authorization integration into Active Directory using a variety of integration methods, from straight Kerberos to integration into Oracle’s own LDAP directory service.
Regardless of the method you use, there are obvious advantages in trying to reduce the number of identity stores you have to fold into your identity management lifecycle. If Active Directory can be that point of consolidation for many of your business applications and systems, you can focus on provisioning and de-provisioning tasks into Active Directory. Thus, the task of de-provisioning a user from most of your internal and external systems and applications can become a simple matter of disabling a user account in Active Directory and just a few other places.
It’s not uncommon for identity to start off through an organization’s HR system. That system then pushes that identity out to other required identity stores, such as Active Directory or application-specific identity stores. It’s usually the job of a formal provisioning and de-provisioning system to perform these kinds of updates on the various connected systems—keeping identities in sync and removing them from all connected systems when the user leaves the organization.
Such solutions might have their own directory service where all this data from the connected systems is aggregated. This is often called a meta-directory. The solution may simply keep track of the mappings between connected systems, mapping key fields in one system to another.
The goal of such mapping is to find a field that uniquely identifies a user within all identity stores. That ensures John Smith within Active Directory is the same John Smith just hired by HR, and the same John Smith that has access to specific applications by virtue of the identities that the meta-directory stores. And, when John Smith leaves the organization, his user ID is disabled from the HR system, Active Directory, and the application-specific store in one operation.
It’s actually quite important to have a system in place for managing the identity lifecycle. There are real, on-the-ground reasons for building a system that keeps track of who exists in your organization and what they can access: reasons such as data loss, regulatory risks and business impact.
Data loss: Without a doubt, one of the scariest risks most businesses that deal with private information—such as customer data—face is the inadvertent loss of information. Any reasonably large organization today faces any number of possible avenues for data loss: from employees walking out with customer lists on USB keys to an executive getting his unencrypted laptop with sensitive financial information stolen from an airport lounge. Some of these scenarios are preventable with the proper tools and procedures in place, but by far one of the worst mistakes you can make is to lose data by virtue of someone having the wrong level of access or having access to systems that should’ve been removed long ago.
These scenarios are bad because they’re all preventable with a cohesive identity plan that focuses on ensuring good processes and good automation are in place every time a user enters, changes jobs, or leaves the organization. Data loss is especially bad in today’s Internet world because a company’s online reputation and its ability to keep or lose its customers’ data can have a direct and immediate impact on its bottom line and the level of trust it has with its customers.
How does having a good identity management plan in place help data loss? Simple—if you have good control over the users who are able to authenticate to your systems and good processes in place for granting access only to the data needed to do their jobs, the chances the wrong data will fall into the wrong hands are greatly reduced.
The most troubling part of this challenge is that the threat landscape is rapidly changing. A recent report on data breaches commissioned by Verizon shows that while external attacks against organizations are still a major vector for data loss, internal threats from both inadvertent mistakes due to poor system security as well as organized internal fraud efforts are a major concern.
In fact, in a nod toward having good identity controls in place, the Verizon survey shows that a vast majority of internal threats are perpetrated by “normal” users without privileged access. Thus, having good controls in place around access to data and systems can have a demonstrable impact on preventing data loss by internal users bent on malicious activities. These controls are only possible when you have a system that can provision and identify the correct users with the correct levels of access, such as when you have a provisioning system in place that identifies a user’s authorization levels based on his business function.
Regulatory risks: Along with the risk of data loss comes the attendant risks for organizations subject to governmental regulations. Regulations such as the Sarbanes-Oxley Act (SOX), Health Insurance Portability and Accountability Act (HIPAA), Payment Card Industry (PCI) and others have varying degrees of explicit prescription when it comes to methods for protecting customer and non-public data.
All these regulations mandate that such data must be protected. There are stiff fines and possible criminal ramifications for gross failure to protect such data. If your organization is subject to such regulations and you don’t have a solid plan in place to address the variety of risks around data breaches, you’re asking for trouble. In addition to other controls, putting a solid identity management plan in place can help you get better control over who’s accessing your systems.
Business impacts: In addition to data loss and compliance risks, good identity management results in better system availability and fewer business impacts. Identity management systems control access to not only business data and applications, but also systems. Putting a “least privilege” plan for system authorization in place through your identity management system such that only those administrators have access to server resources for which they are responsible will go a long way toward preventing unwanted server outages.
What you want to avoid at all costs is an administrator with privileges far greater than his role making a change to the wrong server at the wrong time and bringing down your business systems. There are countless anecdotes of administrators with Domain Admins access to Active Directory—which is essentially unfettered access to read and write most objects in Active Directory—accidentally deleting a critical application service account, or inadvertently moving objects from one organizational unit (OU) to the next.
This can cause different Group Policies to apply to OUs and subsequently change their behavior. Either of these examples might be enough to cause a major outage, just because someone didn’t follow policy when it came time to provision a user account and granted that user far more rights than he needed or was equipped to handle.
Group Policy is another area that’s ripe for having a good system in place for controlling who can access and make changes. Group Policy changes can have a vast impact on an organization. These types of changes benefit from ensuring the delegation model around Group Policy is tightly controlled. This usually involves ensuring the right users are in the right Active Directory groups that have the ability to modify Group Policy Objects.
The bottom line with all of these access issues is that having a good identity management system in place—with a standard process for provisioning and updating user accounts with their proper groups and other authorizations—helps ensure the right users have access to the right resources.
Keep in mind that “permissioning” resources to do the actual resource granting isn’t covered as part of the user provisioning process. It is, however, an important prerequisite for being able to properly leverage your identity provisioning process.
Darren Mar-Elia is a Microsoft Group Policy MVP, creator of the popular Group Policy site gpoguy.com and coauthor of “Microsoft Windows Group Policy Guide” (Microsoft Press, 2005). He’s also CTO and founder of SDM Software Inc.
For more on this and other Realtime Publishers titles, check out Realtime Publishers.