This paper focuses on the business and IT challenges related to identity and access management and the approaches and technologies available for overcoming these challenges. It describes key concepts, terminology, typical initiatives, and the Microsoft products and technologies related to identity and access management.
Identity and access management has become more complex as digital identities take on an increasingly important role in specifying how users interact with computer networks. Organizations need to manage users efficiently and accurately while granting them access to network resources. However, organizations rarely store and use identity information in only one place. Multiple departments, countries and regions, business divisions, and software choices along with mergers and acquisitions result in the proliferation of directory services and application-specific identity stores — increasing costs and causing complicated security issues.
Developing a consistent and effective identity and access management strategy requires a sound understanding of the approaches and technologies you can use to address multiple digital identities. Organizations and IT departments need to implement both short term and strategic approaches to controlling identity.
Improving access to network resources and managing the identity life-cycle can provide significant dividends for organizations. Typical benefits include:
The intended audience for this paper includes architects, IT professionals, IT managers, and consultants involved in identity and access management efforts. The secondary audience is technical decision makers who want to make the business case for identity and access management investments.
This paper provides fundamental concepts for the Microsoft Identity and Access Management Series; the only prerequisite is to have a basic knowledge of the directory and security services used in heterogeneous computing environments.
This paper consists of seven chapters that explain fundamental digital identity and access management concepts and capabilities of the Microsoft platform. The chapters cover the following topics:
Chapter 1: Introduction
The introduction provides an executive summary, business challenges and benefits, the recommended audience for the paper, and an overview of each chapter in the paper.
Chapter 2: Terminology and Initiatives
This chapter reviews the key terms and strategic issues behind identity and access management. It discusses options for integrating digital identities, and the technical and organizational approaches to address these options.
Chapter 3: Microsoft Identity and Access Management Technologies
This chapter introduces the directory and security services of Microsoft® Windows Server™ 2003, Microsoft Windows XP, Microsoft Identity Integration Server 2003 Enterprise Edition with Service Pack 1 (MIIS 2003 SP1), Microsoft Passport, and other products related to identity and access management.
The remaining chapters discuss identity and access management scenarios and technologies in more detail and are intended for readers with a technical background.
Chapter 4: Directory Services
This chapter discusses how the Microsoft Active Directory® directory service and Active Directory Application Mode (ADAM) provide LDAP, X.500, and multi-master replication services to form the foundation of an effective identity and access management infrastructure.
Chapter 5: Identity Life-Cycle Management
This chapter reviews the approaches for managing users, credentials, and entitlements. It discusses techniques and technologies for enabling user self service, delegated administration, identity integration, and provisioning.
Chapter 6: Access Management
This chapter expands on several concepts and describes the technologies that support them, including:
Chapter 7: Applications
Organizations frequently need to develop applications in-house or purchase applications to operate line-of-business processes. These applications should integrate well with the chosen directory and security services of an organization. This chapter discusses how applications can integrate with the Microsoft identity and access management platform, and reviews the techniques available for developers creating custom applications.
Identity and access management combines processes, technologies, and policies to manage digital identities and specify how digital identities are used to access resources.
Identity and access management initiatives tend to be more complex than most other IT projects, simply because of the number and diversity of identity stores, protocols, encryption mechanisms, policies, and governing bodies that need to work together. A comprehensive strategy can significantly reduce the effort required to manage digital identities in a large network by implementing standards, reducing the number of identity stores, establishing trust, delegating administration, and improving the user sign on experience while strengthening security.
An organizational strategy for identity and access management needs to include well-defined answers to the following questions:
Your organization needs to have a clear idea of the specific benefits that improved identity and access management initiatives should bring. Without this guiding vision, the outcome will not deliver concrete improvements and will likely lead to a more complex and cumbersome system.
When you evaluate potential benefits, do not overlook the challenges of implementing a particular technology solution. There should be a balance between the expected benefits and the size and complexity of each solution.
The following terms describe components or processes within identity and access management. The remaining papers in this series use these terms and expand on them.
Recent advances in the area of distributed computing, especially through the Internet, have resulted in a proliferation of applications and other mechanisms for accessing information in a typical organization. At the same time, organizations want to provide secure access to information assets for employees, partners, and customers while continuing to grow, reducing access costs, strengthening security, and complying with regulatory requirements.
Secure access to information assets must be provided within increasingly complex IT environments. Custom or packaged applications often have their own authentication and authorization systems, as well as management tools for creating and managing user accounts that do not integrate with a comprehensive identity and access management platform. Such applications frequently result in unconnected islands of digital identity information and increased complexity.
Such complex and difficult-to-manage systems make it hard for IT to provide access to information assets and meet the business requirements of the organizations they service. A properly executed identity and access management infrastructure built on a solid identity and access management platform can help IT meet these business requirements.
If an organization does not implement well-designed, automated, and auditable mechanisms that enforce access control, a comprehensive access management policy will be expensive to implement and maintain. The following figures are taken from the PricewaterhouseCoopers/Meta Group Survey 2002 titled "The Value of Identity Management," which is available on the company's Web site at http://www.pwcglobal.com. These figures include primary examples of costs associated with managing digital identities.
Organizations that address identity and access management issues can significantly reduce TCO. Even small changes, such as reducing the number of calls to the Helpdesk for password resets, can produce large increases in productivity for end users and Helpdesk operators.
Security is not only a matter of whom or what you keep out; it is also about whom or what you choose to let in, and what level of access they are granted. Employees, contractors, customers, and business partners have varied needs for access to data and applications. It is crucial for organizations to define and implement an access management policy that allows only specifically authorized users to access sensitive information.
Security is also about effective operational management. Poor management processes covering the accounts that represent employees, partners, and customers can result in increased security risks. For example, managing accounts for millions of online customers can overload conventional user account management systems. Organizations also do not have the same knowledge and control over partner employees that they have over their own employee accounts.
Controlled identity and access management allows organizations to extend access to their information systems without compromising security. Organizations provide this extended access by precisely managing entitlements and modifying or terminating access rights promptly.
The following security activities are typically associated with identity and access management:
In order to improve access to information assets identity and access management technologies should meet the following requirements:
By addressing these key identity and access management requirements, organizations can achieve greater employee productivity, decrease costs, and improve business integration.
Identity has quickly become a focal point of many governmental and regulatory policies. This emphasis is a result of the growing focus on privacy, as more personal information is stored on information systems. Controlling access to customer and employee information is not just good business practice; an organization that fails in this area is open to significant financial and legal liability.
Data integrity or isolation compliance is now law. Organizations in the United States may need to meet the requirements of one or more of the following:
As an example of how these regulations affect organizations, the HIPAA Security Rule has strict guidelines on how healthcare organizations can handle personally identifiable health information. These guidelines include such areas as proper audit controls, access management, and authorization. An effective identity and access management infrastructure accurately associates patient records across different information systems with the correct patient. In addition, such an infrastructure audits access to records and authenticates the identities of the people reviewing them.
Organizations in the United States are not the only ones that face increased regulation, as demonstrated by statutes such as the European Union's Data Protection Directive of 1998 and Canada's Personal Information Protection and Electronic Documents Act (PIPEDA), both of which impose strict guidelines regarding identity information. There are also many local laws that dictate how identity-related data is stored and used.
Regulatory compliance ensures that organizations meet the applicable privacy, authentication, authorization, and auditing requirements mandated by any and all applicable regulations.
Integrating the identity and access management systems of an organization that has merged or acquired another organization presents unique challenges and opportunities. To maximize the value of the new organization, IT must use common standards to combine the data and information of the newly joined organizations and make it available to employees as soon as possible.
Integrating identity and access management systems is particularly important in order to provide all employees in the new organization with the proper level of access to consolidated data. In addition, redundant identity stores and management processes no longer required for the new organization must be consolidated to keep administration costs reasonable.
IT challenges during mergers and acquisitions include:
Every organization will have different business drivers for determining and implementing an identity and access management strategy. To ensure the greatest possible chance of success, strategy must align with business goals in order to drive business results. Project priorities should consider the following:
Each organization that contemplates an identity and access management strategy will have a unique combination of goals and priorities to consider. The following sections discuss some of the more common initiatives, each of which is made up of one or more business and technology projects, including:
Many written organizational security policies that involve people, process, and technology elements can be directly implemented in directory services, but others will be controlled by processes and specific systems that have the capability to enforce security policy. Organizational access policies could specify at a global level the business rules regarding access to specific or groups of applications. Such access policies are usually defined in terms of role, resource, operation, and restrictions.
Examples of security and access policies and the rules within them include:
The potential benefits of establishing security and access policies include:
The challenges of establishing security and access policies include:
Whether using Active Directory or an alternative, having a standard directory service is a primary enabler of identity and access management. However, organizations often find that more than one directory service is needed. Mergers, acquisitions, and application choices can introduce two, three, or more directory services in an organization. An effective identity and access management strategy consolidates these into the minimum number of identity stores that collectively become the standard directory services of the organization.
Directory services can enforce security policy standards, but organizations may find considerable differences in their internal operations. For example, a department may have come into existence because of an acquisition that includes a separate directory service and security policy that differs from the organization's existing directory service. Because security standards related to identity are often tightly integrated with directory services, they should be discussed together.
Establishing directory service and security standards is a necessary prerequisite for establishing application development and procurement standards, keeping management costs low, and extending access in a secure manner.
The potential benefits of establishing standard directory services and unified security standards include:
The challenges of establishing standard directory services and unified security standards are considerable, and can include:
The "Platform and Infrastructure" paper in this series provides more information on establishing directory service and security standards.
In many cases, it is not practical to migrate identity stores and applications to a standard directory service. However, it is often possible to reduce management costs and minimize lost productivity by integrating such systems to share their identity information and create and maintain the same entitlements through common policies.
Identity aggregation comprises this linking of multiple digital identities from a number of identity stores. Without identity aggregation there is no way to recognize that "Li, George Z." in the Human Resources (HR) system is the same person as "George Li" on the intranet and "G. Li" in the e-mail directory. Identity aggregation and synchronization allows your organization to create and maintain a digital identity in its entirety through identity integration services such as those provided by MIIS 2003 SP1.
The benefits of identity aggregation and synchronization include:
Specific challenges associated with aggregating multiple identity stores include:
The "Identity Aggregation and Synchronization" paper in this series provides more information on this topic.
Organizations want new employees and contractors to be productive as soon as possible. They cannot afford to have staff spend hours, days, or even weeks waiting to obtain access to applications.
Automated provisioning can take a new entry from one identity store and create corresponding entries in each of the managed identity stores. Deprovisioning works in reverse, noting a change in one store such as disabling an account and then propagating that change to other identity stores. Therefore, alteration of a value in a single field in one of the connected identity stores (such as changing an employee's status from "employee" to "former employee" in the HR system) can disable or delete a series of digital identities across multiple stores in minutes.
The benefits of automated provisioning and deprovisioning include:
The challenges of automated provisioning and deprovisioning include:
Group management enables automated provisioning and deprovisioning. Organizations typically use distribution groups to distribute e-mail, and they use security groups to group users with similar entitlements conveniently.
When employees join an organization, their user accounts should automatically join the distribution and security groups that those employees require to do their jobs. Additionally, organizations may create groups based on common attribute values, such as "All users in Kansas". Creating attribute-based groups manually is time-consuming and prone to error, so automatic group creation and assignment is a desirable component of identity and access management.
The benefits of automated group management include:
The challenges of automated group management include:
Beyond the aggregation and synchronization of identity data is the reduction of the number of identity stores in use. For example, if an organization has two applications that use Lightweight Directory Access Protocol (LDAP) for authentication and authorization then it might be possible to combine the separate LDAP identity stores into a single store.
Identity data might be synchronized and managed between identity stores through largely automated mechanisms. However, maintenance of these mechanisms and the exceptions that will almost certainly occur generate increased management overhead and an increased security attack surface.
The benefits of consolidating identity stores include:
The challenges of consolidating identity include:
Password management and synchronization takes the identity aggregation process a step further. Password management involves a number of areas, such as establishing and enforcing password policies and changing or resetting passwords. Password synchronization then propagates these password changes to all connected identity stores. For example, password management and synchronization can enable users to change their network logon passwords, SAP account credentials, e-mail credentials and extranet collaboration site passwords in one operation. Password synchronization enables grouping, with strong password policies on critical systems and weaker policies on others that cannot handle modern password strength standards.
The benefits of password management and synchronization include:
Password management and synchronization challenges include:
The "Password Management" paper in this series provides more information on this topic.
Cross platform interoperability scenarios vary enormously from organization to organization, as each has a unique combination of directory services, databases, applications and associated identity stores to integrate.
Interoperability and single sign on (SSO) methods include:
Interoperability and single sign on benefits include:
The challenges of interoperability and single sign on include:
The "Intranet Access Management" paper in this series provides more information on interoperability and intranet SSO.
There are many reasons for choosing to implement stronger authentication mechanisms. The initiative could be part of a general plan to strengthen the security of the organization's computing resources, it could be a response to a specific threat, or (in the worst case) it could be a response to a successful attack. Finally, it could be necessary to meet industry or regulatory standards in order to achieve non-repudiation or a similar ability.
The majority of organizations still use username and password combinations for authenticating to their applications and resources. Password-based authentication mechanisms can range from very secure to very insecure, depending on the implementation of the application, protocol, identity store, and the length and complexity of the password.
More secure non-password based mechanisms and technologies are widely available today, such as X.509 digital certificates, time-based hardware tokens also known as one time password (OTP) devices, or secondary confirmation using biometric authentication.
Combining different authentication mechanisms (or factors) to create multi-factor authentication creates the highest level of security. For example, combining an X.509 digital certificate on a smart card (something you have) with a PIN (something you know) that unlocks the private key associated with the certificate creates a very strong credential, in turn providing strong authentication.
The benefits of strengthening authentication mechanisms include:
The challenges involved in strengthening authentication mechanisms include:
Many organizations want to optimize their information systems for competitive advantage by broadening access to include more types of users, applications, and networks. This approach is often referred to as "expanding the perimeter of the network" because firewalls around the organization's network no longer provide a single barrier to keep external users out.
For example, customer access to information and applications enables new business opportunities. Business partners simplify supply chains by integrating inventory, shipping, financial, and product development systems, enabling them to share confidential pricing, product, and support information. Employees have more opportunities to collaborate and communicate remotely as they work closely with customers and partners.
The main benefits of improving access include the following:
The challenges in improving access for external users are considerable, and include:
The "Extranet Access Management" paper in this series discusses the concepts of providing employees, customers, and partners with secure access to internal applications while providing a single sign on experience.
A typical organization has security policies that require auditing at both the platform and application level. One of the biggest benefits of implementing some of the identity and access management initiatives described in this chapter is the consolidation of identity stores, platforms, and authentication and authorization mechanisms. This consolidation makes auditing easier and more reliable because the number of places and the manner in which security events are generated is reduced.
The next step is for the organization to detail what types of auditing are required and how audit information is captured, stored, and used.
The benefits of establishing a security auditing policy include:
The challenges of establishing a security auditing policy include:
Applications are often the root cause of complex identity and access management systems. Applications typically introduce different kinds of identity stores, different authentication mechanisms, and authorization policies. Once you have standardized directory service, security, and access policies, it is important to establish or update organizational standards for software procurement so that new software integrates well with your organization's other systems.
Selecting software from independent software vendors (ISVs) should be based in part on the ability to integrate with your selected directory services and their ability to meet the established security and access policies.
The benefits of updating software procurement standards include:
The challenges of updating software procurement standards include:
As an organization's business needs evolve, it needs new applications to implement new business functionality. Setting and enforcing development standards that describe how applications interact with the identity and access management infrastructure sets the stage for lower TCO and improved security.
The benefits of establishing software development standards for identity use include:
The challenges of establishing software development standards include:
Once an organization has established standards for application development, new applications can be developed through use of the standards. Existing applications should also have the same level of integration with the identity and access management infrastructure.
To do this, take an inventory and categorize existing applications. Consider the value of each application, the information they provide, and their security characteristics to determine relative importance. Balance these with the cost of migrating or changing each application to prioritize which applications should be migrated first.
The benefits of developing and migrating identity-aware applications include:
The challenges of developing and migrating identity-aware applications include the following:
The "Developing Identity-Aware ASP.NET Applications" paper in this series discusses the necessary techniques for building applications that integrate with the Microsoft Identity and Access Management Platform.
Effective identity and access management involves several interdependent technologies and processes. These elements combine to maintain a unified view of identities in an organization and use them effectively. The main topics for discussion in identity and access management include directory services, identity life-cycle management, access management, and how applications should integrate with the infrastructure.
Note This chapter provides an overview of each of these topics and the remaining chapters examine the processes and services within each topic in much more detail. For an overview of these topics, read this chapter. For a more rigorous, technical treatment, read Chapters 4 through 7.
Many identity and access management technologies and solutions have evolved independently in response to specific tactical problems. Organizations, analysts, vendors, and systems integrators have increasingly come to recognize that these technologies and business problems are all interdependent, resulting in a single category that is simply described as "identity and access management."
To visualize this interdependency, Microsoft created the Identity and Access Management Framework, a graphical depiction of the services and processes involved in identity and access management.
The following figure shows the main components of the Microsoft Identity and Access Management Framework:
Figure 3.1. Main topics of the Identity and Access Management Framework
This chapter establishes each of these framework topics and introduces the technologies, services, and processes that support each of them.
Pervasive elements of the Microsoft Identity and Access Management Framework include the governing business, security, and privacy policies that embody the specific requirements of an organization. These elements help define the business assumptions, rules, standards, and constraints that control how technologies and processes should be applied to meet business objectives. For example, security policies are broad and far-reaching, influencing all aspects of identity and access management.
Directory services provide the foundation of any identity and access management infrastructure. Directory services provide a single source of authoritative digital identity information. Such information can include security information, such as passwords and X.509 certificate mappings, as well as user profile information in the form of user attributes that include addresses, telephone numbers, office space, titles, and department names.
Microsoft recommends identifying a minimal number of directories that become the trusted digital identity store(s) for your organization. This reduction offers immediate returns and provides a solid base on which to integrate all other components.
Microsoft started supporting directory services on the Microsoft® Windows® platform when Windows NT® 3.1 was introduced. Current directory services from Microsoft include:
For more information on Microsoft directory services, see Chapter 4, "Directory Services," later in this paper.
There are several related processes for managing users, their entitlements, and their credentials. These processes include:
Identity integration services are typically needed when an organization has multiple directories or identity stores. Since each of these directories contains a subset of all the information about a user, identity integration services can help by creating an aggregate view of the information from all the identity stores.
Identity integration services create this aggregate view by pulling identity information from a variety of authoritative sources, such as existing directories, Human Resources (HR) and accounting applications, e-mail directories, and various databases. All the identity information that the identity integration services bring together populates a single database or metaverse — a single global, integrated view of all combined objects aggregated from identity information in multiple connected data sources.
With this central database of information, rules can be applied to the data that control the flow during import and export operations. The ability to have rule-based import and export data flows allows for the implementation of identity synchronization and even provisioning. Since this synchronization and provisioning can be automated through programmatic rules, identity integration services allow the organization to reduce costs associated with the management of identity data and limit errors introduced by human administration.
A key component of identity and access management is how digital identities are created. The provisioning process provides a powerful tool that takes advantage of user information contained in the organization's directory infrastructure to speed up the granting and revoking of user accounts and entitlements for information resources. These resources can include e-mail, telephone service, HR applications, line-of-business (LOB) and functional applications, intranet and extranet access, and Helpdesk services.
Automating the processes that create digital identities can reduce costs and increase productivity dramatically. For example, when a new employee joins the organization, the provisioning system can reduce the time required to obtain user accounts and access rights from over a week to a few hours. Automated provisioning also eliminates much of the time managers spend processing associated paperwork, as well as the time that finance, human resources, and IT personnel spend approving and implementing the requests.
Workflow is a requirement of most provisioning processes. Requests for resources are entered online, routed in a predetermined path to reviewers and approvers, and then finally to the person or system that creates the user account. Requests and electronic copies of supporting materials are automatically routed to each participant in the process. Processes are applied consistently and completely across all departments, with each piece of information entered only once. A complete audit trail is available regarding who granted approval and when it was granted. Automatically monitored workflows notify a higher-level manager or administrator if review or approval actions are not completed in a timely fashion.
Workflow is also helpful within some delegated administration and self-service processes — for example, routing requests for approval.
The typical administration model involves a small group of trusted individuals who have the ability to manage all aspects of an identity store. These administrators create and delete users, set and reset passwords, and can set all user attributes.
However, there are often good business reasons for not having a single central group of administrators manage all aspects of user identity. In the case of partner accounts in an extranet directory, the preferred method is for the owning organization to delegate administration of the accounts to an administrator in the partner organization. The partner administrator assumes responsibility for all of the accounts for their own employees. This arrangement makes sense from an administrative standpoint, since the partner has a better idea of when users need to be created or deleted and requests for assistance are processed locally.
Delegated administration can also occur within an organization, where trusted individuals within different departments manage a subset of an organization's identity store.
For typical users such as employees, there are many user attributes that are not security related; an organization may consider allowing users to modify such attributes. For example, users may be allowed to change their cell phone number. However, self-service administration should have suitable constraints, such as enforcing naming conventions and validity checking.
Since credentials are the "keys" to authentication and authorization, they have special management needs and should have strict security considerations for all related processes. Credentials need to be provisioned, they need to be administered (such as revoking a certificate or resetting a password), and users need self-service capabilities (such as changing their passwords). The mechanism for receiving a credential should be closely scrutinized (for example, receiving a smart card in person by showing identification, or receiving a reset password through an encrypted, direct channel).
Password management is a specific subset of credential management. Authentication using username and password combinations is still the most widely used technique in today's networks and applications. Different techniques are available for managing password information across heterogeneous environments.
One aspect of password management covers the use of technologies to propagate password information automatically from one system to another. This propagation allows a user to use the same password to log on to multiple systems, which can reduce the possibility of forgotten passwords and the associated Helpdesk calls that forgotten passwords generate. With consistent passwords between platforms and applications, there is typically a requirement to centralize password change and Helpdesk password reset operations through common interfaces.
Password propagation should only be considered once the security characteristics of each participating system are fully understood. For example, a UNIX environment that uses Telnet and sends passwords in plaintext over the network should not have the same password as an Active Directory account used to complete sensitive, business-critical transactions.
Deprovisioning is another key function of identity life-cycle management. Deprovisioning ensures that accounts are systematically disabled or deleted and entitlements are revoked when employees leave the organization. Good security practice recommends that accounts be disabled quickly (to prevent possible attacks by disgruntled ex-employees) but not deleted until after a suitable time has elapsed, in case it becomes necessary to re-enable (or rename and reassign) the account. Disabling accounts (rather than deleting) is also helpful for some organizations that need to ensure certain identity attributes such as account name are unique and not reused within a period that meets policy requirements.
Group management includes automatic and manual assignment of user accounts to and from groups, as well as removal of accounts from groups. Typically, groups exist in directory services or e-mail systems, such as Active Directory or Lotus Notes. Groups fit into one of two types: security groups and distribution groups. Security groups can be used to configure entitlements, whereas distribution lists organize e-mail recipients. User accounts receive the rights and permissions of any groups to which they belong.
Organizations may want to implement query-based groups, where group membership depends on the value of a selected attribute in the directory service. This facility enables the identity and access management system to generate groups that contain all users in a particular city or office, for example. Groups are only created for unique values of each city or office. If a group no longer has any members, the group is deleted. These group names and memberships then propagate to all connected directory services and e-mail systems.
Microsoft technologies for identity life-cycle management include:
For more information on identity life-cycle management with Microsoft technologies, see Chapter 5, "Identity Life-Cycle Management," later in this paper.
Access management involves controlling user access to resources, whether using authentication to identify a user, credential mapping to relate digital identities to each other, or authorization to check user identity against resource permissions. Additional access management topics discuss implementing federation and trusts to extend access, and auditing to track and record what users are doing.
Authentication is the process of proving the digital identity of a user or object to a network, application, or resource. Once authenticated, users can access resources based on their entitlements through the process of authorization.
Authentication techniques range from a simple logon based on user identification and password information (something you know), biometrics (something distinguishing about you), to more powerful security mechanisms such as tokens, digital certificates, and smart cards (something you have). High security environments may require a multi-factor authentication process. For example, combining something you know (such as a password) with either a distinguishing feature (such as a fingerprint) or something you have (like a smart card).
In an e-business environment, users may access multiple applications spanning many Web servers within a single site or across multiple sites. Effective identity and access management strategies deploy authentication services to simplify the user experience and reduce administration overhead. For these reasons, authentication services must support heterogeneous environments.
Examples of authentication techniques include:
Authentication techniques can range from simple ones where users provide passwords directly to applications or hosts to much more complicated ones that use advanced cryptographic mechanisms to protect user credentials against potentially malicious applications and hosts.
Providing a plaintext password (that is, one that is not encrypted in any way) to an application or host is considered the weakest authentication technique because of the danger of interception of the authentication sequence. Also, if the user authenticates to a malicious host, the owner of that host has all the necessary information to act as that user anywhere on the network. If you think of a password as a secret, then it is not much of a secret if the user must tell every computer on the network what the secret is.
Stronger authentication techniques protect the authentication credentials so that the host or resource to which the user authenticates does not know what the secret actually is. Typically, this is done by cryptographically signing data with the secret password that is known only to the user and a trusted third party (such as an Active Directory domain controller). A computer authenticates the user by presenting the signed data to the trusted third party. The third party then compares the signature to what it knows about the user and advises the computer whether it believes the user is who they say they are. Such a mechanism helps keep passwords as true secrets.
An important part of any authentication discussion is the concept of single sign on (SSO). SSO at the application level involves establishing a "session" between the client and server that allows the user to keep using the application without providing a password every time they take an action within the application.
The same kind of idea can be extended to a set of applications available on the network. To implement SSO amongst different applications, sessions can be established between the client, a trusted third party on the network, and various server applications and network resources. The session is represented in many implementations by a ticket or cookie which is best thought of as a substitute credential for the user. Instead of requiring the user to provide their credential during authentication, the ticket or cookie is sent to the server and accepted as proof of the user's identity.
The end result is that the user only has to sign on once before using many applications — thus providing a single sign on experience.
Note Only in very unusual circumstances is it considered appropriate for an authentication mechanism to force the user to repeatedly provide authentication credentials. Applications, on the other hand, may sometimes prompt for credentials before performing a particularly sensitive operation.
Microsoft Windows Server 2003 Active Directory provides integral support for a range of authentication methods, including:
Windows Server 2003 Internet Information Services 6.0 (IIS) supports all of the above in addition to the following:
Applications can call authentication methods through application programming interfaces (APIs) such as the Security Support Provider Interface (SSPI), which includes Secure Protocol Negotiation (SPNEGO).
Windows XP includes integrated authentication for workstation log on and resource access, Internet Explorer for integrated authentication to Web sites, and Credential Manager for managing the passwords, digital certificates, and Passports used for authentication.
Authorization is the process of determining whether a digital identity is allowed to perform a requested action. Authorization occurs after authentication, and maps attributes associated with the digital identity (such as group memberships) to access permissions on resources to identify which resources the digital identity can access.
Different platforms use different mechanisms for storing authorization information. The most common authorization mechanism is known as an access control list (ACL), which is a list of digital identities along with a set of actions that they may perform on the resource (also known as permissions).
Actions are typically defined relative to the type of object the ACL protects. For example, a printer might allow actions such as "print" or "delete job" while a file might allow actions such as "read" and "write."
Operating systems that support large numbers of users typically support security groups, which constitute a special type of digital identity. Using security groups reduces the management complexity of dealing with thousands of users in a large network.
Security groups simplify management because an ACL can have a few entries specifying which groups have a specific level of access to an object. With careful group design, the ACL should be relatively static. You can easily change authorization policy for many objects at a time by manipulating the members of a group maintained by a centralized authority, such as a directory. Nesting groups within each other increases the flexibility of the group model for managing authorization.
Many applications use the term role to refer to a user classification. For example, a "Manager" role could be used to refer to all members of a security group called "Finance Managers," who as members of this group would automatically be granted the entitlements to network resources this role provides.
Roles can also be based on dynamic, run-time decisions that provide more flexibility, such as authorization in an expense report application. This application may have approval actions that only authorized users (or principals) can validate in the "Approving Manager" role. However, before granting approval to authorize an expense, the system queries the directory to determine if the submitter's "Manager" attribute matches the name of the person approving the expense. Such business-driven logic is almost impossible to configure with ACL-type mechanisms.
Roles can be defined either globally, such as by group memberships in a directory, or with application code that determines role membership based on a dynamic query. There are even combinations of both types, such as an application that defines a role called "Managers" that is locally defined to include both the global group's "HR Managers" and "Engineering Managers" roles.
There are advantages to each of these methods. A well-designed roles mechanism provides application developers with the flexibility to choose among them for the correct fit.
Windows Server 2003 provides integral support for a range of authorization methods. Microsoft authorization technologies and supporting components include:
For more information on Microsoft authorization technologies, see the "Authorization" section in Chapter 6, "Access Management" later in this paper.
The concept of trust is becoming more important as organizations continue to share resources with their business partners. The ability to establish trust between independently administered systems is crucial for IT systems to support the required level of data exchange. Trust enables secure authentication and authorization of digital identities between autonomous information systems with less management overhead.
The mechanisms of trust are complicated because there are many tasks that must happen between independent organizations to make the authentication and subsequent authorization processes useful. The trusting organization needs to have a secure mechanism to communicate with the trusted organization. Once the trusting organization has authenticated the foreign digital identity, it must incorporate the entitlement information about that foreign account into the authorization process within the trusting organization.
A federation is a special kind of trust relationship established beyond internal network boundaries between distinct organizations. Federation enables the secure authentication and authorization of digital identities between autonomous information systems based on the principle of trust. For example, a user from company A can use information available at company B because there is a federated trust relationship between the two companies.
Note Federation includes the implementation of evolving specifications, such as WS-Federation, an initiative headed by Microsoft and IBM for standardizing the way companies share user and machine identities among disparate authentication and authorization systems spread across organizational boundaries. For more information on WS-Federation, see Web Services Federation Language.
Federation is an attempt to remove the requirement for management of accounts in more then one place. In federation, a user from one organization can authenticate directly to a resource managed by another organization using his or her normal network account. This idea is popular because it can remove the requirement (or at least make the requirements much easier to meet) for administration of many different accounts.
Consider an organization that does business with one hundred different partners. The alternative to federation would be for the organization to use a delegated administration interface to manage accounts on one hundred different partner extranets. Through this example, it should be obvious that techniques such as delegated administration do not scale to highly connected business environments. The ability to federate digital identities reliably and securely is essential for advancing business opportunities.
Microsoft Windows provides support for trust and federation through the following technologies:
Auditing provides a means to monitor access management events and changes to directory objects. Security auditing is typically used to monitor for the occurrence of problems and security breaches.
Microsoft Windows provides a security event log for recording interesting security events such as:
Microsoft Operations Manager (MOM) 2005 SP1 can consolidate event logs in an environment and provide useful auditing reports.
General purpose business applications are the ultimate consumers of identity and access information. Accordingly, they should be integrated with the identity and access management platform. Applications typically integrate with the authentication and authorization components of the framework through APIs. Applications that fail to integrate add complexity to the environment, increasing management costs and often creating new attack surfaces, which in turn lead to security vulnerabilities.
Integrating applications may require a large amount of effort, but this integration process can deliver a high return on investment (ROI). If an application has its own authentication system, the only way an organization can fully integrate the application into the authentication process is to redesign it to work with the platform. Therefore, to ensure application compatibility with the identity and access management framework, the organization's Software Development Life Cycle (SDLC) methodology must include clear standards on how applications must use the authentication and authorization functionality of the standard platform.
For more information on application integration using Microsoft technologies, see Chapter 7, "Applications" later in this paper.
The following figure lists all of the processes and services in the Microsoft Identity and Access Management Framework.
Figure 3.2. Processes and services in the Microsoft Identity and Access Management Framework
Directory services are central components in any identity and access management strategy for several reasons, most importantly because directory services are the most common way of storing identity and authentication information for server operating systems.
A directory service doesn't just store user information. It also stores identity information about resources, computers, and applications, since security policies must also apply to these assets. Integrating identity with authentication and authorization capabilities enables the directory to manage both logon authentication and authorization to resources.
The Microsoft® Active Directory® directory service is a secure, highly available, distributed central identity store that is tightly integrated with Windows 2000 Server and Windows Server™ 2003. Active Directory serves as the focal point for managing and administrating user accounts, authentication, security policies, and organizational resources such as computers, printers, and servers.
Unique to Active Directory is its capability to manage user identity and control user access to varied resources across multiple systems and platforms. This capability enables an organization to use Active Directory as the authoritative store for identity, authentication, and authorization information that can be extended to other applications, systems, and platforms.
Using Active Directory as the directory service for user identities allows your organization to take advantage of industry-leading capabilities to manage user access rights. This integration solves the following key identity and access management challenges that were previously identified:
You can use Group Policies in Windows Server 2003 and Windows 2000 Server to define and enforce user and computer configurations for groups of users and computers. With Group Policy, your organization can specify policy settings for the following:
Group policies provide organization-wide control of policy settings, helping to improve security while reducing administrative effort and support costs.
For more information on Group Policy in Windows 2000 Server as well as Windows Server 2003, see the Group Policy Overview topic in Windows Help and Step-by-Step Guide to Understanding the Group Policy Feature Set page on Microsoft TechNet.
Directory Services Markup Language (DSML) provides a means of representing directory structural information and directory operations as an XML document. DSML is intended to allow XML-based enterprise applications to use profile and resource information from a directory in their native environment. DSML allows XML and directories to work together and provides a common ground for all XML-based applications to make better use of directories.
DSML Services for Windows extends the power of the Active Directory service on the Windows Server 2003 operating system. Because DSML Services for Windows uses open standards such as HTTP, XML, and the Simple Object Access Protocol (SOAP), a greater level of interoperability is possible. For example, in addition to the already standard Lightweight Directory Access Protocol (LDAP), many devices and other platforms have alternatives for communicating with Active Directory. This approach provides a number of key benefits for IT administrators and independent software vendors (ISVs), who now have even more open-standard choices to access Active Directory.
DSML Services for Windows supports DSML version 2 (DSMLv2), a standard approved by the Organization for the Advancement of Structural Information Standards (OASIS) and backed by many directory services vendors. Supporting the DSMLv2 specification allows better interoperability with other directory services vendors who are also supporting this standard. For information about the DSMLv2 specification and schema, see the OASIS Web site.
To obtain DSML Services for Windows, see the Windows Server 2003 Feature Packs download page on Microsoft.com.
A network directory such as Active Directory is the proper place to store relatively static, globally applicable data. When an organization or developer needs to store identity-related information that is application specific or requires local control of their data, they can benefit from a new mode of Active Directory called Active Directory Application Mode (ADAM).
ADAM solves many of the issues that result when deploying applications that need the structure of a directory but are not well-suited for the Active Directory environment because of one or more of the following requirements:
For more information on ADAM in these scenarios, see the "Intranet Access Management" paper in this series. You can learn more about ADAM and download it from the Windows Server 2003 Active Directory Application Mode page.
Most organizations have to cope with multiple identity stores. As soon as a network environment has more than one location to store digital identities, the problem of how to manage multiple identities emerges.
Identity life-cycle management includes the process and technologies for provisioning, deprovisioning, managing, and synchronizing digital identities while complying with governing policies. The success of identity and access management will rely mostly on how efficiently the digital identity life cycle can be managed.
Identity life-cycle management services provide for security principal creation, attribute management, synchronization, aggregation, and deletion. In addition, you must accomplish these actions securely with a thorough audit trail. This section describes how Microsoft products meet these requirements.
Identity integration (IdI) services link identity information in multiple directories, databases, and other identity stores. They provide a unified view of users, and can implement identity provisioning and deprovisioning across multiple stores.
Microsoft offers two related applications for identity integration that are discussed in this section. The products are:
MIIS 2003 SP1 augments the Microsoft Active Directory® directory service by providing broad interoperability capabilities that include:
The Identity Integration Feature Pack 1a for Microsoft Windows Server Active Directory is a reduced feature set version of MIIS 2003 SP1 that is available as a free download. The feature pack provides the ability to integrate identity information between Active Directory, ADAM, and Exchange 2000/2003 global address lists. Download the feature pack from the Identity Integration Feature Pack 1a for Microsoft Windows Server Active Directory page on the Microsoft Download Center Web site.
Microsoft also offers products that enable integration with specific platforms. These products enable you to integrate non-Microsoft operating systems into a Windows environment, and may be useful for a few scenarios that MIIS 2003 SP1 does not fully support or if you only need to integrate with one other platform.
These other integration products include:
The central problem of managing digital identity life cycles is ensuring that you can add and remove security principals in the centralized identity store that Active Directory maintains, as well as other identity stores for applications that are not fully integrated with Active Directory. This scenario is commonly referred to as a "hire/fire" scenario.
Provisioning often needs to tie in with the organization's operational procedures. For example, when hiring a new employee, that employee's manager might need to approve the provisioning process. There are three main ways of adding workflow to the provisioning mechanism.
Chapter 6, "Access Management," describes how you can use shadow accounts as an alternative to creating a trust between two otherwise untrusting realms. In order to maintain this mechanism and make it robust, it is best to automate the creation and removal of shadow accounts between different realms. MIIS 2003 SP1 is an excellent tool for shadow account provisioning and synchronization.
Identity life-cycle management includes delegating the ability to manage certain aspects of the digital identity maintained in Active Directory. You can achieve this using the built-in precise access control in Active Directory through a choice of interfaces. If the schema has a properly configured authorization policy for Active Directory object access control lists (ACL), the Microsoft Management Console (MMC) snap-ins provide a way to delegate management of any object in Active Directory, including the user accounts that represent digital identities.
Another popular management interface choice is to create an Active Directory-integrated Web application that provides account and attribute management. Microsoft partners that specialize in access management typically include this functionality in their products.
For more information on the delegated administration capabilities of Active Directory, see "Design Considerations for Delegation of Administration in Active Directory" on Microsoft TechNet.
The ability for regular users to manage some subset of their directory attributes is a key factor in reducing identity management costs. Microsoft products support this capability indirectly through detailed authorization to the attribute level in Active Directory. Many Microsoft customers have developed their own interfaces, typically Web pages, for self-service attribute modification using Visual Studio.NET. For those customers who wish to purchase an existing product, Microsoft partners provide easy-to-use Web interfaces that allow users to self-manage certain attribute information.
Different authentication mechanisms often have different credentials (such as x.509 certificates, Kerberos authentication protocol passwords, and Microsoft Passport passwords), so any platform that supports multiple authentication mechanisms should have the capability for users to manage their multiple credentials. In Windows, this feature is called Windows Credential Manager.
Windows Credential Manager provides end users with the ability to cache credentials and associate them with specific locations. For example, you can use different Microsoft Passport accounts with different Web sites, and you can identity different certificates for use with different Web applications.
Many environments include systems and applications that cannot be readily integrated with the security features in Windows Server 2003 and Active Directory. These systems typically rely on different authentication protocols, or use a separate identity store for authentication.
However, many of these systems use passwords for authentication. It is possible to achieve a better user experience (although possibly also increasing the attack surface) through provisioning and synchronizing accounts and managing credentials (passwords) used for logon to Active Directory with accounts and passwords used in the other systems. Microsoft products that perform password management include:
You can manage accounts and passwords with other systems, especially other directory systems and identity store databases, through MIIS 2003 SP1. The product ships with connectors that integrate with the most common directories and databases, making it simple to deploy a password management mechanism. MIIS 2003 SP1 supports password management in the following ways:
Whatever password management system you employ, you will only benefit from it if it is easy to use and your users understand how to access it.
Access management consists of the processes and technologies for controlling and monitoring access to resources consistent with governing policies. Access management includes:
In the Microsoft Identity and Access Management platform, the Microsoft® Active Directory® directory service is the recommended technology for storing identity information, including the cryptographic keys that validate user credentials during the authentication process.
Applications integrated with Microsoft Windows Server™ 2003, Microsoft Windows® XP Professional, and Windows Security Services use the built-in features of the operating system to perform authentication.
Implementing authentication protocols on an application-by-application basis is very inefficient and will likely introduce security flaws across the organization. A better approach is to build applications using the authentication mechanisms in the Windows platform.
For best results, developers need to understand the different authentication types and the ramifications of using different protocols and the interfaces they support before starting the application design process.
Windows Server 2003 and Microsoft Windows XP implement a complete set of authentication methods and security protocols that satisfy many application authentication requirements. Microsoft .NET Passport, public key authentication through certificates or smart cards, and username/password combinations all provide different user experiences due to different credential requirements, and each has different security characteristics. The data transport mechanism can also define which authentication protocols you can use.
The security system for the authentication services in the Microsoft Identity and Access Management platform is layered: It extends from lower-level interfaces that offer greater flexibility and control to higher-level interfaces with less flexibility but simpler application programming interfaces (API). The following figure shows how authentication protocols and application APIs are layered.
Figure 6.1. The authentication API and protocol hierarchy in the Windows operating system
At the top of the authentication stack in the previous figure, high-level APIs and services provide inter-process communication (IPC) mechanisms that offer a secure, authenticated channel for transmitting application data. Examples of such services and APIs include Distributed Component Object Model (DCOM), remote procedure calls (RPC), Microsoft ASP.NET, ASP, WinInet, and others.
Microsoft RPC is a powerful, efficient, and secure IPC mechanism that enables data exchange and invocation of functionality that resides in a different process. This process can be on the same machine, on the local area network, or across the Internet.
WinInet is an application protocol interface that is designed to support Internet security protocols such as Secure Sockets Layer (SSL) over Internet protocols. The implementation of WinInet security support uses the Security Support Provider Interface (SSPI) to the Secure Channel (Windows NT® implementation of SSL) security provider.
In some cases, the APIs that these services expose give the application developer complete control over how authentication is performed and data is protected. For example, DCOM APIs allow the developer to select a specific authentication protocol such as the Kerberos protocol or NT LAN Manager (NTLM) challenge/response. It also specifies whether data should be signed (protecting against an attacker changing the data) or encrypted (protecting against an eavesdropper viewing the data). Other services and APIs are only affected by system configuration. ASP.NET, which best exemplifies this, is hosted on a server running Microsoft Internet Information Services (IIS) 6.0, which can be configured to use the appropriate authentication mechanism for a given scenario.
The lowest level application interface for authentication is SSPI, which is the Microsoft version of the Generic Security Service API (GSS-API). For more information about the GSS-API, see RFC 1508 and 1509 on the Internet Engineering Task Force (ITEF) Request for Comments Web site.
For more information on SSPI, see The Security Support Provider Interface Revisited article on the MSDN Web site.
The idea behind SSPI and GSS-API is that network authentication between two parties generally follows a common pattern. The parties need to exchange one or more pieces of information in an ordered sequence. Since they may be communicating through one of numerous different network protocols — Hypertext Transfer Protocol (HTTP), RPC, server message block (SMB), Internet Inter-ORB Protocol (IIOP), DCOM, Java Remote Method Invocation (RMI), and so on — it is wise not to hardcode a single authentication handshake into the network protocol itself. It is better simply to provide a generic interface that produces "authentication tokens," which are really just binary data constructs that represent some aspect of an authentication sequence. These tokens are exchanged through whatever application protocol is in use.
For instance, in RPC, a handshake is already used to synchronize the protocols between the client and server. RPC simply provides space in this handshake for opaque, arbitrarily sized authentication tokens. A large part of the job that SSPI and the GSS-API perform is generating and evaluating these tokens.
As mentioned previously, Windows Server and client operating systems implement a wide variety of authentication protocols. These protocols are "security packages" (sometimes referred to as authentication packages) consisting of DLLs loaded by the Local Security Authority Service. SSPI is the interface to all security packages that ship with the Windows Server and client operating systems. These security packages typically implement a network authentication protocol such as the Kerberos version 5 authentication protocol, NTLM challenge/response, Digest authentication, Secure Sockets Layer (SSL), or Transport Layer Security (TLS). Applications can use these protocols to securely and seamlessly integrate with Active Directory for authentication, and in addition use the protocols' capabilities to secure application data.
Secure Protocol Negotiation (SPNEGO) is a special kind of security package that negotiates between authentication protocols as required. The best practice for applications using SSPI and either the Kerberos version 5 protocol or NTLM is to use the SPNEGO package instead of these protocols directly.
The Kerberos version 5 authentication protocol is specified on the IETF RFC 1510 page on the Request for Comments Web site. The protocol is extremely secure and scalable, making it ideal for authentication in an integrated networking environment.
In Windows servers and clients running Microsoft Windows 2000 Server or later, the Kerberos version 5 authentication protocol is the basis of authentication to Active Directory. It is also integrated into SMB, HTTP, and RPC, as well as the client and server applications that use these protocols. The Windows platform offers the user a seamless and integrated experience for this powerful security tool.
The Kerberos version 5 protocol is very important to the Microsoft Identity and Access Management platform because it is based on an open standard. Many other vendors have also implemented the Kerberos version 5 protocol based on the Massachusetts Institute of Technology (MIT) implementation of the protocol, thus setting the stage for authentication interoperability between Microsoft and non-Microsoft platforms and applications.
Windows supports two ways of configuring the Kerberos version 5 protocol to achieve interoperability:
In an intranet, Kerberos version 5 protocol implementations on the Windows platform offer the user SSO because of the basic characteristics of the authentication protocol and the specific features of the way the protocol is implemented in Windows client and server operating systems.
One major limitation of the Kerberos version 5 protocol that prevents it from being a universal solution for application authentication and security is that it is not practical to configure Kerberos authentication for use on the Internet. The reasons for this are discussed in more detail in the "Web Single Sign On" section later in this chapter.
SSL 3.0 and TLS 1.0 are closely related protocols you can use to solve the general problem of how to secure a communication channel between two applications. SSL 3.0 is a proprietary Netscape Communications protocol, while TLS 1.0 is the IETF standard RFC 2246 definition on the Request for Comments Web site. The two protocols are similar, but TLS does have some important improvements and Microsoft recommends using it whenever possible. Both TLS and SSL provide the opportunity for server authentication during establishment of the secure data channel, with client authentication as an option.
The SSL and TLS protocols are most commonly used to provide data protection and integrity (encryption) over the HTTP protocol. Other protocols offer support for SSL or TLS as well. For example, Lightweight Directory Access Protocol (LDAP) incorporates SSL to produce LDAP over SSL, or LDAPS. In addition, custom or third-party applications can use SSL or TLS directly through SSPI and specify the SChannel security package.
SSL and TLS offer authentication that is based on certificates and secure data transfers using symmetric encryption keys. On the Internet, organizations commonly use SSL and TLS for server authentication. Clients verify the following conditions to authenticate servers in SSL and TLS:
SSL and TLS also support and integrate client authentication with the Windows Server 2003 platform through X.509 client certificates. Simultaneous client and server authentication is usually referred to as mutual authentication. To complete client authentication, the client presents a valid client certificate, measured by the server against the same criteria as described for server authentication. After validating the client certificate, Windows Server includes the ability to map it to an Active Directory account. Active Directory offers flexibility in how certificates can be mapped, allowing one-to-one or many-to-one mappings.
Relative to other authentication protocols, SSL and TLS have very good security characteristics when using X.509 digital certificates for authentication.
Note SSL and TLS offer Web SSO for users through Windows Credential Manager on the Windows XP client, which is described later in this chapter.
Microsoft Passport is a Web service that authenticates users against a massive database of digital identities. Individuals maintain their Passport identity through a secure Web site. Passport enables authentication and Web SSO capabilities at many Web sites, and is in use on many Microsoft Web sites, and also on some sites not owned by Microsoft.
Developers can create applications that link to Passport, so that the applications only accept connections from registered Passport users. If Passport determines that a user's credentials are valid, it returns an authentication ticket that the application can decrypt to determine the user's identity. Because of privacy requirements, a typical Passport authentication will only deliver a Passport Unique ID (PUID) to the affiliated application.
Typically, the application then maps the PUID to a locally maintained user account to derive a digital identity that is valid in the organization. Windows Server 2003 fully integrates with Passport when selecting the Passport authentication configuration option in IIS 6.0. In addition, you can map Passport users to Active Directory accounts to allow full Passport authentication integration with the Windows security model.
Passport authentication provides an SSO user experience for Internet-facing applications. Passport does this by providing an authentication ticket encoded in a HTTP cookie. The presence of the cookie, maintained during the life of the browser session, allows for authentication to multiple applications without requiring the user to log in repeatedly to the Passport authentication service.
Digest authentication is another standards-based authentication protocol described in RFC 2617 on the Request for Comments Web site, that is included as an authentication package in Windows Server 2003. Digest authentication primarily provides interoperability between Windows and non-Windows platforms for Internet authentication.
Windows Server 2003 also implements Digest authentication as a simple authentication and security layer (SASL) mechanism as described in RFC 2831 on the Request for Comments Web site. SASL is another abstraction layer between the application and the underlying protocol that makes it easy to include different authentication mechanisms without changing the application. In some respects it is similar to the SPNEGO mechanism described previously. SASL is primarily used for LDAP authentication.
Digest authentication has similar security characteristics to the proprietary NTLM protocol. Both Digest authentication and NTLM are challenge/response protocols, which require the authenticating server to generate a challenge containing some amount of unpredictable data. The client then forms the response by encrypting the challenge using a key derived from the user's password. The server, or a trusted third party service such as Active Directory, can verify that the user possesses the correct password by comparing the client's response to a computed value based on the credential associated with the user in the identity store. If the response matches the computed value, the user is assumed to know the secret password and is authenticated.
In general, Digest authentication is not as secure as the Kerberos version 5 protocol because it depends on strong passwords to protect against attacks on the challenge/response mechanism. However, because the plaintext password is not presented to the server during authentication, it is better than forms-based or Basic authentication. SSL and TLS are often used to protect Digest authentication from attacks.
Digest authentication does not scale as well as the Kerberos version 5 protocol in most scenarios, but it will work in scenarios where the Kerberos protocol will not. An example is authentication to externally facing Web sites.
Digest authentication offers SSO only to protect information that is available through a single Web URL. If users navigate to a different site, or even to a different server in the same site, then they will usually have to enter their credentials again.
Forms-based authentication relies on logon forms in Web pages to collect user credentials, almost always in the form of a plaintext username and password. As such, this type of authentication is not an authentication protocol between a client and server in the same sense as either the Kerberos version 5 protocol or Digest authentication described in the previous section.
Forms-based authentication requires extreme care to properly protect an application that supports it, and Microsoft does not recommend using it without SSL. An exploited vulnerability in an application that uses forms-based authentication can allow the attacker to harvest plaintext password data, which would be a serious security risk to application data across the organization and to the network itself.
Because the application performing forms-based authentication receives user credentials in plaintext, the application can choose to authenticate against user stores other than Active Directory. Microsoft does not recommend this approach in most cases because additional identity stores can complicate the identity and access management solution.
Application developers who implement forms-based authentication are encouraged to authenticate users in Active Directory using LDAP bind or a Windows API such as LogonUser() to validate the user credentials, and optionally to generate a security context as described in the "Authorization" section later in this chapter.
Applications that implement forms-based authentication typically use HTTP cookies or modifications of URLs to provide SSO for the user. ASP.NET provides functionality to protect cookies from unauthorized reading using encryption and from alteration using digital signatures.
The "Developing Identity-Aware ASP.NET Applications" paper in this series provides more details about how developers can use forms-based authentication on the Windows platform.
Like forms-based authentication, Basic authentication is not really a network authentication protocol in the sense that it does not cryptographically protect the user's credentials when authenticating to a network resource. Like forms-based authentication, the server doing the authentication receives the user credentials in cleartext and then uses Windows APIs to authenticate the user. As with forms-based authentication, the developer and system administrator deploying this authentication technique must go to great efforts to protect the application or server against compromise. For this reason, Microsoft strongly recommends that you do not use Basic authentication without SSL. Basic authentication has the same SSO characteristics as Digest authentication.
An important part of any discussion about authentication is the concept of single sign on (SSO). There are several approaches available for achieving SSO as part of the authentication process:
SSO is purely about eliminating the need for additional entering of user credentials and implies no judgment about the security level of the authentication involved. There may be some types of SSO that are preferable to others for security reasons.
In addition, Extranet SSO and Intranet SSO are terms used to refer to the techniques for achieving SSO in extranet or intranet scenarios. Extranet SSO is usually Web-based, while Intranet SSO can involve many types of applications and services, including Web applications, thick-client applications, and terminal sessions.
Secure logon requires that the user prove their identity to a network, but repeatedly typing a password to access multiple resources is an undesirable user experience. The Microsoft Windows platform capitalizes on the ability to use a single user identity (maintained in Active Directory) across the network. Because the credentials used to log on to the workstation will often be the same credentials that are used to access network resources, the user's logon credentials (the user name and password combination) are cached locally in the Local Security Authority (LSA) on the client operating system. When a user logs on to the domain, Windows authentication uses the cached credentials to provide SSO when authenticating to network resources.
Good security requires a user to provide an authenticated identity to access a network resource. SSO allows users to authenticate once with the system to access all applications and data sources they are entitled to use without entering another account ID or password.
The Kerberos version 5 authentication protocol, NTLM, and smart card authentication techniques are all integrated with the desktop logon process in Microsoft client and server operating systems in order to provide a SSO experience for users within a Windows domain or forest in an organization's intranet. Active Directory provides the trusted third party that allows servers to validate users without needing to store information about each user locally.
Advanced trust mechanisms such as cross-forest trusts in Windows Server 2003 allow identities in one forest to enjoy SSO when accessing resources in other forests.
As more companies deploy extranet and intranet-based Web applications that are used by employees, partners, and customers, the ability to provide the user with a SSO experience becomes very important.
Web applications are different than traditional "thick" client/server applications because they often rely on the Web server to implement authentication. This reliance allows a common approach for adding authentication mechanisms to a single application (the Web server) while solving the authentication problem for a large number of server-hosted applications. In an intranet environment, Microsoft server and client products provide Web Single Sign On or Web SSO by implementing the Kerberos version 5 authentication protocol in Internet Explorer and IIS 6.0 as described in the "Intranet Access Management" paper in this series.
Unfortunately, the Kerberos implementation that works well in the intranet scenario does not work well for Internet-facing applications in an organization's extranet. The distinction between intranet and extranet Web SSO results from a combination of three factors:
A detailed discussion of the difficulties inherent in deploying an Internet-facing KDC is beyond the scope of this paper, but the issue is a significant barrier to deployment.
The second problem is usually the more significant issue for extranet deployments. Unlike internal deployments, where software standards are enforceable, few organizations can dictate both the type and version of browser software used by external customers and business partners for accessing external applications. Microsoft Internet Explorer version 6.0 and greater is the only commercially available browser that supports Kerberos authentication over HTTP.
The standard approach to solving the problem of SSO to multiple Web applications is to make use of session "cookies" as described in the HTTP State Management Mechanism, defined by IETF RFC 2109 on the Request for Comments Web site. Several independent software vendors (ISV) offer solutions that enable you to achieve Web SSO across your extranet Web applications.
Microsoft Passport Services, described in detail in an earlier section, also provides the user with a SSO experience to sites that support Passport authentication.
You can combine Web SSO techniques with Enterprise SSO techniques, such as a SharePoint Portal Server Web site that includes a Web part for accessing legacy application data within a unique authentication directory. In this example, a Web SSO technique provides access to the Web site and an Enterprise SSO technique provides access to the legacy application data.
Enterprise SSO defines any technique that uses a form of credential mapping to provide an SSO experience. Credential mapping is necessary because different identity stores or directories are involved in authentication. A service (which may be running on the client or on a server) signs on to the target application on behalf of the account, simulating the experience of SSO. This service must look up the appropriate credentials (accounts, passwords, and so on) from a credential mapping store or database.
Microsoft BizTalk® Server, Host Integration Server, SharePoint® Portal Server, Windows Credential Manager, and products from ISVs such as PassLogix, Protocom, and Version3 use various Enterprise SSO techniques for SSO with legacy systems, applications that use their own directories for authentication, and even for accessing resources in un-trusted Windows domains.
Enterprise SSO provides a better user experience than no SSO with multiple non-trusting identity stores, as is the case in many organizations. The Enterprise SSO approach should be integrated with provisioning and password management approaches to ensure a seamless experience and keep Helpdesk calls to a minimum. This approach will also provide the best user experience while minimizing TCO.
Note Desktop integrated SSO is preferable to Enterprise SSO, as it is tightly integrated with the directory of choice and does not require additional provisioning and administration of redundant directories and a credential mapping database.
For more information on credential mapping through Enterprise SSO, see the "Intranet Access Management" paper in this series.
Windows XP Professional and Windows Server 2003 include a Stored User Names and Passwords feature that also provides credential management functionality. Depending on the type of authentication attempted, this component can save user credentials and reuse them during future access attempts.
Figure 6.2. Stored User Names and Passwords enables SSO for multiple sets of credentials
If the application does not allow the user to save credentials, the user must manually access Stored User Names and Passwords to set up a credential for that resource. Credential Manager supports the following types of credentials:
Note You can use Windows Credential Manager to provide a Web SSO experience with SSL/TLS X.509 client certificate authentication. By default, users see a prompt to choose a certificate for authentication whenever they have more then one valid certificate. Credential Manager can ensure that the proper certificate is automatically presented when authenticating to a specific resource.
For more information on Windows Credential Manager, see the "Intranet Access Management" paper in this series.
Authorization is the process of an application or platform determining access to a resource by comparing the user's entitlements to the security configuration of the resource. For example, a user can authenticate to a file server, and then the server can determine whether or not the user has the ability to read, write, or delete a file.
Applications integrated with the Windows Server 2003 operating system and Active Directory use the built-in features of the operating system to perform authorization.
Windows Server 2003 supports two authorization mechanisms: the Windows access control list (ACL)–based impersonation model, and the new roles-based Authorization Manager. In addition, Microsoft ASP.NET applications can use ASP.NET roles for authorization. Both mechanisms are discussed in detail in the following sections.
Microsoft Windows NT 3.1 introduced the impersonation and ACL model to provide authorization for services and applications. Impersonation is the result of closely coupling the authentication and authorization mechanisms for a seamless user experience and easy management.
An authentication package authenticates the user and then builds a "security context" for that user. The security context represents the identity and groups that the user belongs to, as well as the user's entitlements. Once the authentication package generates the security context, the application or service is given the security context to use for allowing access to resources. In other words, the service can impersonate the user locally when attempting to access resources by using the user's security context to gain access instead of using the service's own context.
This is an important concept because most services have broad privileges on a computer. For example, the server message block (SMB) service that provides file and print services on servers running Windows operates as the local system and has access to any resource. To limit user access to files according to rules established by the owner of the file or system administrator, the SMB service impersonates the remote user.
The other part of the Windows authorization model is the object-based ACL. The ACL for an object defines what access level security principals (users or groups) have to the object. For example, the ACL on a file could define that one user has the right to read a file while another user has rights to both read and delete the file.
The operating system, specifically the NT Object Manager, is the final arbitrator on access to objects using this model. The NT Object Manager does this by comparing the security context of the user against the ACL on the object. Because the operating system is the final arbitrator, the impersonation/ACL model has security characteristics that are good for scenarios where multiple applications may access a system resource.
There are areas, however, where it is possible to improve on the impersonation/ACL model, including the following:
To overcome these issues, Windows Server 2003 includes Authorization Manager for system administrators and application developers. The Windows 2000 version of Authorization Manager is available from the Windows 2000 Authorization Manager Runtime download page on Microsoft.com.
Authorization Manager in Windows Server 2003 is a new roles-based access control (RBAC) interface. Authorization Manager provides developers with the ability to achieve the following:
For a given task, the Authorization Manager interface organizes users into various roles within the application and gives them access while impersonating these roles. The following figure shows three different users accessing an application. Authorization Manager maps each of these users into a role defined in the authorization policy store.
Figure 6.3. How Authorization Manager defines and applies roles
Authorization Manager provides the ability to define and maintain logical roles and tasks according to each application's needs. Representing the security model according to an organizational structure simplifies access control administration. In addition, task and role definitions are conducive to modeling application workflows, and giving developers a natural application-centric environment through Authorization Manager.
Authorization Manager also dynamically qualifies entitlements granted at run time. This capability addresses the distinct authorization problem that exists for line-of-business (LOB) Web applications, such as expense reporting applications or Web-based shopping applications.
For such applications, access to well-defined persistent objects often does not determine authorization decisions. Instead, they require verifying a workflow or a set of multiple distinct operations, such as querying a database and sending an e-mail message. Such access decisions are not just based on token group membership but also on business logic, such as the amount submitted in an expense application or workflow completion verification. Applications such as these that do not have well-defined persistent objects have no place to put an ACL. These dynamic access decisions are readily available in the form of dynamic business rules (called BizRules) that Authorization Manager supplies.
BizRules are commonly implemented using a Microsoft Visual Basic® Scripting Edition script or JScript® routine that executes when access rights are checked as the application is running. If the BizRules succeed, the application performs the requested operations.
Authorization manager policy that defines the logical roles and tasks used by an application can be stored in either an application partition in Active Directory or Active Directory Application Mode or in an XML file on the server or on the network.
For more information on RBAC using Windows Server 2003 Authorization Manager, see the Authorization Manager Concepts page on TechNet.
IIS 6.0 provides an example of how an application can use an Authorization Manager role-based framework. IIS 6.0, which comes with Windows Server 2003, integrates with Authorization Manager to implement IIS 6.0 URL authorization. This integration lets Web application administrators control access to URLs based on custom user roles, LDAP queries, and BizRules.
Authorizing user access to Web pages in IIS 6.0 can require managing many discretionary access control lists (DACL) on resources that Web applications use. Resources for Web applications may include Web page files, database records, and registry keys. Maintaining DACLs requires administrators to know precisely what back-end permission requirements each object needs to perform meaningful tasks in the Web application.
IIS 6.0 URL authorization lets administrators simplify access management by authorizing user access to the URLs that make up a Web application. When a client requests a URL, IIS 6.0 URL authorization validates the user's access based on the user's roles. If necessary, the Web application can further restrict access to resources and operations by using the Authorization Manager role-based framework.
ASP.NET offers a roles-based authorization model that uses Active Directory groups as well as application-derived roles. There are some similarities between Authorization Manager RBAC and ASP.NET role-based authorization, but they are implemented through separate mechanisms. ASP.NET roles are most useful for standalone applications that are unlikely to belong to a larger suite of applications.
There are situations where you may need to link two or more separate identity stores, such as when you need to implement a partnership arrangement or use separate external and internal directory structures. The link enables users who can authenticate to one identity store to authenticate to a second one, even though they have no digital identity in the second identity store. This arrangement is called a trust relationship.
Trust relationships exist between separate realms, where a realm defines a security boundary. In Windows NT and Active Directory environments, you can establish trusts between domains. In Windows Server 2003, you can establish higher trust levels between forests. However, domains within a forest have implicit trusts with each other.
Applications that integrate with Windows Server 2003 and Active Directory use the built in features of the operating system to establish and maintain trust.
At a high level, trust relationships simply provide a way to authenticate between realms. The mechanisms of trust, however, become complicated because there are many tasks that must occur among realms to make the authentication and subsequent authorization truly useful.
The remainder of this section discusses the types of trusts available in the Windows platform, and how to use them to solve identity and access management problems.
Microsoft Windows NT Server introduced the concept of domain trusts. The Windows NT domain trust, or external trust as it is now called, allowed one Windows NT domain to trust another Windows NT domain as an authority to authenticate users belonging to that domain. External trusts can be either one way or bidirectional, and the direction of trust dictates the direction through which authentication and access can occur, as shown in the following figure.
Figure 6.4. The relationship between trusting and trusted domains
The Windows NT Server 4.0 model was very flexible and allowed departments to implement Windows NT 4.0 domains as needed in a bottom-up, grass-roots deployment pattern. The problem was that as very large companies brought more and more domains on line, managing external trust relationships became a serious issue. Because each deployed domain can have n trust relationships, the total number of trust relationships to manage grows rapidly as the number of domains expands. A small company with 4 domains might have to manage just 12 different trusts, but a larger company with 10 domains could have to manage 90 trust relationships. A company with 100 domains could have to manage a much larger number of trust relationships.
To simplify trust management in large organizations, Microsoft Windows 2000 Server introduced the concept of the Active Directory forest. The Active Directory forest preserves the flexibility of the Windows NT Server 4.0 bottom-up trust model when needed but makes the problem of how to carry out top-down trust management much easier, as shown in the following figure.
Figure 6.5. A single Windows 2000 Server forest
This figure represents an organization with a single Windows 2000 Server forest. The trust relationships within a forest are implicit trusts, which provide the same functionality as bidirectional external trusts but are created automatically when domains (thought of as trees within a forest) are added to the same forest. Domains within a forest are hierarchical, which allows an organization's network to mirror the organization's business.
Unfortunately, Windows 2000 Server did not provide the final answer for trust relationships. It was presumed that most companies would deploy a single forest spanning their entire network and resources. There are many reasons, however, why this turned out to not be the case.
For example, some very large organizations do not have a centrally trusted administrative group with the responsibility to manage all of the organization's resources. In such organizations, therefore, there are natural security boundaries between the different parts of the organization that the directory service architecture must implement. Another common example is the need for separate intranet and extranet forests. While it is possible to design the extranet as a domain of the intranet forest, many organizations would like to create more isolation between the extranet and intranet for security reasons.
More information about the security boundary characteristics of Windows domains and forests, see "Creating and Enhancing Security Boundaries" on Microsoft.com.
For an organization that has multiple forests with Windows 2000 Active Directory but wishes to use trust between the domains of the different forests, it is necessary to establish explicit trusts between every domain in one forest to every domain in the other forest. Achieving this configuration is only slightly less complex then establishing trusts between every Windows NT Server 4.0 domain, so a better solution was clearly needed.
To make multiple forest deployments easier, Windows Server 2003 established the concept of the forest trust. A forest trust allows administrators to federate two Active Directory forests with a single trust relationship to provide a seamless authentication and authorization experience between them. A forest trust is a single trust link between the root domains of two forests; it establishes a transitive trust between all the domains in each forest. For example, if Forest A trusts Forest B, then all the domains in Forest A trust all the domains in Forest B through the forest trust. The following figure illustrates this concept:
Figure 6.6. Windows Server 2003 forest trust relationships
However, forest trusts are not transitive across forests. That is, if Forest A trusts Forest B, and Forest B trusts Forest C, then Forest A does not automatically trust Forest C.
For more information about using and configuring Windows Server 2003 cross-forest trusts, see the Planning and Implementing Federated Forests in Windows Server 2003 page on Microsoft TechNet.
Forest trusts make the concept of federated forests possible in Windows Server 2003. As mentioned, a forest trust enables a transitive trust between all of the domains in two forests; the trust is established between the root domains of both forests.
Forest trusts can be one-way or bidirectional trusts. In the previous figure, Forest A and Forest B have a bi-directional trust. Because of this, users in Forest A can authenticate to resources in Forest B, and users in Forest B can authenticate to resources in Forest A. In addition to authentication, the forest trust enables authorization so that the resource owners in each forest can add principals from the other forest to DACLs and groups, or create roles based on those groups.
Security requirements will sometimes prevent using Windows trust mechanisms between forests. In such cases you can create shadow accounts in one of the directories to mirror the accounts in the other one. The shadow account typically mirrors only as much of the identity information from the source realm as is needed by the specific application or scenario. To meet security requirements, identity attributes that are particularly sensitive are not represented. Sensitive information could include such things as the identity's social security number or user password.
The concept of using shadow accounts for employees might not be intuitive, but consider the case in which an organization is using an intranet instance of Active Directory for employee authentication but also wants to have an extranet for employees to use. The two options for authenticating employees on the extranet are:
The first option involves opening a number of ports to allow a path through the firewall separating the perimeter network from the intranet. This option is acceptable to many organizations, but others require complete isolation between their perimeter networks and intranets.
For organizations that require strict network isolation, using a shadow account might be the best option. Microsoft recommends creating shadow accounts with an automated mechanism, such as those available in Microsoft Identity Integration Server 2003, Enterprise Edition (MIIS 2003 SP1). Shadow accounts can even add to network security in certain scenarios if they enable non-password-based authentication mechanisms to less secure servers such as those found in the extranet. Examples of this include authentication based on Secure Sockets Layer (SSL) 3.0 and Transport Layer Security (TLS) 1.0 client certificate authentication, or one-time password authentication mechanisms such as the SecurID two-factor authentication product from RSA Security Inc.
A public key infrastructure (PKI) is a system of digital certificates, certification authorities (CA), and other registration authorities that verify and authenticate the validity of each party involved in an electronic transaction through the use of public key cryptography. For this to occur, however, each party must trust the issuer of the certificate, most often a CA.
For Windows users, computers, and services, trust in a certification authority is established when there is a copy of the root certificate in the trusted root certification authority's store as well as a valid certification path. A valid certification path means that none of the certificates in the certification path have been revoked or expired. The certification path includes every certificate issued to each CA in the certification hierarchy that ranges from a subordinate CA to the root CA.
For example, for a root CA, the certification path is one certificate, its own self-signed certificate. For a subordinate CA, which is just under the root CA in the hierarchy, its certification path uses two certificates: its own certificate and the root CA certificate.
The process of importing a root certificate into the trusted root certification authority's store is the most straightforward way to establish a PKI trust for a computer and the applications that the computer hosts. For example, if a Web server at Contoso Pharmaceuticals (a fictitious organization) has the root certificate CA for Fabrikam Inc. (another fictitious organization) installed in the root certification authority's store, then the Contoso Web server will trust any valid certificate that the Fabrikam CA issues. This process only establishes the trust portion of the transaction, however, and does not establish an identity, or context, on the Web server. To create a mapping from identity to context requires other actions, such as mapping some information in the certificate to a security principal in Active Directory.
For more information on mutual authentication using Active Directory certificate mapping, see the Step-by-Step Guide to Mapping Certificates to User Accounts page on the Microsoft Windows 2000 Server Web site.
While the trusted root certification authority's store mechanism is fairly easy to deploy, it may not meet the security requirements in complex scenarios for establishing a federated trust between two organizations such as Contoso and Fabrikam. Consider a scenario in which both Contoso and Fabrikam users can present valid certificates to access the Contoso Web site. The external Active Directory in this case would contain certificate mappings from both the Contoso and Fabrikam CAs.
One practice could be to establish a mapping based on the subject of the certificate, for example: Eemail@example.com. The problem with this approach is that the trust is unbounded. The unbounded trust means that Contoso is willing to completely trust Fabrikam to not issue a certificate with the subject Efirstname.lastname@example.org, where email@example.com is a user from the Contoso organization, not a user from Fabrikam. In this case, the certificate holder could gain access to sensitive data on the Contoso site. This problem exists not because PKI trust is inherently weak, but because the certificate definitions are too broad. The answer to this problem is a more finely controllable PKI trust mechanism, which would enable Fabrikam to issue certificates for the @fabrikam.com domain but not for the @contoso.com domain.
True cross-certification of CA hierarchies in a Windows 2000 network was not possible. The only available alternative was to define certificate trust lists (CTL) that trusted specific CAs and restricted certificate usage.
Qualified subordination, introduced in Windows 2003 Server, is the process of cross-certifying CA hierarchies using basic policy, naming, and application constraints to limit which certificates are accepted from partner CA hierarchies or a secondary hierarchy within the same organization. Using qualified subordination, a CA administrator can clearly define which certificates issued by a partner's PKI are trusted by the CA administrator's organization. Qualified subordination also provides methods for compartmentalizing and controlling certificate issuance within an organization according to policy guidelines.
Qualified subordination also allows you to establish trust between CAs in separate trust hierarchies. This type of trust relationship is also called cross-certification. With such a trust relationship, qualified subordination is not limited to subordinate CAs. Trust between hierarchies may be established using a subordinate CA in one hierarchy and the root CA in another hierarchy.
Qualified subordination allows you to place additional trust conditions within and between the domains in your PKI to extend your trust hierarchy. With qualified subordination, the qualified subordinate CAs in your trust hierarchy can each have different rules governing how they issue certificates and how their certificates may be used.
An example of how trust conditions can be used to solve the previously described problem of excessively broad certificate definitions is to use namespace constraints when establishing the cross-certification between the Contoso and Fabrikam hierarchies. In this way Contoso would only accept certificates from Fabrikam CAs that specified a fabrikam.com domain.
For more information on qualified subordination, see the Qualified subordination page on Microsoft TechNet.
Federated identity management is a standards-based technology and information technology process that enables distributed identification, authentication, and authorization across organizational and platform boundaries. Federated systems interoperate across organizational boundaries and connect processes that use different technologies, identity storage, security approaches, and programming models. Within a federated system, an organization needs a standardized and secure way of expressing the services that are available to trusted partners and customers. An organization must also implement the policies by which it runs its business, such as:
Microsoft Windows Server 2003 R2 introduces the Active Directory Federation Services (ADFS), which enables organizations to share a user's identity information securely. ADFS provides Web single sign on (SSO) technologies to authenticate a user to multiple Web applications over the life of a single online session. ADFS accomplishes this by securely sharing digital identity and entitlement rights, or "claims," across security and enterprise boundaries.
ADFS works with both Active Directory and Active Directory Application Mode (ADAM). Specifically, ADFS works with both enterprise-wide deployments of Active Directory or instances of ADAM. When it works with Active Directory, ADFS can take advantage of the strong authentication technologies in Active Directory, including Kerberos, X.509 digital certificates, and smart cards. When it works with ADAM, ADFS uses Lightweight Directory Access Protocol (LDAP) Bind to authenticate users.
ADFS supports distributed authentication and authorization over the Internet. ADFS can be integrated into an organization's or department's existing access management solution to translate the terms that are used in the organization into claims that are agreed on as part of a federation. ADFS can create, secure, and verify the claims that move between organizations. It can also audit and monitor the activity between organizations and departments to help ensure secure transactions.
For more information on ADFS, see Overview of Active Directory Federation Services (ADFS) in Windows Server 2003 R2 on Microsoft.com.
Auditing provides a means to monitor access management events and changes to identity objects. Security auditing is typically used to monitor for the occurrence of problems and security breaches. Technologies such as the Windows Security Event Log, the Windows Management Interface (WMI), and products such as MOM 2005 SP1 can provide comprehensive security auditing and reporting.
Active Directory and ADAM are fully integrated with Windows Server 2003 auditing. The Windows Security Event Log reflects changes to directory objects and attributes, as well as authorization policy for directory objects and attributes, schema, and Group Policy. You have precise control over configuring auditable events that can be based on success, failure, or the action attempted.
The Windows authentication mechanisms described above all generate audits in the Windows Security Event Log. You can configure which audits to generate (such as authentication failure or success) using Group Policy, or you can manually configure each server.
Windows Server 2003 also provides precise control over authentication events by categorizing them according to the authentication type. For example, one type of audit tracks console logons while another tracks authentication attempts to network resources. Authentication audits are always traceable to a unique security principal.
Once the user has authenticated to the identity store, the next stage is to specify what the user can access. Authorization is the process that controls access to resources.
The Windows Server platform provides complete support for auditing authorization actions. For the impersonation/ACL model, the NT Object Manager reports audits for resource access according to the audit configuration. You can enforce this configuration through Group Policy or manually on each server. Since the system generates these audits, the audit event will appear in the System Security Event Log.
The auditing configuration capabilities are precise, making it possible to specify, for example, only to audit failed access attempts to files. Because the authentication and authorization mechanisms are tightly integrated, the authorization audit specifies the security principal accessing the resource according to its unique security identifier (SID).
Authorization Manager supports both run-time auditing and Authorization Manager policy change auditing. Run-time auditing uses either fail or success audits to report application initialization, context creation and deletion, and object access. Authorization Manager policy change auditing can report any change to the policy store, including the audits on the policy and the policy definition.
Authentication and authorization within a single security realm or Active Directory forest is a relatively straightforward process. However, identity and access management often needs to cope with a requirement to link two separate security realms, which requires implementing some form of trust, either between directory services or between organizations. The next chapter looks at this requirement.
Windows Server 2003 fully audits trust configuration at a detailed level. You can audit events for creating, deleting, and modifying trusts. Trust auditing events appear in the Security Event Log.
Applications play an important role in any identity and access management strategy. Applications consume digital identity data for authorization purposes and evaluate entitlements that enforce access to resources. It is essential when choosing or developing applications to ensure that the applications fit into your identity and access management framework.
Applications usually fall into one of two types:
Regardless of whether an application has been developed or purchased, it needs to be integrated effectively into the organization's identity and access management framework. However, there are different criteria involved, depending on which sort of application it is that you are trying to integrate.
Whether an application is easy or difficult to integrate with the identity and access management platform is determined by an application's architecture and the mechanisms it uses to identify its users. Microsoft recommends identifying your applications, categorizing them, and looking at their functionality and infrastructure dependencies. If an application is not compatible with your organization's identity and access management platform, you will need to modify either the application or your infrastructure.
Note The important point from an application development perspective is that applications should not invent and implement their own identity stores, security protocols (for authentication, authorization, and auditing), or data protection mechanisms.
The following sections in this chapter explore recommended methods for integrating applications with the Microsoft Identity and Access Management Platform. They also set the stage for a detailed discussion of the techniques for development, testing, and deploying identity-aware applications. The paper "Developing Identity-Aware Applications" in this series describes in more detail what application architects and developers need to do to integrate applications into the infrastructure.
When choosing an application, IT managers often put significant effort into ensuring that the application can provide the required functionality. Unfortunately, consideration of how the application will integrate with the network is often overlooked, particularly with regard to identity management.
Third-party applications can identify users by:
Exchange Server 2003 provides an example of an application that fully integrates with a directory service. Exchange extends the Microsoft Active Directory® directory service schema and then adds mailbox attributes to user accounts in Active Directory. Unlike Exchange 5.5, Exchange 2000 Server and Exchange Server 2003 do not maintain a separate directory database. Full integration with a directory service provides the easiest way to implement application identity management.
Some applications do not fully integrate with a directory service, but can authenticate users to a directory using standards-based connections. An example of this would be applications that can use the Kerberos version 5 authentication protocol to authenticate to Active Directory, such as the SAP R/3 example that is part of the fictitious Contoso environment referenced in other papers in this series.
Applications may authenticate to another directory service that is not the organization's primary directory. This is not ideal, as you will now have to synchronize between your primary directory and the directory the application uses. A metadirectory product such as Microsoft Identity Integration Server 2003, Enterprise Edition (MIIS 2003 SP1) can provide this synchronization through management agents that connect to most common identity stores.
The least suitable arrangement is when the application has a dedicated proprietary identity store and there are no available tools to import/export identity data in a format supported by MIIS 2003 SP1. In this special case, it may not be possible to use MIIS 2003 SP1 to synchronize the application identity store with the primary directory service, so maintaining identities in the application identity store becomes a manual process, which is costly and prone to errors.
If you are developing applications in-house, there are three fundamental approaches that application architects and developers need to consider:
The choices in these three areas affect what application developers need to implement for authentication, authorization, and auditing. In a well-integrated application, almost no identity-aware code needs implementing, since the underlying infrastructure does all the work.
Application integration covers the same factors that were discussed in the earlier "Choosing Applications" section.
There are three different models for flowing the identity of the authenticated user in distributed environments, also known as identity flow. These models are:
Impersonation allows a server process to run using the security credentials of the client. When the server is impersonating the client, any operations performed by the server are performed using the client's credentials. However, impersonation does not allow the server to access remote resources on behalf of the client; such access requires delegation. Delegation is more powerful and allows the server process to make calls to other computers while acting as the client.
With this model, the middle tier service uses a fixed identity to access downstream services and resources. The security context of the original caller does not flow through the service at the operating system level, although the application may choose to flow the original caller's identity at the application level. It may need to do so to support back-end auditing requirements, or to support per-user data access and authorization.
The model name stems from the fact that the downstream service (perhaps a database) trusts the upstream service to authorize callers.
The credential mapping model aligns one set of credentials with another in a mapping table. The mapped credentials can then be used to create a new connection to another system. The credential mapping model comes in two varieties: one uses direct credential mapping, while the other uses indirect mapping "tickets" that are later exchanged for credentials. You can use the credential mapping model if the target system does not support the Kerberos version 5 authentication protocol or does not use Active Directory as its identity store.
Once your application has identified the user, it needs to be able to control what that user can access through authorization. The two application authorization models are:
The ACL model involves securing a resource (such as a file, folder, printer, or directory service object) using an ACL, which is a list of users and groups, together with the permissions (both allow and deny) for each user or group. When a user requests access to the resource, the user's access permissions are evaluated along with the access permissions of all groups of which the user is a member. The user is then granted or denied access on the basis of those access permissions.
The ACL model works well with well-defined persistent objects, but does not function in certain environments such as line-of-business (LOB) applications or Web applications. Dealing with these types of applications, workflow applications, and transitory objects requires a different model.
RBAC uses the concept of roles. Typically, a role is an organizational title, such as "Manager," "Teller," or "Sales Executive." RBAC maps these roles to application permissions so that access control administration can be accomplished in terms of a user's role.
RBAC then translates a user's role membership to application permissions. Since the permissions are granted at the role level, permissions can be queried and changed for the role without examining the specific resources.
Once administrators create the roles and assign permissions to those roles, there should be little need to change roles or permissions. The only changes will be to assign users (or groups) to the roles.
The "Developing Identity-Aware ASP.NET Applications" paper in this series describes in more detail what application architects and developers need to do to integrate applications into the infrastructure.