by 

Chapter 1 discussed how Active Directory (AD) has become a key player in many organizations’ identity landscape—controlling access to not only Windows desktops but also an increasing number of systems, applications, and sensitive corporate data. The chapter also talked about the importance of managing the identity lifecycle, as defined by creating, updating, auditing, and removing identities within both AD and related identity systems. This chapter digs into that identity lifecycle, identifying downsides of not getting a handle on your AD and drilling into each of the four phases of the identity lifecycle.

The Challenges and Importance of Managing the Identity Lifecycle

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 to resources. In a typical midsize-to-large organization, you might find the following sources of identity

• AD
• Other directory services
• HR systems
• Databases
• Custom LOB (LOB) applications
• Third-party software-as-a-service (SaaS) Web applications
• Local system accounts on Windows, Linux, and/or Unix

All of these identity stores present challenges. Each one requires its own provisioning event (and de-provisioning 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. AD Windows uses security groups, databases like Oracle use custom roles built-in to the database, and other LOB applications use yet different mechanisms. More recently, SaaS applications are becoming more prevalent, which means you’re now required to provision access to both internal and external applications.

It’s also important to not blur the lines between authentication and authorization. Some products—I’ll use my previous example of Oracle databases—are able to integrate into AD for authentication (for example, through Kerberos) but still keep their own authorization mechanisms that don’t directly leverage AD 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 that the right users are provisioned into your environment, and de-provisioned when the time comes. But it also increases the importance of having lifecycle management in place because it becomes a lot easier to “lose track” of identities if they are not all knitted together using a common framework. I’ve seen many an organization that 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.” I can remember personally being at a job for a number of years, then going back to do some work for them 5 years later, only to find 10 year-old Unix accounts that I had the first time I was still there floating around their systems. That kind of poor identity management is a recipe for unauthorized access, failed audits, or both.

Click here to download this chapter or book.

Tags: Active Directory