Welcome to my new column! In this space, I'll be exploring the range of technologies, concerns, and opportunities that identity professionals face today. This month, I want to talk about the evolution of enterprise identity management and cloud computing’s effect on it. Cloud computing—hot on the heels of virtualization—has shaken up the IT department. Unlike the move to virtualization (which at least initially remains within IT’s data centers), cloud computing solutions can allow IT’s traditional customers to perform an end run around established IT processes. Departments can buy Software as a Service (SaaS) applications such as Salesforce.com or Google Apps to provide capabilities that don’t require any capital expenditure, scale well, and have setup times measured in hours or days rather than weeks or months.
Cloud computing has also shaken up another aspect of IT: the IT professional’s career path. What kind of a future does the IT pro have if computing is evolving from on-premise data centers to massive but invisible data centers in the sky? There are a lot of aspects to this question, but I want to focus on a career path I’m most familiar with: the identity professional.
I’ve been working with Windows identity management in one form or another for many years, and I’ve watched it evolve over that time. For its entire existence, its scope of responsibility has grown—never shrunk—and I don’t think that will change in the near future. In the beginning, there was the standalone computer, which had only a local account database. If you wanted to access resources on another computer, you had to create an account on it. Workgroup computing, introduced with Windows for Workgroups (WFW) and carried forward to this day, has separate account databases on each system, but you can authorize a user on another system to access your resources.
LAN Manager in the early 1990s marked the transition of account management from PCs to servers. It was the first Microsoft networking product to have a single user-accounts database server that determined identity and access across multiple servers, and to authenticate clients to those server’s resources. It was a pretty cantankerous piece of software, put together from OS/2, MS-DOS, and 3Com’s 3+Share network server software. I remember going into the morning operations meeting at Texas Instruments, where we’d beat up the Microsoft team over the previous day’s outages.
In 1993, Microsoft developed what we OS geeks considered the real thing—Windows NT 3.1, a 32-bit pre-emptive, multiprocessing, multithreaded OS that was far more capable than its predecessors. With this leap in capability came the NT domain, a much more capable account-management system. Instead of a single account server, an NT domain had a primary domain controller (DC) and multiple backup DCs to ensure that the domain would keep functioning if the primary DC was offline.
NT domains were orders of magnitude more scalable than LAN Manager; they could hold several thousand user accounts and computers. Even better, you could configure an NT domain to hold only accounts (account domains) or only computers (resource domains) and string these together so that the computers in the resource domains used the accounts in the account domains to control access to their data. And you could string many of these domains together with trust relationships to handle many thousands of users and computers. This scenario spurred IT’s first attempts to wrangle user account management out of the hands of the departments and into a centrally managed organization. Manual account management is a thankless job, and departments in general were happy to hand the work to someone else. This got very complicated, though, as the number of account domains and their trusts multiplied dramatically. For example, Intel had 156 trusts between its account domains alone, and many hundreds more between them and the resource domains.
As the Windows network increased its scope to a significant segment of the enterprise, it began to show up on high-level management dashboards; for many companies, it became the primary network authentication mechanism. Even so, if you’d asked an NT administrator whether he or she was an identity manager, you’d have received a blank stare. But at this scale, much of an admin’s time was taken up with managing a user’s identity and access management across these many domains.
The biggest milestone in the history of the Windows Server OS, and its identity management, was the introduction of Windows 2000 and AD. Designed to scale to a level that still hasn’t seriously challenged its limits 10 years after it was introduced, a single AD forest of domains was first thought to be the only solution you'd ever need—one forest to rule them all! At Intel, through some very good negotiations, we managed to convince our various business units to do just this, leaving behind their NT 4.0 fiefdoms and moving to organization units (OUs) in a single corporate forest. Once again, this increased the scope of Windows identity management. Soon, however, many companies realized that Windows security depended not on domain boundaries but on forest boundaries, and multiple forests started popping up. Business needs often dictated that these forests needed to share some information, so inter-forest trusts were set up. As a result, some companies’ AD environment began looking like a scaled-up version of their NT 4.0 environment, with multiple AD forests taking the place of multiple NT domains.
As the scope of Windows identity management continued to grow, technical decision-makers and AD administrators began thinking about it in a larger context. Instead of thinking about identity from only within the Windows network (“How do we manage user accounts and passwords within our AD forests?”), they began viewing it as part of the enterprise (“How do we manage the employee’s identity information holistically across the entire company?”). Though by now our AD credentials controlled most of our access to the company’s computing infrastructure, there were still significant gaps—most notably, human resource databases and physical security systems. These databases contained sensitive and important aspects of an employee’s digital identity, but they were loosely coupled by manual batch jobs if they were linked at all. This caused serious security concerns—for example, in the employee-termination scenario: If all of a user’s accounts aren’t disabled immediately throughout all systems he or she has an account on, the terminated employee might be able to cause damage to a system that still contains the user's active account. Identity professionals began using metadirectory services such as Microsoft Identity Lifecycle Manager (ILM) and its successor Forefront Identity Manager (FIM) to take these disparate identity sources and link them in a metadirectory (literally, directory of directories) that provides a holistic view of everything associated with a user’s identity, and the ability to shape and control data flows between these identity sources. With a metadirectory service overseeing all the company’s identity sources, a termination action triggered in the HR database cascades into other systems, immediately locking out Windows accounts and any other systems the user had access to (e.g., disabling badge access to buildings). Implementing metadirectory services isn’t a trivial project, however: The software is costly, the learning curve is pretty steep, and the implementation is complex. As a result, only a relatively small percentage of AD professionals have added this technology to their skill set so far.
Now, we have cloud computing and its identity-management concerns to contend with. Cloud identity—the management of identity credentials between identity providers (e.g., your AD forest) and cloud service providers (e.g., Amazon’s Elastic Computer Cloud)—is the next step in this natural progression of growth for the identity professional. By default, the scope of your corporate identity system doesn’t extend to the cloud. The challenge is how to securely use your existing corporate identity for these services. We've all experienced the dizzying number of user accounts and passwords necessary for consumer websites; why should you, similarly, have to create and manage a separate set of accounts for every cloud service provider you use at work? Readying your company to work securely with cloud services is relatively cheap, though the technology and its jargon can be confusing.
Federation is the leading technology for stitching your identity system to the cloud service of your choice. It lets you securely provide just the relevant identity data the cloud application needs without exposing the entire identity system externally. Microsoft’s Active Directory Federation Services (AD FS) and Ping Identity’s PingFederate are examples of established federation products available today. Understanding federation and the claims-based authentication model it supports is the next step for the identity professional who wants to keep his or her skills current because we’re at the beginning of a growth curve for this technology. I’ll be covering cloud identity technologies such as federation in future columns.
Cloud computing isn’t going away, but that’s a good thing for identity pros. Despite worries about virtualizing and moving applications wholesale to the cloud, identity stores aren’t going anywhere in the foreseeable future. Basic security principles dictate that AD stays with you, on the premises. Cloud computing gives you a new challenge and skill set to acquire. The cloud isn’t a threat to identity professional’s careers but rather an opportunity.
If you have a topic you’d like to see discussed here, please drop me a line! This magazine is all about reflecting what’s on the mind of the IT professional. See you next month!
