Commerce Server 2000: Active Directory Authentication

On This Page

Introduction

Active Directory in Internet Scenarios

Proposed Solution

Domain accounts

References

Introduction

Commerce Server 2000 Windows Authentication¹ allows the authentication of Internet user's requests against Microsoft Active Directory Service: every access to the site is impersonated with a domain account.

A special ISAPI Filter (AuthFilter²), installed by Commerce Server 2000, realizes Windows Authentication; it uses credentials supplied by the Internet user to get Ticket-Granting Ticket³ (TGT⁴) from Key Distribution Center⁵ domain service. (It is implemented by one of the Domain Controllers installed in the domain.)

In an Internet scenario, Active Directory authentication provides great benefits, but it can also introduce some limitations and constraints. In circumstances in which there are many users and several concurrent accesses, Active Directory authentication may limit the use of the services that are provided.

The main issues introduced in this paper are:

• scalability of the user provisioning service,

• domain data replication delay (introduced by Domain Controllers replication process in case of distributed⁶ Active Directory architecture).

This document analyzes these two problems in depth and describes a solution to them.

Top of page

Active Directory in Internet Scenarios

With Active Directory authentication, Internet user's requests are "impersonated" using specific domain account credentials.

This type of authentication provides some key benefits:

• Integrate Active Directory-enabled services (that require a domain account, for example Internet Mailbox service provided by Exchange 2000)

• Configure ACL (Access Control List) makes it possible to set the most granular access permission to thec resources.

With these benefits, it is possible to deliver all types of services easily across the Internet without any restrictions.

The use of Active Directory also introduces some typical constraints, due to its hierarchically distributed architectures:

• Scalability: Each Domain Controller can guarantee up to 35 LDAP adds (creation of new users) per second (the performance for the read operations competes with SQL Server);

• Replication Latency: In a scenario in which there are many domain controllers, the attributes⁷ stored in the Active Directory are updated directly in only one domain controller. The domain information is then replicated, with a delay of up to 15 minutes, to all domain controllers, thereby synchronizing the same managed credentials.

The scalability constraints of a domain controller would introduce limitations about usability of the user provisioning service. In an Internet scenario with lots of concurrent accesses, the constraint would limit the use of a registration service.

To supply a more scalable and reliable service (one that guarantees it is "always" working), the Active Directory architecture should be distributed on many domain controllers. But this introduces a domain information replication latency problem: only one domain controller handles updates (especially new user creation) and, during the replication period, the new information should not be stored in any other domain controllers.

When a new user is generated, his or her domain account is created in only one domain controller Thus, during the domain replication latency period, other domain controllers should not yet contain the new user's credentials. When a user logs on, WindowsLocatorService, querying the DNS or via NetBIOS, gets to Commerce Server AuthFilter the specific domain controller used to authenticate the requests. For that reason, AuthFilter authentication uses only one domain controller at a time, thus, during the domain replication period it would look for the user credential in a domain controller that does not yet have it and cannot impersonate the request, nonetheless the user's account is already present in the domain.

The above brief description emphasizes the need to build specific solutions to avoid the constraints and limitations introduced by using Active Directory in an Internet scenario.

Top of page

Proposed Solution

Main Features

To avoid the limitations described in the previoussection, this paper proposes a solution based on these features:

• Authentication with proxy account⁸ : the user's requests are authenticated using a "service" account, which is different from the real domain user's account. The service account is used to impersonate the user's requests only during the domain controllers replication period to avoid accessing to the real user's account credentials that have not yet replicated on all domain controllers;

• Asynchronous user creation process (using a store and forward architecture): the user's profile is created separately from the domain account in the Active Directory. That separation is implemented using a queue to store the account creation requests. Because domain controllers are not involved immediately, Internet users are spared a long wait.

Implementation

To separate the user's profile from the domain account used to impersonate the user's requests, a proxy account authentication is used. As described earlier, this special authentication solves the domain controller's data synchronization latency problem or "transition period".

The use of a service domain account (a proxy account that is different from the user's account) during the transition period introduces a limitation: users cannot access services that need their real domain accounts: for examples change password, mailbox folder, and so on.

During the same navigation session, the user is always authenticated with the unchanged domain account. Therefore, until the transition period ends during the session, the user's requests are always impersonated by the service account. It should be possible to use the user's real domain account; the authentication with that real account will occur at next logon. During the session some services that require a specific user security credential should be disabled. However, generic services that do not require a specific user security credential can proceed. The change of impersonation account during the navigation session is very complex (every page should check if the latency period has already occurred), and it will introduce an unacceptable overhead with respect to the benefits.

The Commerce Server authentication service is configured to Windows Authentication. It uses the ISAPI Filter (AuthFilter) to authenticate the user's requests and to check the user's authentication session information.

Figure 1: Authentication and personalization architecture.
See full-sized image.

The user profile is build to store a user's data only in the database. This feature separates the profile from authentication and guarantees that the user's profile is always accessible, even during the transition period. To know which domain account to use, the user's profile contains some specific, recognizable attributes:

• AccountInfo.account_registration_status: supplies the user's account registration status:

  • The account is stored only in the database (DB_Only == 1).

  • The account is stored in the database and is created in the domain (Active Directory). Because the transition period should not have ended yet, the account credentials should not be replicated in all domain controllers, and the account should not be always available (AD_Latency == 2).

  • The account is already stored in the database and in the Active Directory; the transition period has ended already, and the domain account is available in all domain controllers. (Normal== 0).

• AccountInfo.date_registered: stores date and time of the account's creation in the Active Directory.

The account_registration_status attribute is initialized to DB_Only by the synchronous provisioning component (Provisioning.User⁹); it is updated to AD_Latency by the asynchronous component (QCProvisioning.User¹⁰) after the account has been created by Active Directory. Therefore, the attribute is set to AD_latency during the transition period and is updated to "Normal" by the authentication ASP page after the domain replication latency has ended.

The authentication type-checking process¹¹ is written entirely inASP code in the authentication functions used by the Logon.asp page.

The authentication ticket (Auth Ticket) used by Auth Filter to check the user's authentication information contains:

• The UserID (GUID) from the user's profile (GeneralInfo.user_id). This is the main piece of information stored in the ticket (using AuthManager::setAuthTicket function), and the same information is stored in the MSCSAuth and MSCSProfile cookies, therefore guaranteeing that users are tracked accurately¹² .

• Property (called LogonName) containing the user's logon name (GeneraInfo.user_name). This property allows immediate access to the user's name in every page without accessing the user's profile.

• Property (called SessionType) containing information about the type of authentication used for the user's requests. As already described, the user is always impersonated with the unchanged domain account during the same navigation session. To avoid changing the impersonification type during the same user's session, the authentication functions (used by the Logon.asp page) use this property to check the type of impersonification (normal with the real user's domain account, or service with the service domain account) it must use in the entire Web farm. The attribute should have the following values:

  • NormalAccount == 0 to indicate the use of a normal authentication session.

  • ServiceAccount == 1 to indicate that a service account is being used.

• A property (called guid) containing the user's authentication session id is used to avoid the distributed denied of service attack¹³ .

Figure 2: Authentication process.
See full-sized image.

To separate the creation of the user's profile from the user's domain account during the user creation process, the insertion in the Active Directory is done asynchronously by a queued componentthat uses ADSI (Active Directory Service Interfaces¹⁴). The component is configured in a server COM+ application with component execution identity set to a domain user administrator of the Organization Unit (or sub tree) where the users are stored¹⁵.

To create the new account, the component makes an ADSI bind with implicit authentication¹⁶ to the Web user's container. A Serverless LDAP Path is used to connect the component to the Active Directory. This feature avoids having a single point of failure (the server-oriented LDAP path uses a specific domain controller). To create the account and change the password, the above methods of ADSI persistent interfaces are used:

• IADsContainer::Create()

• IADsUser::SetPassword()

All user data is handled by two components:

• Provisioning.User: A Visual Basic component handles the user's profile data on the database. The Visual Basic component is always called synchronously by ASP pages and is configured in the library COM+ Application. It accesses the user profile through the Commerce Server Profile User Object or by directly using OLEDB Provider for SQL Server. It does not directly use Active Directory; any changes to Active Directory are made by calling the ADProvisioning component.

• ADProvisioning.User: A Visual Basic component handles the user's data stored on Active Directory. It is called synchronously for password changes and asynchronously for the user's account creation. It's a queued component that is configured in a COM+ Server Application running with the user's OU administrative rights.

Figure 3: New user creation process¹⁷.
See full-sized image.

The ADProvisioning.User::Add() updates two transactional stores (SQL Server and MSMQ) and a non-transactional store (Active Directory). Therefore, it updates the database first and the Active Directory last. If the component fails and aborts a transaction after a successful update to the Active Directory, the database rollbacks the update, MSQM puts the message in the retry queue, but the Active Directory will still maintain the new value (Active Directory has no transaction rollback facility). When the COM+ listener reads the message from the retry queue and calls the ADProvisioni.User::Add method again, the component fails when it creates the account in the Active Directory (using IADsContainer::Create method) because it has already been created. Therefore, after an IADsContainer::Create failure, the component should check if the account is already present in the domain and set its password. This behavior works only if the component sets the user's password using IAdsUser::setPassword instead of IADsUser::ChangePassword.

Because the account is created asynchronously in the domain, all errors generated by QCProvisioning.User::Add are not communicated directly to the user. To allow the user's domain account to be created, the system should guarantee the uniqueness of Web accounts with respect to others domain accounts (Web accounts' uniqueness is guaranteed by the profile table in the database).

The user's password is stored in the unicodePwd attribute (of the Active Directory user class), and it is not affected by the domain replication latency problems that affect other attributes¹⁸. Therefore, the method that changes the password (ADProvisioning.User::ChangePassword) could be called synchronously. As described above, the ADProvisioning component runs in server COM+ application configured with a domain account identity with enough rights to run IADUser::setPassword method.

Figure 4: Change password process¹⁹²⁰.
See full-sized image.

Top of page

Domain accounts

Active Directory contains accounts that are not provisioned directly by Web channel (for example, administrative domain accounts). This characteristic introduces the account duplication problem: Internet users may register themselves using logon names that are already present in the domain.

Using asynchronous provisioning, the problem could disable some services for users who are registered using a duplicate logon name: if a user tries to register with a logon name that is already present in the domain (but not provisioned by the Web channel), the Provisioning.User component creates the user profile successfully in the database and sends a message to the QCProvisioning.User component. When QCProvisioning is asynchronously called, it cannot create the account in the domain, and the user's account_registration_status attribute will contain a DB_Only value forever (the user's profile has already been created but the user's domain account does not yet exist). Therefore, the user is always impersonated by the service account and cannot use any Active Directory-enabled services that require the user's real account.

To avoid this limitation, the provisioning service should guarantee uniqueness of the logon name between the profile database (users registered by Web channel) and the domain accounts of other users.

There are a few ways to achieve this uniqueness:

• Introduce constraints to differentiate the users who are provisioned by the Web channel from other users. For example, use a unique prefix for the logon name of Internet users. This solution guarantees uniqueness but introduces restrictions to the acceptable logon name²¹ .

• Maintain a block list of logon names that are not usable by the Web channel. The block list contains all logon names used by other domain accounts, and it must be synchronized with accounts created in the domain.

• Use the new Kerberos²² authentication type: UPN (User Principal Name²³ ) authentication. UPN authentication, unlike the classic netBIOS, uses the userPrincipalName²⁴ attribute to authenticate users; it can be personalized and does not have any restrictions.

UPN (User Principal Name) authentication

The UPN is an Internet-style logon name for the user, based on the Internet standard RFC 822. The UPN is shorter than the distinguished name and is easier to remember. By convention, the UPN should map to the user's e-mail name. The point of the UPN is to consolidate the e-mail and logon namespaces so that the user need only remember a single name. The UPN is the preferred logon name for Windows 2000 users. Users should be using their UPN to log on to the domain.

At logon time, a UPN is validated, first by searching the local domain, then by searching the Global Catalog (GC)²⁵. Failure to find the UPN in the local domain or the GC results in rejection of the UPN. The UPN can be assigned, but is not required, when the user account is created. Once assigned, the UPN is unaffected by changes to other properties of the user object (for example, if a parent domain was renamed or a domain was moved). Thus, a user can keep the same logon name, although the directory may be radically restructured.

Note that the UPN is a string property that can contain any string value, and it can be administratively changed at any time.

The UPN must be unique among all security principal objects within the directory forest. By default (that is, for the built-in user accounts and user accounts created using the Active Directory Users and Computers snap-in), the UPN can consist of any name for the user (such as the sAMAccountName property of the user) and the domain tree name to which the user belongs in the following form: Name@treeName.

The treeName is the domain name system (DNS) name of a domain, but is not required to be the name of the domain containing the user. However, the treeName portion of the UPN must be the name of a domain in the current forest or an alternate name listed in the upnSuffixes property of the Partitions container within the Configuration container. You can add or remove UPN suffixes by modifying the upnSuffixes property. Usually, the treeName is the name of the first domain in the first tree of the forest.

When creating a new user object, you should check the local domain and the Global Catalog for the proposed name to ensure that it does not already exist²⁶.

Thus, generally a User Principal Name (UPN) is composed of a user account logon name and user principal name suffix joined by the "@" sign (for example: fabiochi@europe.corp.microsoft.com). The UPN allows for a simplified logon. Because the user principal name provides the ability to perform a single logon anywhere in the enterprise, the UPN is required to be unique across the entire Microsoft Windows 2000 forest²⁷.

The tidiest way to guarantee the domain account uniqueness is to use UPN authentication.

The profile system is based in a database that guarantees user logon name uniqueness²⁸,so the users provisioned by the Web channel cannot have a duplicate logon name.

To preserve the uniqueness constraints and the authentication functions, the account must have unique a distinguished name²⁹ (DN), unique sAMAccountName, and unique userPrincipalName.

Because the container name is unique by default (although the container did not be created), a unique distinguished name requires a unique common name³⁰ (CN) on the same container. The profile database guarantees logon name uniqueness, because CN is valued by the logon name. Using a special container (or a subtree) to store the Web user's domain account assures distinguished name uniqueness in the forest. For example, the Web user's accounts are stored in a container like this: UO=WebUsers, OU=Portal, DC=CompanyDomain, DC=net.

Using this constraint, two users (one of administrative type and one from the Web) with the same CN could coexist in the same domain with different distinguished names:

CN=Administrator,CN=Users,DC= CompanyDomain,DC=net

CN=Administrator,CN=WebUsers,DC= CompanyDomain,DC=net

Because SAMAccountName is used by Down-Level Authentication, the SAMAccountName must be unique in the domain: Web users' accounts use a random id for this property to guarantee its uniqueness (the id should be any 20-character string that is generated randomly). This characteristic hinders the use of the logon name in the property.

To guarantee correct authentication, users must have a unique userPincipalName in the forest. If two or more users have the same UPN, the Windows 2000 SSPI can log on one of them only (generally, the first created). To guarantee this constraint, the Web users are created with a special UPN suffix used only for accounts that are provisioned by the Web channel. Because Web users cannot have duplicate logon names, this constraint assures the uniqueness of UPN.

As an example, in a domain called CompanyDomain.net, the Web user could use the web.CompanyDomain.net UPN suffix. Therefore, two users with the same logon name have different UPN properties:

Domain user Administrator administrator@CompanyDomain.net

Web user Administrator administrator@web.CompanyDomain.net

and they could logon with no problem.

In brie,f the Web user fabiochi should have these property values:

Therefore, UPN authentication have these benefits:

• domain account uniqueness,

• can exceed the sAMAccountName 20-character limit

and these issues:

• more authentication overhead during the request of ticket granting ticket to Key Distribution Center service

• account with random id in the sAMAccountName must be used only with UPN authentication.

Summary

It is possible to provide a solution using Active Directory security and authentication integrated with Commerce Server 2000 for an Internet scenario overcoming the following issues:

• Scalability constraints by deploying multiple domain controllers

• Replication latency constraints by implementing temporary proxy accounts

Top of page

References

• Microsoft Commerce Server 2000 Documentation

  Microsoft Corporation

• Microsoft Commerce Server 2000 Resource Kit Documentation

  Microsoft Corporation

• Microsoft Commerce Server 2000 Solution Sites Documentation

  Microsoft Corporation

• Microsoft Developer Network Library

  MSDN

• Microsoft System Journal

  MSJ

• Understanding Active Directory Services

  Daniel Blum - 1999 Microsoft Press
  

Top of page