Distinguished Name Mapping and Limitations

16-22 Oracle Fusion Middleware Administrators Guide for Oracle Directory Integration Platform be authenticated. Basic authentication is not supported over HTTP without secure sockets layer SSL, because the communications channel between the end user and the server would not be encrypted and the end user password would be transmitted similarly unencrypted.

16.3.3 Windows Native Authentication

This section describes how Windows Native Authentication can be used with the Oracle Directory Integration Platform. It contains these topics: ■ Understanding Windows Native Authentication ■ Authenticating Users Against Multiple Microsoft Active Directory Domains ■ Overriding an Application Authentication Mechanism with Windows Native Authentication

16.3.3.1 Understanding Windows Native Authentication

Windows Native Authentication is an authentication scheme for users of Microsoft Internet Explorer on Microsoft Windows. When this feature is enabled in OracleAS Single Sign-On Server, users log in to OracleAS Single Sign-On Server partner applications automatically. To do this, they use Kerberos credentials obtained when the user logged in to a Windows domain. Using the Simple and Protected GSS-API Negotiation Mechanism SPNEGO protocol, Internet Explorer version 5.0 and later can automatically pass the user’s Kerberos credentials to a requesting Kerberos-enabled Web server. The Web server can then decode the credentials and authenticate the user. You cannot use Microsoft integrated security or any other type of security mechanism when integrating Oracle Application Server Single Sign-On with Windows Native Authentication. Although the SPNEGO protocol supports both Kerberos version 5 and NT Lan Manager NTLM authentication schemes, Oracle Application Server 11g Release 1 11.1.1 supports only Kerberos V5 with SPNEGO. The following steps, shown in Figure 16–5 on page 16-23, describe what happens when a user tries to access a single-sign-on-protected application: 1. The user logs in to a Kerberos realm, or domain, on a Windows computer. 2. The user attempts to access a single-sign-on partner application using Internet Explorer. 3. The application routes the user to the single sign-on server for authentication. As part of this routing, the following occurs: a. The browser obtains a Kerberos session ticket from the Key Distribution Center KDC. b. The OracleAS Single Sign-On Server verifies the Kerberos session ticket and, if the user is authorized, then the user is allowed to access the requested URL. Note: Although this chapter refers only to Windows 2000, Windows Native Authentication is also supported on the Windows XP platform. If the browser is not Internet Explorer 5.0 or higher, then Oracle Identity Management authenticates the user by using OracleAS Single Sign-On Server. Authentication to an external directory is performed by using an external authentication plug-in. Third-Party Directory Integration Concepts and Considerations 16-23 4. The application provides content to the user. Figure 16–5 Flow for Windows Native Authentication When the user logs out of the Windows session, this application and any single sign-on applications accessed are logged out at the same time. To use Windows Native Authentication in deployments where Microsoft Active Directory is the central directory, a user must exist in Microsoft Active Directory. If Windows Native Authentication is enabled, then, for local Oracle Internet Directory users to invoke the single sign-on server, you must populate the attributes orclsamaccountname and krbprincipalname for each user entry.

16.3.3.2 Authenticating Users Against Multiple Microsoft Active Directory Domains

To authenticate users against multiple Microsoft Active Directory domains that are part of a single forest, create a global catalog and have Oracle Application Server Single Sign-On connect to the global catalog for authentication. However, if the domains are not part of the same forest, then you must create domain trusts between the domains. For detailed configuration procedures, refer to Configuring Windows Native Authentication on page 18-8.

16.3.3.3 Overriding an Application Authentication Mechanism with Windows Native Authentication

Windows Native Authentication does not automatically override an application’s existing authentication mechanism. To use Windows Native Authentication and Oracle Application Server Single Sign-On with an application that contains an internal authentication mechanism, you must perform one of the following tasks: ■ Remove the application’s internal authentication mechanism. ■ Configure the application as an Oracle Application Server Single Sign-On external application. This requires storing a valid application user name and password in the application configuration, making the authentication process transparent to the user after he or she logs in with Oracle Application Server Single Sign-On. For Microsoft Active Directory Oracle Internet Directory Windows 2000 Server Key Distribution Center OracleAS Single Sign-On Server User Synchronization 2 4 3a Browser 3 Oracle HTTP Server OracleAS Partner Applications 1 3b