Microsoft Identity and Access Management - Fundamental Concepts

Introduction to the Fundamental Concepts Paper

Executive Summary

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.

The Business Challenge

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.

The Business Benefits

Improving access to network resources and managing the identity life-cycle can provide significant dividends for organizations. Typical benefits include:

• Lower total cost of ownership (TCO) through efficiency and consolidation.
• Security improvements that reduce the risk of internal and external attacks.
• Greater access to information by partners, employees, and customers — driving increased productivity, satisfaction, and revenue.
• Higher levels of regulatory compliance through the implementation of comprehensive security, audit, and access policies.
• Greater business agility during events such as mergers and acquisitions.

Who Should Read This Paper

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.

Reader Prerequisites

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.

Paper Overview

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:

• Authentication, single sign on, and credential mapping.
• Authorization using role-based access control and access control lists.
• Trust and federation.
• Security auditing.

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.

Terminology and Initiatives

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:

• What are the benefits that identity and access management initiatives should produce?
• What challenges must each initiative overcome?
• What are the specific organizational factors that must be addressed?
• What business and technology projects and solutions are necessary to support each initiative?

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.

Identity and Access Management Terminology

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.

• Digital identity. The unique identifier and descriptive attributes of a person, group, device, or service. Examples include user or computer accounts in Active Directory, e-mail accounts in Microsoft Exchange Server 2003, user entries in a database table, and logon credentials for a custom application.
• Credential. Typically a piece of information related to or derived from a secret that a digital identity possesses, although secrets are not involved in all cases. Examples of credentials include passwords, X.509 certificates, and biometric information.
• Security principal. A digital identity with one or more credentials that can be authenticated and authorized to interact with the network.
• Identity store. A repository that contains digital identities. Identity stores are usually some form of directory or database managed and accessed through a provider such as Active Directory or Microsoft SQL Server. Identity stores can be centralized, for example on a mainframe computer, or distributed; Active Directory is an example of a distributed identity store. They generally have well-defined schemas for what information can be stored and in what form it can be recorded. They usually incorporate some form of encryption or hashing algorithm to protect both the store and components of the digital identity, such as credentials. Older and custom identity stores may not have such strict security mechanisms and may store passwords in plaintext (with no encryption).
• Identity synchronization. The process of ensuring that multiple identity stores contain consistent data for a given digital identity. This process can be achieved using programmatic methods such as scripts or through a dedicated product such as MIIS 2003 SP1.
• Identity integration services. Services that aggregate, synchronize, and enable central provisioning and deprovisioning of identity information across multiple connected identity stores. MIIS 2003 SP1 and the Identity Integration Feature Pack 1a (IIFP) for Active Directory provide identity integration services.
• Provisioning. The process of adding identities to an identity store and establishing initial credentials and entitlements for them. Deprovisioning works in the opposite manner, resulting in the deletion or deactivation of an identity. Provisioning and deprovisioning typically work with identity integration services to propagate additions, deletions, and deactivations to connected identity stores.
• Identity life-cycle management. The processes and technologies that keep digital identities current and consistent with governing policies. Identity life-cycle management includes identity synchronization, provisioning, deprovisioning, and the ongoing management of user attributes, credentials, and entitlements.
• Authentication. A process that checks the credentials of a security principal against values in an identity store. Authentication protocols such as Kerberos version 5, Secure Sockets Layer (SSL), NTLM, and digest authentication protect the authentication process and prevent the interception of credentials.
• Entitlement. A set of attributes that specify the access rights and privileges of an authenticated security principal. For example, Windows security groups and access rights are entitlements.
• Authorization. The process of resolving a user's entitlements with the permissions configured on a resource in order to control access. Authorization in the Windows operating system involves access control lists (ACLs) on files, folders, shares, and directory objects. Applications such as SQL Server, SharePoint® Portal Server, and Exchange Server implement access control mechanisms on resources they manage. Application developers can implement role-based access control using Windows Authorization Manager or ASP.NET roles.
• Trust. A state that describes the agreements between different parties and systems for sharing identity information. A trust is typically used to extend access to resources in a controlled manner while eliminating the administration that would otherwise be incurred to manage the security principals of the other party. Trust mechanisms include cross-forest trusts in Windows Server 2003 and trusts between realms using the Kerberos version 5 authentication protocol.
• Federation. A special kind of trust relationship between distinct organizations established beyond internal network boundaries.
• Security auditing. A process that logs and summarizes significant authentication and authorization events and changes to identity objects. Organizations will differ in their definition of significant events. Security audit records can be written to the Windows Security Event Log.
• Access management. The processes and technologies for controlling and monitoring access to resources consistent with governing policies. Access management includes authentication, authorization, trust, and security auditing.

Business Requirements

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.

Reducing Total Cost of Ownership

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.

• Logon and authentication. Reducing the amount of time spent logging on to different systems can significantly improve knowledge worker productivity. The average user spends 16 minutes a day authenticating and signing in. For a large organization (defined in the survey as having 10,000 users), this is equivalent to 2,666 hours—or 1.3 full-time equivalent (FTE) years per day.
• Managing the identity life-cycle. It is critical that an organization's IT staff concentrate on the important tasks of providing resource availability and ensuring network security. Time spent managing identities through inefficient mechanisms could be better spent doing more important tasks. The average time spent managing users, user stores, and authentication and access control is 54,180 hours per year. Even a 25 percent improvement in efficiency would equal 13,545 hours (or 6.7 FTEs) for a large organization.
• Password resets. Forty-five percent of Helpdesk calls are for password resets. Automating password resets reduces this call volume by approximately one third. For an organization with 10,000 users this is equivalent to an estimated annual cost savings of $648,000.
• Duplicate data. Eliminating duplicate identity data can streamline administration processes and reduce TCO. Thirty-eight percent of external users and 75 percent of internal users are contained in multiple data stores. The average timesaving for centralized and consolidated user store management is predicted to equal 1,236 hours per year for large organizations.

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.

Enhancing Security

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:

• Improving account policy enforcement. Security can be improved by managing accounts according to pre-defined standards. Account policy enforcement defines rules and procedures for implementing advanced security measures. Examples include requiring administrators to use smart cards and ensuring that all users have complex passwords and change them frequently.
• Removing stale accounts. Computer security can be significantly enhanced by removing stale accounts in a timely manner. Organizations must disable accounts for employees, contractors, partners, and customers when these accounts are no longer needed. If they are not disabled, the original account holders can misuse them to gain unauthorized access to systems. Stale accounts are attractive targets for malicious users and attackers, since they are likely to have outdated static credentials and any misuse or potential compromise of the account is less likely to be noticed.
• Improving application data protection. To meet organizational security requirements, applications must transfer data through secure mechanisms. Sensitive data must require both proper authentication and authorization before it can be accessed, and it must be protected on the network to prevent attackers from intercepting (sniffing) the data.
• Implementing strong authentication. Commonly used authentication techniques and credentials may not provide the level of security needed for critical applications and data. Microsoft recommends using strong authentication mechanisms, such as the Kerberos version 5 protocol and public key infrastructure (PKI) technologies when possible to improve the overall security of computing resources.
• Managing credentials with directory services. While directory services have many uses in an organization, they can provide specific security benefits. For example, advanced authentication methods such as smart cards and biometrics can greatly improve the security level of the organization. Unfortunately, such systems also introduce complexity and additional data about users that must be rigorously maintained and centrally accessible. Deploying such systems is easier when a robust directory infrastructure is in place.
• Improving authorization. Authorization must be flexible enough to provide both general and precise access to resources. For example, general access lets all employees have access to a particular application, whereas precise access only allows employees in the sales department to perform a certain operation in an application between the hours of 9 AM and 5 PM. Users should map logically to roles, such as database administrator, Helpdesk operator, or application user within the context of an organization or application.
• Managing entitlements through provisioning. A properly implemented provisioning system enforces the consistent application of policies for requesting and approving entitlements. Enforcement is made easier when all business units can easily follow the same process. A provisioning system also provides an audit trail that records when decisions and approvals were made and by whom.
• Implementing identity life-cycle management. An identity life-cycle management process helps keep user entitlements current over the course of a career. For example, if an employee moves from Finance to Marketing, the identity life-cycle management process can close and remove the employee's access to financial applications and provide them with access to marketing applications. Identity life-cycle management processes can be either manual or automated. Automated processes typically increase the level of security in an organization by removing and granting access in a more timely manner, and, if required, ensuring that both operations take place at the same time.
• Managing Groups. Good security practices require organizations to keep control of group memberships through effective group management. Group membership can give access rights and privileges, so it is important to ensure that each group only contains the correct accounts. Identity and access management systems can assign user accounts to the correct groups, or create dynamic groups dependent on an account's attributes, and then provision these groups into directory services and e-mail systems.
• Reducing the attack surface. Multiple identity stores present an increased risk of compromise of user accounts if each store is not managed to a common high standard. Similarly, a variety of authentication mechanisms typically means that threats to the entire system are less well-known and less easily mitigated. Reducing the total number of security systems and mechanisms means that remaining ones can be better managed and secured.
• Making it easy for users to do the right thing. Single sign on (SSO) makes it easier for users to comply with an organization's password policy. When faced with having to remember and manage multiple passwords, it is only natural for people to create simple ones or write down complex passwords that could be left unprotected in the work area.

Improving Access

In order to improve access to information assets identity and access management technologies should meet the following requirements:

• Enable immediate employee productivity and access to information resources through the efficient provisioning of accounts and hardware.
• Enable employees to be more productive by providing remote access to key applications outside of the organization's internal network environment.
• Allow partners to participate directly in business applications in a managed and controlled manner, thereby streamlining processes that span organizational boundaries.
• Attract customers through personalized information and by providing the ability to request products and services online. Improve the user experience and customer satisfaction to improve profitability.
• Enable savings by implementing federation, which encompasses a growing business opportunity for working with partners directly without having to bear the burden of managing the identities and credentials of participating partner staff.

By addressing these key identity and access management requirements, organizations can achieve greater employee productivity, decrease costs, and improve business integration.

Ensuring Regulatory Compliance

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:

• Sarbanes-Oxley Public Company Accounting Reform and Investor Protection Act.
• Gramm-Leach-Bliley Financial Services Modernization Act.
• The Health Insurance Portability and Accountability Act (HIPAA).

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.

Accommodating Mergers and Acquisitions

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:

• Making the identity stores of the two organizations compatible.
• Combining accounts from each system into a consolidated system.
• Using federation to unite identity and access management systems through trust.
• Synchronizing identity stores, which is often an acceptable short-term solution when the immediate consolidation of different systems isn't feasible during a merger or acquisition.
• Updating security policies to incorporate and comply with new regulatory requirements that arise as a result of the merger or acquisition.

Initiatives in an Identity and Access Management Strategy

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:

• Fast results improve executive sponsorship. Achieve some quick, low-cost results in order to build momentum and reinforce management approval.
• Address high-risk areas early. Security issues are often the primary business concerns which should be addressed as quickly as possible.
• Standards and infrastructure are often prerequisites for other initiatives. Depending on past investments, establishing standards through policy and the infrastructure to support them may involve significant costs and effort. However, the investment is worthwhile considering that the success of most other projects depend on these being in place.

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:

• Establishing security and access policies.
• Establishing directory service and security standards.
• Implementing identity aggregation and synchronization.
• Automating provisioning and deprovisioning.
• Providing effective group management.
• Consolidating identity stores.
• Providing password management and synchronization.
• Enabling interoperability and single sign on.
• Strengthening authentication mechanisms.
• Improving access for employees, customers, and partners.
• Establishing security auditing policy.
• Updating software procurement standards.
• Establishing software development standards for identity use.
• Developing and migrating identity-aware applications.

Establishing Security and Access Policies

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:

• Account management policies, which may dictate that stale accounts should be regularly pruned from identity stores.
• Password policies, which may state that account passwords must be changed on a regular basis and that the passwords are a certain minimum length and complexity.
• Security audit policies, which may define which actions must be reported on.
• Privacy policies, which may define "the right to be left alone" (freedom from unwanted communications such as spam) and informational privacy rules (the ability for individuals to control the collection and use of their personal information).
• Access management policies, which may insist that:
  • VPN access requires a smart card or other multi-factor authentication.
  • Specific applications require biometric authentication.
  • Extranet access to certain systems is restricted to authenticated users and enforced by edge firewall services.
  • Domain administrator logon requires a smartcard.
  • Computer connections to high-value systems require the use of IPSec encryption.
  • Operational restrictions are fulfilled, such as "withdrawals may be initiated on customer accounts by tellers only between the hours of 9am and 5pm."

Benefits

The potential benefits of establishing security and access policies include:

• Increased security across the organization.
• Increased security to specific high-value systems.
• Improved security audits.
• Achieving regulatory compliance.

Challenges

The challenges of establishing security and access policies include:

• Establishing the appropriate security requirements for each access scenario.
• Implementing policies with the chosen technologies, while acknowledging any constraints and limitations.
• Coping with the increases in management overhead and reduced efficiency that increased security without automation may bring.
• Operating more complex security mechanisms.
• Managing conflicting security requirements.

Establishing Directory Service and Security Standards

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.

Benefits

The potential benefits of establishing standard directory services and unified security standards include:

• Reduced administrative overhead.
• Simplified provisioning.
• Increased security across the organization.

Challenges

The challenges of establishing standard directory services and unified security standards are considerable, and can include:

• Line-of-business (LOB) applications and platforms with specific directory needs.
• Incompatible security policies that cannot be aligned.
• Intra-organizational issues, such as departmental autonomy.
• Regulatory requirements for information and management boundaries within organizations, such as financial institutions (for example, keeping the personal banking business separated from the insurance business).
• Finding a common authentication protocol that existing applications and identity stores across the organization can use.
• Presenting entitlements in a common format that different applications and systems across the organization can consume.

The "Platform and Infrastructure" paper in this series provides more information on establishing directory service and security standards.

Implementing Identity Aggregation and Synchronization

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.

Benefits

The benefits of identity aggregation and synchronization include:

• Reduced administration overhead related to linking identity information spread across multiple identity stores.
• Increased business information provided from a unified view of all digital identities in the organization.
• Improved identity administration from a single identity store.

Challenges

Specific challenges associated with aggregating multiple identity stores include:

• Discovering all of the managed identity stores in the organization.
• Agreeing to aggregate identity stores and synchronize information.
• Choosing which attributes are owned by which identity stores.
• Achieving cross-department collaboration among human resources, IT, legal, and other participating business divisions.
• Determining the authoritative source of various attributes that form the digital identity used across the organization.
• Creating a global view of identity information for the organization.
• Auditing changes through a global view of all the organization's identity information.
• Synchronizing identity information across different identity stores within the organization.

The "Identity Aggregation and Synchronization" paper in this series provides more information on this topic.

Automating Provisioning and Deprovisioning

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.

Benefits

The benefits of automated provisioning and deprovisioning include:

• Reduced costs through automatic creation and deletion of accounts in multiple identity stores.
• Increased productivity by reducing the time required to create accounts, passwords, and access rights for new employees.
• Automated generation of necessary attributes, such as mailboxes and account names.
• Easier group membership management.
• Easier role management.
• Increased security by ensuring that employees who leave the organization have all their access rights withdrawn immediately.

Challenges

The challenges of automated provisioning and deprovisioning include:

• Determining the business process that leads to provisioning.
• Determining what departments and approvals are necessary for provisioning new accounts.
• Addressing business process delays that affect timely provisioning and secure deprovisioning.
• Replacing the existing manual tasks with automated processes that include workflow and auditing.
• Provisioning digital identities to multiple identity stores.
• Creating and managing a consistent set of entitlements for users across applications with different identity stores or authorization mechanisms.
• Collecting the necessary information quickly to ensure prompt provisioning.

Automating Group Management

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.

Benefits

The benefits of automated group management include:

• Increased security resulting from greater control of group memberships and entitlements.
• Assignment of employees to the correct groups during provisioning.
• Removal of accounts from groups when users leave the organization, change roles, or move between departments.
• Creation of query-based groups, such as distribution lists of all direct reports for a particular manager.

Challenges

The challenges of automated group management include:

• Identifying the appropriate security and distribution groups.
• Standardizing on attribute values to avoid unnecessary creation of query-based groups.
• Implementing a suitable audit process to keep track of group creation and membership.
• Complying with regulatory requirements.

Consolidating Identity Stores

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.

Benefits

The benefits of consolidating identity stores include:

• Reduced management overhead.
• Reduced TCO by eliminating servers and licenses.
• Reduced server maintenance requirements.
• Less costly hardware and software upgrades.
• Easier application deployment.

Challenges

The challenges of consolidating identity include:

• Creating an aggregate schema in a single identity store.
• Differences between LDAP or other protocol implementations on different identity stores.
• Application migrations.

Providing Password Management and Synchronization

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.

Benefits

The benefits of password management and synchronization include:

• Reduced administration and support costs, because Helpdesk staff do not have to reset user passwords for multiple identity stores.
• Increased security by limiting the number of passwords users must remember and reducing the likelihood that users will write passwords down.
• Increased security resulting from consistent password policy application with regard to policy elements such as password length and complexity requirements.
• Reduced idle time while users wait for support from the Helpdesk to reset their passwords.

Challenges

Password management and synchronization challenges include:

• Coping with multiple password policies that have differing criteria for length and complexity.
• Dealing with password expiry and history intervals across multiple platforms.
• Determining which systems should not be involved in password propagation due to insecure identity stores or authentication techniques and other weaknesses.
• Capturing password changes from multiple platforms, if required.
• Connecting to and transmitting updated passwords securely to target identity stores.
• Ensuring users are who they say they are when requesting a password reset.
• Ensuring that newly reset passwords are sent in a secure fashion to the end user.
• Dealing with applications and services that have hard-coded or locally configured passwords.

The "Password Management" paper in this series provides more information on this topic.

Enabling Interoperability and Single Sign On

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:

• Integrating with the server operating system (used by products such as Microsoft Exchange Server 2003 and SQL Server 2000).
• Using a secure, standards-based authentication protocol such as the Kerberos version 5 authentication protocol.
• Using LDAP authentication and authorization for applications or platforms that do not support the Kerberos version 5 protocol.
• Employing credential mapping and Enterprise SSO (used by products such as Microsoft BizTalk® Server 2004, SharePoint Portal Server 2003, and Host Integration Server 2004).
• Synchronizing user names and propagating passwords across multiple platforms and applications. This method does not provide true SSO, but reduces the requirement for users to remember multiple user names and passwords; it is enabled through identity synchronization and password management improvements.
• Implementing Web SSO for intranet and extranet scenarios.

Benefits

Interoperability and single sign on benefits include:

• Streamlining application deployment.
• Achieving higher standards for authentication and data security on the network.
• Reducing the time users spend repeatedly authenticating to multiple identity stores through Intranet SSO.

Challenges

The challenges of interoperability and single sign on include:

• Choosing the right mechanisms for the platforms found in the organization.
• Choosing between Web and network SSO mechanisms where both options are available.
• Choosing how and when to use LDAP directory services for authentication and authorization.
• Choosing when to reconfigure applications and platforms for implementing password propagation.
• Differences in LDAP protocols or schema implementations.
• Dealing with minor variations in the implementations of standards-based authentication mechanisms.

The "Intranet Access Management" paper in this series provides more information on interoperability and intranet SSO.

Strengthening Authentication Mechanisms

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.

Benefits

The benefits of strengthening authentication mechanisms include:

• Increased security.
• Alignment with regulatory requirements that require additional validation when accessing resources.

Challenges

The challenges involved in strengthening authentication mechanisms include:

• Balancing the cost of additional infrastructure against the need for improved security.
• Integrating stronger credential mechanisms and authentication protocols across different platforms and applications.
• Avoiding increased end-user and management complexity. Multi-factor mechanisms often increase the number of things that can go wrong (such as users losing smart cards or forgetting their PINs).
• Minimizing the costs and resources associated with deploying hardware to support credentials such as smart cards and OTP tokens.

Improving Access for Employees, Customers, and Partners

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.

Benefits

The main benefits of improving access include the following:

• Rapid application development.
• Faster application deployment.
• Increased control of access to resources.
• Better end user experience.
• Reduced administrative overhead.

Challenges

The challenges in improving access for external users are considerable, and include:

• Integrating with existing applications.
• Choosing appropriate identity stores.
• Choosing the appropriate authentication mechanisms for each class of user.
• Choosing an appropriate authorization model.
• Scaling authentication and authorization mechanisms.
• Managing identities for many partners and customers.
• Granting users access to appropriate resources, based on the role they play in the organization and the applications they use.
• The complicated nature of establishing trust between partner organizations.

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.

Establishing Security Auditing Policy

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.

Benefits

The benefits of establishing a security auditing policy include:

• Reduced effects of undergoing an external security audit.
• Improved ability to execute forensic operations should a security attack occur.
• Improved ability to detect attacks in real time, thus alerting administrators to initiate emergency procedures.
• Increased ability to retroactively enforce policies that are difficult to enforce at the time of occurrence.

Challenges

The challenges of establishing a security auditing policy include:

• Different auditing mechanisms in platforms and applications.
• Different auditing capabilities with varying degrees of specificity.
• Different audit requirements for different business units of an organization.
• Consolidating auditing reports in a central location.
• Filtering through volumes of information.
• Generating meaningful reports.
• Archiving large amounts of auditing data.

Updating Software Procurement Standards

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.

Benefits

The benefits of updating software procurement standards include:

• Rapid deployment of new applications.
• Ease of integration with the identity and access management infrastructure.
• Lower TCO.
• Increased security.
• Reduced training for end users.
• Increased productivity for end users.

Challenges

The challenges of updating software procurement standards include:

• Finding the right software with the right features.
• Knowing which optional components to use or purchase.
• Selecting software to maximize security.
• Selecting software to maximize productivity.

Establishing Software Development Standards for Identity Use

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.

Benefits

The benefits of establishing software development standards for identity use include:

• Applications do not create new identity management problems.
• Applications can be developed more rapidly.
• Reduced administrative costs.
• Increased security through a smaller attack surface.

Challenges

The challenges of establishing software development standards include:

• Providing an authoritative source for identity information that new applications can capitalize on.
• Requiring and ensuring that applications use existing identity stores, as well as existing authentication and authorization capabilities.
• Creating and publishing clear guidelines, integrated with any Software Development Life Cycle (SDLC) methodologies, on how applications must integrate with the identity and access management infrastructure.
• Training internal and external developers how to follow these guidelines.

Developing and Migrating Identity-Aware Applications

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.

Benefits

The benefits of developing and migrating identity-aware applications include:

• Reduced administrative overhead for managing identities.
• Increased security.
• Consistency across applications.

Challenges

The challenges of developing and migrating identity-aware applications include the following:

• Understanding how applications work so that decisions can be made on how best to integrate them.
• Selecting a platform for migrating applications.
• Choosing a language or developer environment for application development.
• Choosing an identity store that meets organizational and application requirements.
• Selecting authentication and authorization techniques to meet requirements.

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.

Microsoft Identity and Access Management Technologies

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.

Privacy policies are influenced by your organization, industry, and country/region of operation. These policies define reasonable steps to protect the personal data in your organization's identity stores. National and international legislation, such as The Health Insurance Portability and Accountability Act of 1996 (HIPAA) in the United States, the Data Protection Act of 1998 in the United Kingdom, the Data Protection Directive 95/46/EC in the European Union, and international Safe Harbor agreements and principles play a significant role in establishing privacy policy.

Directory Services

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.

Directory Services in Microsoft Technologies

Microsoft started supporting directory services on the Microsoft® Windows® platform when Windows NT® 3.1 was introduced. Current directory services from Microsoft include:

• The Microsoft Active Directory® directory service, which is an integral part of Windows 2000 Server and Windows Server™ 2003.
• Active Directory Application Mode (ADAM).

For more information on Microsoft directory services, see Chapter 4, "Directory Services," later in this paper.

Identity Life-Cycle Management

There are several related processes for managing users, their entitlements, and their credentials. These processes include:

• Identity integration services, including aggregation and synchronization.
• Provisioning, including the management of related processes that occur before, during, and after provisioning (often called "workflow").
• Delegated administration, such as account management by partner staff.
• Self-service administration, such as user-initiated entitlement requests.
• Credential and password management, including end-user password change and Helpdesk password resets.
• Deprovisioning, including the deactivation or deletion of an account.
• Managing groups

Identity Integration Services

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.

Provisioning

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

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.

Delegated Administration

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.

Self-Service Administration

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.

Credential Management

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

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

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.

Managing Groups

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.

Identity Life-Cycle Management in Microsoft Technologies

Microsoft technologies for identity life-cycle management include:

• Active Directory, including the Active Directory Users and Groups Microsoft Management Console (MMC) and built in delegation of administration capabilities.
• Microsoft Identity Integration Server 2003, Enterprise Edition (MIIS 2003 SP1), which includes the following specific capabilities:
  • Provisioning
  • Password synchronization and web interfaces for password reset and change
• The Identity Integration Feature Pack for Microsoft Windows Server Active Directory.
• Self-service and automatic X.509 certificate enrollment.
• Services for UNIX 3.5 (SFU 3.5).
• Services for NetWare.
• Windows Credential Manager.
• IdM Notification service, Group Management Web application, and Group Populator tool in the Identity and Access Management Tools and Templates.

For more information on identity life-cycle management with Microsoft technologies, see Chapter 5, "Identity Life-Cycle Management," later in this paper.

Access Management

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

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

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:

• User names and passwords
• Personal identification numbers (PINs)
• X.509 digital certificates
• One-time passwords
• Biometrics (for example, fingerprint or iris scans)
• Smart cards
• Electronic passports
• Hardware tokens

Comparing Strong and Weak Authentication Techniques

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.

Single Sign On

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.

Authentication in Microsoft Technologies

Microsoft Windows Server 2003 Active Directory provides integral support for a range of authentication methods, including:

• Public key infrastructure (PKI)-based authentication
• The Kerberos version 5 authentication protocol
• X.509 certificate mapping
• Microsoft Passport
• Windows NT LAN Manager (NTLM) challenge/response
• Extensible Authentication Protocol (EAP)
• Secure Sockets Layer (SSL) 3.0 and Transport Layer Security (TLS) 1.0 encryption
• Support for smart cards with X.509 certificates

Windows Server 2003 Internet Information Services 6.0 (IIS) supports all of the above in addition to the following:

• Digest authentication
• Forms-based authentication
• Basic authentication

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

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.

Access Control Lists

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."

Security Groups

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.

Roles

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.

Authorization in Microsoft Technologies

Windows Server 2003 provides integral support for a range of authorization methods. Microsoft authorization technologies and supporting components include:

• Access control lists (ACL)
• Role-based access control through Windows Authorization Manager
• IIS 6.0 URL authorization
• ASP.NET authorization

For more information on Microsoft authorization technologies, see the "Authorization" section in Chapter 6, "Access Management" later in this paper.

Trust

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.

Federation

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.

Trust and Federation in Microsoft Technologies

Microsoft Windows provides support for trust and federation through the following technologies:

• External trusts in Windows NT 4.0 and Windows 2000 Server.
• Cross-forest trusts in Windows Server 2003.
• The Kerberos version 5 authentication protocol.
• Shadow accounts.
• PKI trusts.
• Active Directory Federation Service (ADFS) in Windows Server 2003 R2.

Security Auditing

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.

Security Auditing in Microsoft Technologies

Microsoft Windows provides a security event log for recording interesting security events such as:

• Authentication events.
• Authorization events.
• Changes to directory objects.

Microsoft Operations Manager (MOM) 2005 SP1 can consolidate event logs in an environment and provide useful auditing reports.

Applications

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

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.

Summary

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

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.

Active Directory

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.

Managing User Rights in Active Directory

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:

• Security. You can implement changes to user access rights across the entire network in one step, reducing the possibility of inadvertently leaving a back door open to sensitive information.
• Management Complexity. For each user, there is one location where entitlements and credentials can be managed. Moreover, this approach simplifies user access because only one logon and password is required to access the network and all resources within it.
• Cost Containment and Productivity. A single system for managing groups and roles eliminates the redundancy of network administrators granting and monitoring privileges on each individual system and application.

Group Policy

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:

• Registry-based policies for Windows operating systems and components.
• Security options for local computer, domain, and network security settings such as password and account policies.
• Software installation and maintenance options to centrally manage the adding, updating, and removal of applications.

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.

Using Directory Services Markup Language

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.

Active Directory Application Mode

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:

• Storing personalization data
• Storing data that needs frequent updating
• Supporting directory-enabled applications that require aggregation of profile data from multiple forests or a different organization such as OU structure
• Enabling directory migration

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.

Identity Life-Cycle Management

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

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:

• Microsoft® Identity Integration Server 2003, Enterprise Edition (MIIS 2003 SP1).
• Identity Integration Feature Pack 1a for Microsoft Windows Server™ Active Directory.

MIIS 2003 SP1 augments the Microsoft Active Directory® directory service by providing broad interoperability capabilities that include:

• Integration with a wide range of identity repositories.
• Provisioning identity information across multiple stores.
• Associating identity information, automatically detecting updates, and synchronizing the changes across systems.
• Transforming data from one identity store to fit the schema in another store.

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:

• Services for UNIX. This product augments Active Directory records to include UNIX credentials and entitlements, allowing you to administer UNIX users and groups in a manner identical to Windows users and groups. The product also enables synchronization of passwords between UNIX and Active Directory.
• Services for NetWare. This product provides a highly flexible service that offers a complete interoperability solution between Active Directory and Novell eDirectory 8.7 and its bindery. The product reduces the cost of identity and access management through two-way password synchronization between Active Directory and Novell systems.
• Services for Macintosh. This product enables an integrated component of Microsoft Windows Server to allow computers running Windows-based and Macintosh operating systems to share files and printers. In addition, Windows Server can function as an AppleTalk router. Services for Macintosh also includes the Microsoft User Authentication Module (MSUAM), which provides a secure SSO mechanism for Macintosh clients to access applications running Windows Server 2003.
• Host Integration Server (HIS). This product provides application, data, and network integration to extend access from Windows-based operating systems to legacy host systems such as AS/400 and mainframes running DB2, RACF, ACF2 and other operating systems. HIS can also map user IDs and passwords from a Windows operating system to a host system without changing the host security environment.

Provisioning

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.

Adding Workflow to Provisioning

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.

• MIIS 2003 SP1 rules extensions. You can implement simple workflow-driven provisioning using MIIS 2003 SP1 rules extensions. A change of state in a connected database, such as an HR application, would then kick off an automated provisioning sequence. The rules extensions in MIIS 2003 SP1 govern the resultant creation of digital identities in the appropriate identity stores. However, this mechanism would not allow for any manual approval processes.
• Simple workflow. Another option would be to implement a simple workflow application, probably with a Web-based interface that allows manual workflow steps within the automatic provisioning process. This option could include the scenario where a new employee requires manager approval, but a manager can only approve his or her new employees. When the HR department creates a new employee account, they enter the manager details to send a notification e-mail to the relevant manager. When the manager logs on to the Web site, they see a list of new employees to approve. Granting approval then creates the new user accounts in all the relevant identity stores.
• Microsoft BizTalk® 2004 orchestration. BizTalk 2004 orchestration provides advanced workflow capabilities for complex heterogeneous environments.

Provisioning Shadow Accounts

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.

Delegated Administration

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.

Self-Service

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.

Credential Management

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.

Password Management

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:

• MIIS 2003 SP1. This product provides for password propagation between connected directories through a Windows Management Instrumentation (WMI) interface. The WMI interface is used by pre-built Web pages for password change and reset that ship with MIIS or by a custom solution that uses other capabilities of Windows, such as the password notification filter described in the final item on this list.
• Services for UNIX. This product performs password propagation between Active Directory and the UNIX platform.
• Services for NetWare. This product performs password propagation between Active Directory and NetWare.
• Host Integration Server (HIS). This product performs password synchronization between Active Directory and various host-based systems.
• Active Directory Custom Password Notification Filters. The Windows Platform Software Development Kit (SDK) and the "Password Management" paper in this series include information on developing a custom password notification filter to implement enhanced password management services.

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:

• Helpdesk reset. Helpdesk personnel reset user passwords through the Web interface provided with MIIS. You can configure the password change to flow to Active Directory and other directories supported by MIIS 2003 SP1 for password management.
• Web initiated changes. Users change passwords through a common Web-based password change application. The password is then distributed to all MIIS-supported directories and systems, including Active Directory.
• Windows initiated changes. Users change passwords through the Change Password dialog box on Windows-based client computers. The Active Directory password notification filter obtains the changed password and then distributes it to other systems through MIIS 2003 SP1. This facility is not currently built in into MIIS 2003 SP1 but can be implemented using Visual Studio .NET with custom coding, as shown in the sample included with the "Password Management" paper in this series.
• Other System initiated changes. Users change passwords through non-Windows-based operating systems. The password is obtained through mechanisms supported on the operating system and then distributed through MIIS 2003 SP1. This capability is only supported through the use of non-Microsoft applications that integrate with Active Directory or MIIS 2003 SP1.

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

Access management consists of the processes and technologies for controlling and monitoring access to resources consistent with governing policies. Access management includes:

• Authentication
• Authorization
• Trust
• Security auditing

Authentication

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.

Windows Authentication Services

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 Authentication Services Architecture

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.

Security Support Provider Interface

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.

Kerberos Authentication

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:

• You can establish a trust relationship between a Windows domain and an MIT-based Kerberos version 5 protocol realm. This relationship enables clients in this realm to authenticate through the trust mechanism to network resources in the Windows domain.
• Non-Windows clients and servers can use Active Directory accounts to obtain authentication from a domain controller.

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.

Secure Sockets Layer 3.0 and Transport Layer Security 1.0

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:

• The server certificate is valid.
• The server has proved possession of the appropriate private key associated with the server's X.509 certificate.
• The server being authenticated is the same server specified in the certificate.

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.

Passport Authentication

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

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

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.

Basic Authentication

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.

Single Sign On

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:

• Desktop integrated SSO.
• Web SSO.
• Credential mapping, or Enterprise SSO.

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.

Desktop Integrated Single Sign On

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.

Web Single Sign On

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:

• The inherent difficulties in deploying an Internet-facing Key Distribution Center (KDC), such as an Active Directory domain controller.
• The fact that many browsers do not support Kerberos authentication over HTTP.
• Inherent vulnerabilities in the KDC protocol

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.

Credential Mapping and Enterprise Single Sign On

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 Credential Manager

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:

• Username/password combinations for Kerberos version 5 protocol and NTLM authentication.
• X.509 digital certificates for client authentication using SSL/TLS.
• Microsoft Passport credentials for Web authentication.

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

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.

Windows Impersonation and Access Control Lists

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:

• Performance. For services that deliver content to many different users at a time, the cost of using impersonation to switch contexts can generate additional server load that may affect application scalability.
• Flexibility. Using the impersonation model, it is not possible for the application developer or service administrator to create new groups, or roles, for users without changing the group memberships at the domain level. Domain administrators resist creating lots of groups for a single application to use, which results in application developers having to work with what currently exists.
• Business rules. The impersonation/ACL model expresses authorization for objects adequately, but it is hard to describe business rule logic such as time of day or other run-time logic. For example, you may want to enforce an authorization policy that only allows certain individuals to perform a certain action during certain hours.

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.

Windows Server 2003 Authorization Manager

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:

• Simplify application access control administration.
• Provide a simplified and natural development model.
• Enable flexible and dynamic authorization decisions.

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 Authorization

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.

Trust and Federation

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.

Managing Trust Relationships

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.

External Trusts

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.

Windows 2000 Server Forests

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.

Windows Server 2003 Forest Trust

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.

Using Forest Trusts

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.

Using Shadow Accounts Instead of Trusts

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:

• Use a forest or domain trust from the perimeter network (also known as DMZ, demilitarized zone, or screened subnet) to the intranet.
• Create shadow accounts in the perimeter network.

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.

Public Key Infrastructure Trusts

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: E=fred@fabrikam.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 E=fred@contoso.com, where fred@contoso.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.

Qualified Subordination

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.

Implementing Federation

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:

• Which other organizations and users it trusts.
• What types of credentials and requests it accepts.
• Which privacy policies it enforces.

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.

Security Auditing

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.

Auditing Directory Services

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.

Auditing Authentication

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.

Auditing Authorization

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.

Auditing Trusts

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

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:

• Third-party, off-the-shelf, or commercial applications such as Microsoft® Exchange Server 2003.
• Custom or in-house applications written for the organization by developers.

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.

Choosing Applications

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:

• Integrating with the organization's primary directory service.
• Linking to the primary directory service using a standards-based connection.
• Authenticating to another directory service.
• Using a dedicated identity store.

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.

Developing Applications

If you are developing applications in-house, there are three fundamental approaches that application architects and developers need to consider:

• Application integration. Choosing to integrate or interoperate with the infrastructure.
• Identity flowing. Choosing an appropriate combination of the three fundamental models for front-end and back-end authentication.
• Authorization. Choosing a combination of the two fundamental models for authorization.

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.

Enabling Identity Flow

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/Delegation
• Trusted Subsystem
• Credential Mapping

Using the Impersonation/Delegation Model

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.

Using the Trusted Subsystem Model

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.

Using the Credential Mapping Model

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.

Implementing Authorization

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:

• Access control list (ACL)
• Role-based access control (RBAC)

Using Access Control List Model

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.

Using Role-based Access Control

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.

---