Improving Identity Management in the Enterprise: Getting Started
See other Security MVP Article of the Month columns.
Identity management is a very sensitive topic. One incorrect decision may cause a lot of time, effort, and money to be spent in vain and yield a result that doesn’t work. Today we can learn from other people’s mistakes and failures. We have much better technology than we had 10 years ago. We know that there is no universal manager and that you need to take a step-by-step approach.
Be strategic but not too strategic
First, formulate your identity management strategy. You have many immediate problems and many solutions in mind, but you need to define your medium- to long-term target
However, don’t hesitate to think in technical terms right away. It might not be a popular approach to jump to a solution, but you will have to deal with a lot of existing technologies and different standards that you need to support. You need to be ready to explain exactly what your multifactor authentication is and how the solution will work well before you have chosen products and technologies that are parts of the solution.
Identify your identity domains
Enterprises have staff, customers, and associates/partners. People can be part either of one or all of these groups. This matters because different identity domains have very different requirements for things like user identification, support, and provisioning etc. They are likely using different directory services.
The reality is that the solutions, including technology and processes used for each identity domain, are going to be very different. For example, you might wish to implement distributed credential service model for staff, but still have centralized help desk for customers. Do not try to cover solutions for all identity domains with a single strategy -- use a different approach for each if needed. And you need to have a reasonable level of confidence in your solution for each identity domain before you start doing anything about identity federation across logical perimeters of your identity domains and the enterprise.
Identify both the issues that you’re trying to solve and the issues you won’t solve
It is important to define the issue space for each identity domain. In the enterprise, some of the issues that you’re trying to solve can include the following:
It takes too long to grant a new user access to the systems and even longer to revoke access.
System access credentials are shared between the users and are not secret.
Password reset help desk is too expensive, and it grows faster than the business.
Access to the systems and applications granted to an account is never revoked, and users accumulate unnecessary access as their careers progress.
Keystroke loggers are used to collect passwords.
No one can tell exactly how many Windows and Exchange administrators are in the organization.
On average, a user has to remember six passwords and carry two access cards and a one-time password generator token.
A server has failed and no one knows how to log on as the root.
Information security is all about risk management. Assess the risks and potential impact and act accordingly. Don’t underestimate the importance of small targets. If you can tackle a smaller issue quickly, do that. In some cases, business might be willing to accept a risk and not to pursue a solution. For example, personal assistants having the same access as their bosses (who in theory make decisions) and knowing their passwords is an example of conceptual conflict that you won’t solve with technology. However, make sure that the risks – and their acceptance and compensating controls – are documented for revisiting and possible reconsideration in the future. This is standard risk management practice.
Build the solution around the enterprise directory
One of the big questions: What is the authoritative source of identity information? In the enterprise identity domain, one might suggest that the human resources (HR) database is a good candidate for the role. But when you think about it, you don’t authenticate users against the HR database; you don’t provide authorizations to use systems and applications by querying the HR database; you don’t send e-mail messages to groups in the HR database or apply system configuration policies to them. To manage all those functions, you use the enterprise directory.
A record in the HR database is somewhat similar to the record about your birth in the state registry. As definitive as it could be, it is hardly ever used in your day-to-day transactions. The HR database, therefore, may be a trusted source of your identity information, but it isn’t an operational identity store.
A part of the problem is that an organization (especially a multinational) can have more than one HR database. And there is more than one directory service, such as Active Directory for your Windows infrastructure, /etc/passwd on every UNIX and Linux system, and an application-specific user database in the document management system.
Before thinking about implementing a meta-directory or a virtual directory, consider the features that are already available in the products that you use. For example, Active Directory in Windows Server 2003 provides distributed Kerberos authentication, LDAP interface, PKI infrastructure, and Authorization Manager for role-based control in the applications and, in Windows Server 2003 R2, Active Directory Federation Services (formerly known as TrustBridge). It provides a solid foundation for enterprise trust and identity-aware applications.
To minimize the number of operational identity stores, it is ideal to consolidate around a single enterprise directory. You may also need to create directory management procedures that are secure and auditable, and secure the link between HR systems and the enterprise directory.
Create reference application architectures incorporating identity management
One way to incorporate identity management is to stop introducing applications that are not aware of the enterprise identity -- for instance, having proprietary user stores and formalizing reference architectures for different categories of the applications utilizing different technologies. Design decisions could include the following:
Authorization Manager API will be used to implement role-based access control in .NET-based applications.
Kerberos authentication will be used in internal-facing Web-based applications running on UNIX and IBM iSeries; LDAP will be used subsequently to query group information and provide authorization.
For extranet Apache/Linux applications, smart cards and Windows PKI will be used for authentication, followed by authorization using LDAP.
Using a standards-based approach guarantees pluralism of products and technologies, as well as support for third-party applications without much customization.
Create a functional prototype
Make sure that you’re testing every product and technology (as well as the reference architectures) that may become a part of the solution. It may sound complicated, but for the prototype you don’t need much. The lab I use has Windows Server 2003 with Active Directory, IIS, Windows SharePoint Services, Microsoft Exchange Server and Live Communications Server, ISA Server, SQL Server, a Linux system running Apache and an Asterisk PBX, DSL connection to the Internet, wireless access points, and various client platforms -- from Windows XP to Windows Mobile-based Smartphones. The environment doesn’t take too long to build and rebuild (especially using Microsoft Virtual Server), and it allows me to quickly test technologies and solution components -- from SSL VPN appliances to single sign-on helpers. Remember that everything looks good on glossy paper, so never make decisions based on just that.
Information
A good starting point for information on Microsoft solutions for identity and access management is the Identity and Access Management Series, a comprehensive solution guide that contains everything from the architectural framework and fundamental concepts to application templates.
You can find a lot of useful and entertaining information in the blogosphere. I must mention Kim Cameron’s Identity Weblog. Kim is officially the champion of identity management and his website is a hub of the community process around the Laws of Identity and the Identity Metasystem.
One last thing to mention is that identity management is a process and not a goal. Don’t expect that you’ll be done and finished with it soon. Good luck!