Access Manager supports Active Directory Multi-Domain and Multi-Forest topology integration with Windows Native Authentication (WNA).
The Active Directory directory service uses a data store that is also known as the directory for information about objects, such as users, groups, computers, domains, organizational units, and security policies.
See Also:
The System Requirements and Supported Platforms for Oracle Identity and Access Management 11gR1 at https://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html
For the integration, an application must be protected by an Access Manager authentication policy that uses the Kerberos authentication scheme (KerberosScheme) with WNA as the Challenge Method with the KerberosPlugin Authentication Module. In this case, credentials must be stored in a Windows Active Directory instance that is registered as a user-identify store with Access Manager.
Each protected resource is defined in an Application Domain. The Authentication Policy includes the Authentication Scheme (KerberosScheme) that uses an Authentication Module (Kerberos) that is tied to the default User Identity Store. The store uses the value of "User Name Attribute" for authentication. This value is tied to the user in Active Directory and its values for userprincipalname = username@domian or SamAccountName = username, depending on the specific Access Manager release.
When Access Manager single sign-on is combined with WNA, a Kerberos session ticket is generated that contains the user's login credentials (among other things). This Kerberos session ticket is not visible to the user.
Access Manager interoperates with WNA, which uses Kerberos credentials obtained when the user logs in to a Windows Domain. This cross-platform authentication is achieved by emulating the negotiate behavior of native Windows-to-Windows authentication services that use the Kerberos protocol. For this cross-platform authentication to work, OAM Servers must parse SPNEGO tokens to extract the Kerberos tokens that are then used for authentication.
SPNEGO is a Generic Security Services Application Programming Interface (GSSAPI) "pseudo mechanism" used to negotiate one of a number of possible real mechanisms. SPNEGO is largely employed in the Microsoft "HTTP Negotiate" authentication extension which uses it to allow initiators and acceptors to negotiate either Kerberos or NTLMSSP mechanisms. GSSAPI implementation is included with most major Kerberos distributions.
See http://tools.ietf.org/html/rfc4559 for more information on SPNEGO.
Kerberos is a network authentication protocol that provides strong authentication for client/server applications and services using a secret-key cryptography. A free implementation of Kerberos protocol is available from the Massachusetts Institute of Technology and is also commercially available.
See:
With WNA implemented, a user can open a Web application without another challenge for credentials because the Kerberos session ticket is passed through the browser to the OAM Server.
The OAM Server decrypts the received token (using keytab) and derives the authenticated user name from it. If authentication succeeds the user is granted access to the Web application automatically.
See Also:
Supported browsers in the System Requirements and Supported Platforms for Oracle Identity and Access Management 11gR1 at https://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html
The following sections describe an overview of the process of two WNA login scenarios.
The Browser is configured for Integrated Windows Authentication (IWA).
This is a browser security configuration. If the browser being used is not configured to use IWA, no TGT is supplied when a resource protected by the Kerberos authentication module is requested. A browser basic authentication window is displayed where you can enter a valid username/password combination defined in the Default Identity Store for User login attribute.
A resource protected by Access Manager and WNA is called.
The protected resource should be configured as an intranet resource. This is done by adding the site in the "Local Intranet" zone of the Browser configuration.
A valid Kerberos ticket is present - Http headers... Authorization: Negotiate YIIJ/...
The user is not challenged for authentication.The requested resource is displayed, proving that WNA works.
In other words, when the browser is configured to use Integrated Windows Authentication, and a resource is protected by the Kerberos authentication module, then:
If a Kerberos ticket is received by Access Manager (regardless of the domain), authentication is attempted:
Successful: Access is granted.
Failure: An incorrect user name or password error occurs if information from the Kerberos ticket is either not present or does not match the value of the User Name Attribute defined in the Default User Identity Store. Access is denied. The browser automatically submits the ticket, and the interaction with Access Manager is repeated until the user has been locked out. The browser cannot be made to pause before the start of each exchange.
If the user is not logged on to a Windows Domain by way of Kerberos authentication, the browser sends OAM an NTLM token for authentication instead of a Kerberos token. Depending on how Access Manager is configured, it either uses WNA Fallback Authentication upon receiving an NTLM token or authentication fails.
Note:
You need to configure Access Manager to provide fallback authentication when the browser sends an NTLM token. Without configuration, authentication fails. For configuration steps, see Configuring WNA for NTLM Fallback.
NTLMSSP is a security support provider that is available on all versions of the Distributed Component Object Model (DCOM). It uses the NTLM protocol for authentication, which does not actually transmit the user's password to the server during authentication.
Note:
If a Kerberos ticket cannot be identified by Access Manager (regardless of browser, Operating System, domain-login, and so on), the fallback mechanism is invoked.
Fallback uses the authentication scheme "BasicScheme" with a challenge method of "Basic" and authentication module "LDAP".
This LDAP Authentication Module uses the LDAP plug-in. In this plug-in, the User Identity Store can be defined as any currently registered User Identity Store in which you define the attribute to be used for "User Name Attribute." The authentication module can be changed using the console.
The Browser is configured for Integrated Windows Authentication (IWA).
This is a browser security configuration. Access Manager handles two types of WNA fallback authentication.
Within Domain where IWA is enabled: OAM supports WNA for the SPNEGO token. But sometimes due to configuration or other issues, OAM receives NTLM tokens from the client rather than SPNEGO. During the DEFAULT flow, OAM will try to authenticate using the NTLM token and fail because OAM doesn't have the capability to authenticate NTLM tokens. Thus, with introduction of "HandleNTLMResponse" configuration, OAM server will challenge client with Basic prompt for authentication. i.e. The fallback here is to prompt for basic mode of authentication if client is sending NTLM tokens to OAM Server. See Configuring WNA for NTLM Fallback for details.
Outside Domain where IWA is disabled: Here no extra configuration is needed. By default the OOTB user will see a BASIC prompt during authentication.
A resource protected by Access Manager and WNA is called.
The protected resource should be configured as an intranet resource. This is done by adding the site in the "Local Intranet" zone of the Browser configuration.
No ticket is present (NTLM/Kerberos) - Http headers... Authorization: Basic
A basic authentication window pops up.
The user enters a valid username/password.
The requested resource is displayed (WNA Fallback works).
Use the Kerberos Authentication Module or KerberosPlugin Authentication Module when configuring Access Manager for Windows Native Authentication. The Kerberos Authentication Module identifies the key tab file and krb5 configuration file names and Principal.
The KerberosPlugin Authentication Module relies on bundled plug-ins (or those that are developed using the Access Manager Authentication Extensibility Java API). This module uses more than one plug-in that you can orchestrate to ensure that each one performs a specific authentication function. The KerberosPlugin Authentication Module is more robust and richer in functionality than the Kerberos Authentication Module. The KerberosPlugin Authentication Module (along with a plain WNA configuration) supports the following approaches:
Kerberos Plugin with Oracle Virtual Directory: Using Access Manager with orchestrated authentication plug-ins integrated with Oracle Virtual Directory virtualize multiple Active Directory Global Catalogs.
Kerberos Plugin with Search Failover Across Multiple ADGCs: Using Access Manager with orchestrated authentication plug-ins that exercise a failover pattern across multiple Active Directory Global Catalogs.