Platform and Infrastructure

Chapter 3: Issues and Requirements

Published: May 11, 2004 | Updated: June 26, 2006

To implement an effective identity and access management infrastructure in your organization, you need to choose a technology platform by critically analyzing your organization's requirements against the technology capabilities. This functional analysis ensures that the solution meets your business goals while keeping the platform secure and manageable.

This paper covers these issues by using the fictitious company Contoso Pharmaceuticals. The Contoso Pharmaceuticals scenario is intended to provide insight into the problems that a typical organization might face when addressing common identity and access management issues.

On This Page
Introducing Contoso PharmaceuticalsIntroducing Contoso Pharmaceuticals
Business and Technology IssuesBusiness and Technology Issues
Threats and CountermeasuresThreats and Countermeasures
Platform RequirementsPlatform Requirements

Introducing Contoso Pharmaceuticals

Contoso Pharmaceuticals is a fictional company based in the United States with its headquarters and primary manufacturing facility located in Orlando, Florida. Contoso currently has 5,300 employees and yearly revenues of $3.8 billion.

The company's success rests largely on a corporate culture that focuses on pioneering research and development. Contoso Pharmaceuticals is renowned for its commitment to customer service and its low-cost production facilities. Contoso has experienced strong growth the past two years, fueled partly by acquiring a smaller pharmaceutical supplies company, Fabrikam Ltd. (another fictitious company) in the United Kingdom. Several more such acquisitions are planned to strengthen the parent company's market position.

Information Technology Department

The Contoso IT department consists of several hundred technical and managerial personnel. The 22 full-time system administrators manage more than 500 servers of all types, including computers running Microsoft® Windows®-based server operating systems, Sun ONE Directory Server 5.1 (formerly iPlanet Directory Server), and mainframes running third-party and custom applications. The administrators also manage the company’s Microsoft Exchange Server infrastructure and an internal Contoso portal site for employees. The remaining servers are dedicated to file and print services and database functions.

Administering the company’s Microsoft Windows Server™ 2003 domain controllers and the Microsoft Active Directory® directory service is an important part of daily operations. One of the many tasks that domain administrators perform is provisioning accounts into Active Directory.

Contoso has a large and well-trained Helpdesk operation that supports a twenty-four hour, seven days-a-week operation. Helpdesk operators offer support for applications such as e-mail, word processing, and business applications, as well as password reset assistance for employees locked out of company systems. Contoso also has several infrastructure and security architects who review enterprise-wide and departmental IT requirements to create proposals for IT strategies, investments, and standards.

Operating Systems

A wide range of system platforms and applications make up the Contoso Pharmaceuticals IT infrastructure. Although Windows-based servers and clients make up the majority of its systems, Contoso also has business-critical systems, including servers running Sun ONE Directory Server 5.1, and workstations running Sun Solaris 9. The systems running Sun Solaris 9 are currently managed with Network Information System (NIS).

The Contoso intranet Active Directory design features a single forest with an empty root domain and a single child domain. All of the original Contoso user, service, and machine accounts were migrated to Active Directory from Microsoft Windows NT® 4.0 domains. The company also operates the external Domain Name System (DNS) servers that service the Contoso.com Internet domain. These DNS servers are separate from the internal ones that service the intranet Active Directory forest.

Additional Identity Stores

In its recent acquisition of Fabrikam Ltd., Contoso also acquired multiple infrastructure products, such as Lotus Notes Release 6.5.4 for messaging, and a server running Sun ONE Directory Server 5.1 that provides the authentication and directory services for a custom-developed Web application. These systems are still required to support the business activities of the former Fabrikam employees in the short term. The long term plan calls for migrating the Fabrikam infrastructure into the existing Contoso environment.

Business and Technology Issues

Contoso operates in a highly competitive environment in which time-to-market is a key industry driver. Clinical trials are large investments, and a single day's delay in delivering results or submitting a product for approval by the U.S. Food and Drug Administration (FDA) can cost the company nearly a million dollars. Therefore, interaction with users and partners is a key part of the company's operations. Regulation is another primary consideration, as regulatory fines and penalties can range from millions to tens of millions of dollars.

A major business challenge Contoso faces is to expand both the quality and scope of the organization's interaction with customers, partners, and employees who work remotely. New ways of interacting with customers to get their feedback, and to communicate the advantages of the organization's products, have resulted in many improvements. These improvements involve the product development process to create products better suited to customers' needs, which increases the company's market share. However, historically administration involvement has made this process costly and difficult to maintain.

Contoso understands that improving the technology solutions they use to collaborate with partners will lead to greater efficiencies in the product development process. At the same time, employees are increasingly mobile and need easier access to data necessary for their jobs, both through the corporate network and over the Internet.

Contoso appreciates that an identity and access management platform must improve the infrastructure's manageability and security, specifically in the areas of digital identity management. As a long term objective, the company wants to consolidate duplicate identity stores for separate applications into a centralized identity store that will provide greater administrative efficiency, lower total cost of ownership (TCO), and result in fewer administrative errors and greater security.

However, the Contoso architects and administrators are aware that there are short- to medium-term issues they must address before they can meet these goals, particularly on the security side. The "Threats and Countermeasures" section that appears later in this paper summarizes these security concerns and the countermeasures that can reduce or neutralize the threats.

Contoso Pharmaceuticals has identified the following key requirements in its two-year plan to improve identity and access management:

Provide the best possible technology infrastructure for the rapid development, evaluation, and marketing of the company's products.

Increase the efficiency and security level of the company's IT infrastructure, in particular managing digital identities, to pave the way for additional growth without having to accumulate additional administrative overhead and IT complexity.

Consolidate security and privacy mechanisms and related technologies to meet government regulatory requirements, such as the FDA 21 Code of Federal Regulations (CFR) Part 11 (Part 11), and the Health Insurance Portability and Accountability Act of 1996 (HIPAA).

To fulfill these requirements, Contoso has undertaken a comprehensive review of its most critical applications and processes. The next section identifies each of these key assets.

Key IT Assets

Contoso Pharmaceuticals has identified a number of IT assets that are of the highest importance to the company. The following assets contribute key capacities in addressing central business and technical issues:

The extranet-accessible Sales and Contacts application and the sales employee user accounts.

The extranet-accessible Partner Research application, and the extranet partner identity store.

The extranet-accessible Customer Trial feedback application, and the extranet customer identity store.

SAP application data and SAP user accounts.

Microsoft Exchange e-mail infrastructure and accounts.

Lotus Notes e-mail infrastructure and accounts.

Applications that use the Sun ONE Directory Server 5.1 and UNIX user accounts.

The following diagram summarizes these key assets.

Figure 3.1. Contoso key IT assets

Figure 3.1. Contoso key IT assets

The Extranet Accessible Sales and Contacts Application

The sales force for Contoso spends a significant amount of time out of the office, visiting customers and building new business. The staff needs to track their sales and sales contacts, which is done through a Web application and database hosted in the Contoso perimeter network, also known as the demilitarized zone (DMZ). The information this application maintains is not critically sensitive. However, exposure of this data could cause problems for Contoso and its business partners, and would have a broader impact on the public perception of Contoso's trustworthiness.

Unavailability of the application would create the biggest issue because it would seriously hamper the effectiveness of the sales force.

Sales Employee User Accounts

Individual sales employee user accounts can access sensitive materials within a specific scope through the extranet. These accounts could also be misused to mount an attack on the broader Contoso organization and its IT resources.

The Extranet-Accessible Partner Research Application

Collaboration with research partners is essential to new product development, which Contoso depends on for its future growth. Much of that collaboration takes place through a single application hosted in the Contoso perimeter network. While the data in the application is backed up frequently, a successful attack on the application could cause serious problems for Contoso — disclosed research data could lead to a competitive disadvantage and possible regulatory action.

The Extranet Partner Account Store

Partner accounts have less access to Contoso IT resources than employee accounts. Partner accounts only allow access to the Partner Research application. However, compromise of a single account or the entire account store would likely lead to a compromise of at least part of the application. Again, this could lead to competitive disadvantage and possible regulatory action.

The Extranet-Accessible Customer Trial Application

The success of Contoso products depends on early customer feedback during the product development cycle. One of the ways Contoso takes advantage of technology is by providing a Web application whereby customers can easily provide feedback on products in the trial phase.

Contoso collects nearly 50 percent of its customer feedback through the Customer Trial feedback application. Disruption of this application would severely hamper the company's ability to complete trials and submit the results to the FDA, which could result in regulatory action if the FDA had reason to believe that application security was compromised.

The Extranet Customer Account Store

Customer accounts have less access to Contoso IT resources than employee accounts. Customer accounts only allow access to the Customer Trial feedback application. However, a compromise of a single account or the entire account store would likely lead to a compromise of at least part of the application. Another contributing factor would be the damage done to customer relations due to the perception that poor security practices at Contoso could leak customer privacy information. This could again result in regulatory action against the company.

SAP Application Data and SAP User Accounts

Contoso has implemented several SAP – based enterprise resource planning (ERP) applications. Some of these applications serve critical business functions and distribute confidential data to users. Compromise of this data could hamper the company's ability to compete in the marketplace, or result in significant fines from violating regulatory requirements.

Individual user accounts can be used to access sensitive materials within the scope of the SAP application. This could result in financial information leaks to investors that could harm Contoso.

Microsoft Exchange E-mail

Contoso uses Microsoft Exchange Server and Microsoft Outlook® for internal and external e-mail. Compromise of this data could lead to competitors gaining commercially sensitive information, and could also lead to regulatory action.

Lotus Notes E-mail

Fabrikam Ltd. used Lotus Notes for internal and external e-mail, and this environment was migrated during the merger with Contoso. Compromise of this data could lead to competitors gaining commercially sensitive information, and could also lead to regulatory action.

Sun ONE Directory Server 5.1 and UNIX User Accounts

Sun ONE Directory Server 5.1 provides directory services and authentication support for a custom Web application that Fabrikam uses. Compromise of this application and its data could lead to competitive disadvantage and possible regulatory action.

Individual UNIX user accounts can access sensitive materials within a specific scope at Contoso. These accounts could also be misused to mount an attack on the broader Contoso organization and its IT resources.

Completing the Analysis

After completing the analysis of their IT assets, Contoso identified the following issues with their current identity and access management platform:

No clear strategy exists for reducing the cost and complexity of managing digital identities in the Contoso environment.

Provisioning and deprovisioning users for customer applications is not standardized.

Applications under development complicate the IT infrastructure when they add more identity stores.

Authentication mechanisms are often custom-developed for each application, or are obsolete mechanisms that are standard on legacy systems. In either case, these mechanisms are expensive to implement, and are often not sufficiently secure against the many threats found in today's computing environment.

Application authorization is a concern because application developers often implement custom mechanisms, which adds to development and maintenance time and cost.

Threats and Countermeasures

Many identity and access management security issues are actually security vulnerabilities. A vulnerability is a weakness in an information system or its components that could be exploited to produce a security breach. Vulnerabilities may result from problems with people, processes, or technology. Examples can include system security procedures, hardware design, or internal controls. Vulnerabilities can arise at any point in a network's defenses, and assessment is usually part of an overall security review.

Current Threats

Contoso Pharmaceuticals has just completed a major security review of its network. Part of the review included categorizing threats to the network. When creating the scope for its identity and access management project, Contoso decided to consider first and foremost the potential attacks from internal and external sources. Internal threats cover those that target the intranet, while external threats deal with those specific to the extranet.

Security Issues and Vulnerabilities

The Contoso environment has a number of vulnerabilities that relate to the business and technology issues covered earlier in this chapter. From a security perspective, the Contoso identity and access management solution must address the following concerns:

Contoso must make more of its business information available through Internet-facing applications, but the security mechanisms implemented on the internal network are not strong or consistent enough to allow widespread access to this network.

Security breaches at Contoso are difficult to investigate because there is only incomplete, disjointed, and scattered forensic evidence available through security audit logs.

Existing application identity stores are not secure, and an attack against the user accounts they control is both possible and likely to occur.

Existing application authentication mechanisms are not secure, and an attack against the authentication mechanisms is both possible and likely to occur.

Existing application authorization mechanisms are poorly designed, and an attack against these mechanisms is both possible and likely to occur.

The first vulnerability highlights the constant challenge with identity and access management: systems that interface with customers, partners, or employees can only bring benefits if those people can access them. However, the very act of granting access increases the security risk.

Breaking these categories down further, the Contoso security review identified the following process and account vulnerabilities that are open to exploitation from internal and external sources:

Account provisioning

Account deprovisioning

UNIX workstation accounts

SAP authentication

SAP application data protection

Employee accounts

Partner accounts

Customer accounts

The employee, partner, and customer account vulnerabilities are similar, but the employee accounts vulnerability has more serious implications.

Account Provisioning

Inefficient or incomplete provisioning is not a direct security threat because nominally it only sets the stage for the inability to access application and network resources. However, inadequate account provisioning mechanisms can lead to other practices that are a direct threat to security, such as account sharing or allowing anonymous access to valuable assets.

Account sharing is the main risk associated with the account provisioning vulnerability. A recent report by the Helpdesk at Contoso states that this widespread practice is causing high volumes of support incidents due to failed logon attempts that cause accounts to become locked out, and multiple users simultaneously using the same identity to access resources.

An anonymous follow-up survey by the Contoso IT department found that the number one reason for users sharing accounts is that new employees are not provisioned quickly enough to access applications and network resources. This identity sharing was especially true among contract staff, who frequently complete several months of work before receiving the proper access they need to do their work.

Supervisors address this problem by giving contingent staff user names and passwords established for different users, who may or may not still be working at Contoso. This nonstandard practice makes it impossible for application or network administrators to audit who or what is using network resources or accessing application data. Some supervisors have even admitted to providing subordinates with their own account and password information, thus allowing the staff to access resources and data at elevated entitlement levels.

Account Deprovisioning

The account deprovisioning vulnerability is a far more serious concern. Former employees or external hackers could use old accounts left over in application identity stores or directories to gain unauthorized access to, or corrupt confidential and valuable data.

The main risk associated with the account deprovisioning vulnerability is stale accounts. A recent audit of an application-based identity store revealed that accounts were still active for employees that had left the company over three years ago. Stale accounts provide a backdoor which either a former user or an attacker could use to attack application data.

While the vulnerability from former owners of the account is obvious, it is also important to consider that the three-year-old account has not had a password change during this period. Stale accounts increase the opportunities for attackers to mount successful brute-force attacks on these static passwords, particularly if there is no policy in place to enforce password changes and account lockouts. These accounts can then be used to compromise or corrupt application data critical to Contoso business processes.

UNIX Workstation Accounts

Contoso has 40 workstations running Sun Solaris 9 that personnel in the Accounting department use to perform their daily functions. The Solaris workstations are administered through a single Network Information Service (NIS) domain.

Sun Microsystems developed NIS to centralize the administration of UNIX systems. The general NIS functionality is analogous to Windows NT 4.0 domains. NIS is very popular because it is easy for a knowledgeable UNIX administrator to set up and administer, it scales reasonably well, and it is supported by nearly all forms of UNIX. Unfortunately, NIS does not have good security characteristics.

One of the biggest security concerns with NIS is that it does not provide the ability to enforce password expiration or password complexity. In addition, all member servers in a NIS domain receive a copy of the password file that contains the encrypted password of every user in the domain.

Weak or old UNIX passwords are a threat to the security of the network, because they allow an attacker to quickly obtain a user account and password combination. After they have been compromised, user accounts can be used to escalate an attack on systems that might only be protected against anonymous attacks. Tools that apply brute-force and dictionary attacks against password files are widely available on the Internet. The UNIX user accounts at Contoso are not subject to password policy enforcement, and the NIS password policy file is widely distributed.

SAP Authentication

SAP is a well-known and widely deployed ERP application server and Contoso has implemented several such applications. Several of these applications serve critical business functions and distribute confidential data to users. Therefore, this data is critical to the company's business. Application availability interruptions, data corruption, or loss or exposure of data could cost Contoso millions of dollars.

Legacy authentication mechanisms and data access protocols that SAP provides do not have the capability to protect authentication secrets (passwords) when they are used to access the application. SAP user passwords can be intercepted by anyone with a network tap on a user's network segment.

SAP Application Data Protection

By default, client/server SAP application data sent over the network is unprotected. Any attacker who can view the network traffic on the SAP user's network segment can compromise SAP application data by stealing it or introducing incorrect data with potentially severe effects on the consistency of the data maintained in the SAP system.

The data exchanged between users and the SAP application server is critical to the company's business. Again, in this case application availability interruptions, data corruption, or loss or exposure of data could cost Contoso millions of dollars.

Employee Accounts

The employee accounts vulnerability involves two main risks — authenticating with plaintext passwords, and storing plaintext passwords on servers that are not secure. These vulnerabilities apply to both the internal and external networks.

When Contoso Sales department employees authenticate to the external Sales and Contacts application, they often do so by using their enterprise account credentials. This can expose those credentials to external threats through a compromise of the Web server located in the perimeter network, or to application administrators who cannot be trusted with such information.

Authenticating with Plaintext Passwords

An analysis of password use in the Contoso scenario revealed that employees of the Contoso sales organization used their enterprise account passwords to access a Web application hosted on servers in the perimeter network. The sales application uses Basic authentication over Secure Sockets Layer (SSL) to grant access to the application. While SSL does a good job of protecting the user's password on the network, the plaintext password is present on the Web application server. If the Web application server was compromised, the plaintext user passwords would be accessible.

Furthermore, there was no official company or departmental policy on whether the password for this application should or should not be the same as the user's enterprise account password; so many employees use the same password because remembering another password is difficult.

With valid account passwords, an attacker can gain unauthorized access to files and services that could not be attained otherwise. If the user's extranet account password is the same as their enterprise account password, then even more information could be obtained.

Storing Plaintext Passwords on Servers That Are Not Secure

To authenticate Sales and Contact application users, the Sales and Contact application compares the plaintext password acquired through Basic authentication to a password value in a Microsoft SQL Server database located in the perimeter network. With valid account passwords, an attacker can gain unauthorized access to files and services that could not be attained otherwise.

The computers running SQL Server are protected from direct access via the Internet by IP Security Protocol (IPSec) policy and physical network design. An external attack on a SQL Server would have to be a multi-tier attack through the externally-facing Web servers. However, because there is no policy or technology in place to prevent application administrators from accessing employee passwords, the internal attack is much easier to mount and simply requires an application administrator to skim the desired information as the application is running.

Partner Accounts

Contoso has an application for its research partners that uses password-based authentication. The application has a local identity store of user names and passwords that is kept in a database hosted on another computer, separate from the Web servers hosting the application. This design presents a number of identity manageability problems, but also presents security vulnerabilities as well.

Foremost among these is the security vulnerability of the accounts database. The accounts database stores the passwords in plaintext in a single location for all of the accounts that use the application. If unauthorized users gain access to the database, then they could compromise all of the accounts. In addition, during authentication, each Web server makes an unauthenticated request to the database to extract the user's password to compare it to the credential presented by the user. This process means that the plaintext password is visible in the physical perimeter network, which constitutes a significant risk.

Customer Accounts

Contoso also has an application for its customers that uses password-based authentication. The considerations and risks for this vulnerability are identical to those of the Partner accounts vulnerabilities.

Security Countermeasures

With a good understanding of the vulnerabilities in your own organization, you can select countermeasures to address them. Choosing appropriate security countermeasures depends on the vulnerabilities you need to address, and the criticality factor and likelihood of each being exploited.

Correctly choosing suitable countermeasures is particularly important, as each countermeasure can address multiple vulnerabilities. In addition, implementing a countermeasure may have beneficial effects in addressing other minor vulnerabilities that were not part of the initial threat assessment. These countermeasures drive the requirements for a platform selection and how it will be used.

The security requirements for the Contoso Pharmaceuticals action plan include using the following:

Automatic provisioning and deprovisioning of user accounts.

The Kerberos version 5 authentication protocol.

Generic Security Services Application Programming Interface (GSS – API) and Kerberos protocol integration.

Client certificate authentication with encryption.

Password authentication to Active Directory.

Microsoft Passport authentication to Active Directory.

At the end of each countermeasure section, a list details the vulnerabilities they address.

Contoso has also taken steps beyond implementing these identity and access management countermeasures, including:

Implementing extensive defenses against virus threats, such as block lists and attachment filtering, as well as server and workstation virus scanners.

Improved operational procedures and training policies designed to reduce the threat of accidental system misuse.

Physical network and services design improvements to reduce mechanical threats, such as power outages, hardware failures, and network malfunctions.

Well-defined contingency plans in case of natural disasters such as fires, flooding, and earthquakes.

Automatic Provisioning and Deprovisioning

Automating account provisioning and deprovisioning not only provides significant productivity gains, but can close several security loopholes. The most significant of these is when an employee leaves the company, and the organization fails to deactivate his or her account.

Account provisioning can be automated given an authoritative source of employee status, and a known set of application identity stores that administrators can centrally manage. For example, you can script a Human Resources (HR) application to generate an employee status table on a daily basis. You can then use an identity integration product to consolidate the HR application employee status with digital identity states in stores such as directories and applications.

Deployment Considerations

Identity integration products typically come with a number of connectors, or management agents, that provide a communication channel allowing for identity information synchronization. In addition, you need one or more authoritative sources for digital identities. Typically the sources can be a single (or collection of) HR systems, contractor databases and others, but the scenario for every organization will differ to some degree.

The Contoso Scenario

Contoso has identified its HR application as the authoritative source of information for identity status. The company has elected to deploy an identity integration and provisioning product to manage identity data in different stores, such as Active Directory, Lotus Notes Release 6.5.4, and Sun ONE Directory Server 5.1.

When the HR application indicates that a new employee should be provisioned, the system will add or activate the matching account in the other systems. When the HR application reports an employee's status as terminated, then the system will remove or deactivate the matching account in the other systems.

Security Issues Addressed

Implementing an identity integration product can address security issues with account provisioning and deprovisioning.

The "Identity Aggregation and Synchronization" paper in this series covers how to implement Microsoft Identity Integration Server 2003, Enterprise Edition with Service Pack 1 (MIIS 2003 with SP1), an identity integration product that provides the ability to automatically provision and deprovision employee accounts.

Using the Kerberos Version 5 Authentication Protocol

The Kerberos version 5 authentication protocol, introduced for Microsoft platforms in Microsoft Windows 2000, offers many desired security characteristics for a network authentication protocol. The Kerberos version 5 protocol is highly secure, utilizing the latest in cryptographic technologies and protocol design. The Kerberos protocol also provides better performance, as its design takes advantage of a central authentication facility, the Kerberos protocol Key Distribution Center (KDC), while offloading the work of the KDC through the use of relatively long-lived tickets.

Deployment Considerations

In the Contoso scenario, the KDC is on each domain controller running Windows Server 2003 Directory and Security Services. Kerberos interoperability provides the additional benefit of a single sign on (SSO) experience for Windows-based operating systems and possibly even UNIX clients.

The Contoso Scenario

The Contoso administrators plan to configure UNIX workstations to use the Kerberos version 5 protocol to authenticate to Active Directory domain controllers. They also plan to configure SAP R/3 to require Secure Network Communications (SNC) authentication in conjunction with the Kerberos version 5 protocol.

Security Issues Addressed

Implementing the Kerberos version 5 authentication protocol helps address security issues in the following areas:

UNIX workstation accounts.

SAP authentication.

SAP application data protection.

The "Intranet Access Management" paper in this series covers how to implement the Kerberos version 5 protocol, including how to configure SNC authentication on SAP R/3 and how to configure UNIX workstations to authenticate by using Kerberos and Active Directory.

Using GSS-API and Kerberos Integration with SAP

SAP R/3 version 4.0 offers support for SNC. One mode of SNC allows for integration with GSS-API, and through GSS-API, you can use the Kerberos version 5 protocol.

One mode of SNC allows for integration with GSS-API, as described in IETF RFC-2078. GSS-API provides for both data confidentiality and integrity when used with a security protocol that also supports these capabilities. Kerberos version 5 is such a protocol. Configuring the SAP Application Server and the SAP graphical user interface (GUI) client to use both SAP SNC and the Kerberos version 5 protocol will fully protect the SAP application data from interception.

Deployment Considerations

SAP R/3 does not implement the KDC, but instead uses the KDC already installed in the network environment. In the Contoso scenario, the KDC is on each domain controller running Windows 2000 Server or Windows Server 2003 with Active Directory. You must configure SAP to use the Kerberos version 5 authentication protocol. However, after you have configured this, Kerberos interoperability has the additional benefit of providing the foundation for SSO on Windows-based and UNIX – based client operating systems.

The Contoso Scenario

In the Contoso scenario, the administrators configured SAP R/3 to use SNC authentication, and implemented GSS – API with the Kerberos version 5 protocol for Windows-based client workstations to provide end-to-end application data security.

Security Issues Addressed

Implementing GSS-API and the Kerberos version 5 protocol helps address security issues in the following areas:

SAP authentication.

SAP application data protection.

The "Intranet Access Management" paper in this series covers how to configure the SAP R/3 client to use SNC for integration with GSS-API and the Kerberos protocol.

Using Client Certificate Authentication with Encryption

Transport Layer Security (TLS) is the Internet Engineering Task Force (IETF) standard version of Secure Sockets Layer (SSL) developed by Netscape Communications, and is described in IETF RFC – 2246. TLS has the capability to perform public key-based client authentication by using a digital certificate. This is a very powerful capability because  you have configured a public key infrastructure (PKI) trust, you can use an X.509 digital certificate, and the corresponding private key, in place of relatively weak passwords for authentication.

To enable this solution, you create a shadow account that represents the user in the external Active Directory hosted in the perimeter network computers. Because this account never uses its password for authentication, you can set a very strong password, such as one that employs a 24-character cryptographically-generated random value.

Deployment Considerations

Because the external account is only accessible by using a valid X.509 certificate, it is possible that employees may not have access to an important business application if they do not have access to the X.509 digital certificate and the corresponding private key. In such a case, the organization should consider whether temporary access to the extranet application could be granted by resetting the password on the account — and telling the employee what the password is — or by creating a mechanism to issue new certificates through the extranet, or by making a virtual private network (VPN) connection to the internal network.

Because client certificates eliminate the need for passwords, they need to be kept secure through workstation security policies.

The Contoso Scenario

The Contoso architects configured the Sales and Contact application to require TLS and client certificate authentication. This involved setting up a certification authority (CA) and assigning certificates to sales department staff.

Security Issues Addressed

Implementing client certificate authentication with encryption helps address security issues in the following areas:

Authenticating with plaintext passwords.

Storing plaintext passwords on servers that are not secure.

The "Extranet Access Management" paper in this series covers how to configure client certificate authentication with encryption.

Password Authentication to Active Directory

Active Directory is designed to store highly-sensitive information, such as account passwords, in a secure manner. Passwords, in most cases, are not actually stored in such a way that the original password can be determined. Active Directory uses cryptographic hashes (one-way encryption) of the password, which is sufficient to provide authentication by using the protocols that Windows Server 2003 provides. The cryptographic hashes themselves are protected with encryption keys that are only accessible to the operating system, thus further preventing the compromise of highly-sensitive passwords.

Active Directory also provides the mechanisms to perform password-based authentication in a secure manner. In other words, without having to send plaintext password information over the network between the application server and the identity store. An example of a secure authentication mechanism would be secure bind Lightweight Directory Access Protocol over SSL or TLS, (LDAPS).

Deployment Considerations

Using a different account store for authentication usually requires a code change in the application. Applications that use a database table for authentication need to be updated to use Active Directory.

The Contoso Scenario

Contoso updated its Partner Research application for partners to use Active Directory as the identity store for partner accounts, and the mechanism for access management.

Security Issues Addressed

Implementing password authentication to Active Directory helps address security issues in the following areas:

Authenticating with plaintext passwords.

Storing plaintext passwords on servers that are not secure.

The "Developing Identity-Aware ASP.NET Applications" paper in this series describes how applications can perform authentication and authorization by using Active Directory.

Microsoft Passport Authentication to Active Directory

A separate usability study indicated to Contoso architects that customers are challenged by trying to manage user names and passwords for different Web sites. Research indicated that an identity broker such as Microsoft Passport could provide authentication for customers visiting the Contoso Web site while not requiring the customer to maintain an additional identity.

This approach also satisfied the security requirements of the Contoso Customer Trial feedback application because they could eliminate passwords for customer accounts completely. Validating a Passport credential and then mapping the Passport Unique ID (PUID) to an account in the external Active Directory thus authenticates users to the Contoso site.

Deployment Considerations

Using a service such as Microsoft Passport for authentication usually requires a code change in the application. In addition, to support specific authorization, you must provision (through automated means) large numbers of Passport mapped accounts in Active Directory through a scalable and manageable mechanism.

The Contoso Scenario

Contoso rewrote its application for customers to use Microsoft Passport and Active Directory as the authentication mechanism and the identity store for customer accounts.

Security Issues Addressed

Implementing Microsoft Passport authentication to Active Directory addresses the following:

Authenticating with plaintext passwords.

Storing plaintext passwords on servers that are not secure.

The "Extranet Access Management" paper in this series covers how to configure Microsoft Passport authentication to Active Directory.

Platform Requirements

The results of the Contoso business and security requirements analysis produced the requirements that the identity and access management platform must fulfill for the company. Key areas that the platform must address are described in the following sections.

Access Management

The access management services of the chosen platform must provide authentication, authorization, and trust services that fulfill the following requirements:

Both client and server operating systems for client/server applications, and file and print services must interoperate to perform seamless authentication and provide an SSO user experience.

Global authorization entitlements must be derived from global identity information, although such information may be global only within specific scopes, such as the intranet or perimeter network.

The infrastructure must implement robust and manageable authorization mechanisms.

The platform must offer flexible mechanisms for trust, within the organization and externally. Such trusts could be explicit trusts through a public key infrastructure (PKI) configuration, or implicit trusts through operating system mechanisms.

The infrastructure must implement manageable and secure trust configuration mechanisms to integrate multiple identity stores for future acquisitions.

Directory and Security Services

The directory and security services of the chosen platform must support:

Secure storage for identity credentials that can interoperate with secure, standards-based authentication mechanisms.

LDAP to interoperate with certain applications and services.

Strong encryption of user credentials, and services that must not distribute credential information (even in encrypted form) outside the services.

Different types of credentials to meet the requirements of numerous authentication protocols, such as the Kerberos version 5 protocol, biometrics, SSL, and TLS.

Two-factor authentication mechanisms, including PKI and smart cards (for future deployment).

Seamless interoperability between client/server operating systems over a known set of application and security protocols.

Identity Life-Cycle Management

The identity life-cycle management services of the chosen platform should fulfill the following requirements:

The identity and access management infrastructure should use a common set of standards-based protocols to manage the company's identity stores.

A single directory should be able to serve as the central intranet identity store. It must offer redundant services in case of hardware or network failures.

An extranet directory isolated in the perimeter network will store user accounts for customers and partners.

Application Platform

The chosen platform must support applications requirements for Contoso:

Existing and planned applications must use the infrastructure for digital identities, which must be accessible through common, standards-based protocols.

The application servers must have built-in support for strong authentication protocols such as the Kerberos version 5 protocol, and support for client certificate authentication that use SSL and TLS.

The application servers must be able to implement traditional access control list (ACL) authorization and role-based access control.

Security Auditing

The chosen platform must support the security auditing requirements of Contoso:

The platform must offer detailed auditing capabilities for all authentication, trust, authorization, and configuration operations.

The platform must expose manageable, but specific auditing services for all aspects of the server and application infrastructure.


**
**