Access Manager enables Microsoft Internet Explorer users to automatically authenticate to their Web-based single sign-on applications using their desktop credentials. This is known as Windows Native Authentication (WNA).
This chapter contains the following sections to describe how to prepare your environment and perform this integration using Active Directory:
Introduction to Access Manager with Windows Native Authentication
Integrating Access Manager KerberosPlugin with Search Failover
Configuring Access Manager for Windows Native Authentication
This document has been updated to reflect the latest information, which includes:
Certification of Access Managerwith Windows Native Authentication using Active Directory, which is described in this document.
Note:
The identity store can be any LDAP directory that can perform mapping of the Kerberos username (user@realm) and does not have to be Active Directory.Details from Knowledge Base note 1408574.1 clarifying use of userprincipalname vs. samAccountName.
Access Manager WNA Login Scenarios from Knowledge Base note 1278339.1 are included.
Access Manager WNA Fallback Authentication from Knowledge Base note 1410845.1 is included.
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 (known as the directory) for all directory information about objects (users, groups, computers, domains, organizational units, and security policies).
See Also:
The System Requirements and Supported Platforms for Oracle Identity and Access Management 11gR1 athttps://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.htmlFor the integration described in this chapter, an application must be protected by an Access ManagerOracle 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.
Put another way, each protected resource is defined in an Access Manager 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 Managerrelease.
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 Managerinteroperates with Windows Native Authentication (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. For more information on SPNEGO see http://tools.ietf.org/html/rfc4559.
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.
For more information, see:
With WNA implemented, a user can click her Web application without another challenge for credentials because her 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 that. If authentication succeeds the user is granted access to her Web applications automatically.
See Also:
Supported browsers in the System Requirements and Supported Platforms for Oracle Identity and Access Management 11gR1 athttps://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.htmlThis section describes several WNA login scenarios.
Process overview: Successful Access ManagerWNA Authentication
The Browser is configured for Integrated Windows Authentication (IWA).
A resource protected by Access Manager and WNA is called.
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 Access Manager 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 Username 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, 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 a NTLMSSP ticket is received by Access Manager, authentication fails. 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.
If the browser being used is not configured to use Integrated Windows Authentication, no TGT is supplied when a resource protected by Access Manager 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 Access Manager User login attribute.
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.WNA Fallback Authentication: Fallback uses the authentication scheme "BasicScheme" with a challenge method of "Basic" and authentication module "LDAP". The authentication module can be changed using the console.
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".
Process overview: Access Manager WNA Fallback Authentication
The Browser is configured for Integrated Windows Authentication (IWA).
A resource protected by Access Manager WNA is requested.
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).
Access Manager 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.
The tasks in this section are required regardless of the approach you choose.
You need a fully-configured Microsoft Active Directory authentication service set up as described here. The procedure in this section ensures that Active Directory and the Kerberos client will operate together. However, none of this is Oracle specific.
The following sample scenario represents a typical Active Directory topology, and is not a requirement dictated by or for Access Manager. The naming used here is an example only. Your environment will be different.
As an example, consider two Active Directory forests operating within a company.
| Forest | Domain Name |
|---|---|
| ORACLE | lm.example.com |
| SPRITE | lmsib.sprite.com |
Consider that a child domain exists within the ORACLE forest: child.lm.example.com.
Trust is required as follows:
Between forests: Two-way, non-transitive trust.
Between the child domain and its parent: Two-way, transitive trust.
SPRITE users have UPN suffixes such as sun.com orjava.com. The SPRITE forest contains testuser.java.com.
ORACLE users have suffixes such as myoracleco.com and oracleco.com. The ORACLE forest contains testuser.oracleco.com.
ORACLE child domain inherits the UPN suffixes of the parent domain.
Note:
Pre-Windows usernames, formed as DOMAIN\USERNAME, are not supported.Default Identity Store User Name Attribute for WNA
For integration with WNA, the User Name Attribute defined for the Default Identity Store an be any attribute whose value matches the Active Directory user's samAccountName.
You need to know which encryption type your environment will use. In some cases a user might be created with "Use DES encryption types for this account" enabled. However, Active Directory is not using DES encryption.
Note:
The keytab file created in the following procedure uses RC4-HMAC encryption.Access Manager supports what JGSS/JDK6 supports. The limitation on the TGT encryption that can be used would be determined by the piece that is the least common or lowest encryption supported: KDC, Keytab, Operating System, Kerberos client. Access Manager does not support any specific Kerberos encryption type. It is dependent on the Generic Security Services (GSS)/Kerberos jdk encryption types with which it is certified. Access Manager is not dependent on any encryption type and does not use TGT encryption. As part of SPNEGO token Access Manager only looks into the Service Ticket which is encrypted with a key that the service (in this case Access Manager) has registered when executing the ktpass/keytab commands.
Note:
The keytab file created in the following procedure uses RC4-HMAC encryption.Encryptions are used for communication among the different OS (Windows/Linux acting as Kerberos Server/Client). OAM Server just needs the SPNEGO token, from which it extracts the user credential. The encryption used in this three way negation process between the Windows Client (Browser), the Windows KDC, and the Generic Security Services (GSS) classes used by Access Manager, depend on the versions used (which must match).
See Also:
My Oracle Support for details about the Kerberos Encryption types Access Manager Supports [Doc 1212906.1] at:https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1212906.1In the trusted domain (for example, the root domain lm.example.com), you will follow steps provided to:
Create an account for the OAM Server.
Extract the keytab file that was configured with the Active Directory Multi-Domain or Multi-Forest topology and trust relationships.
Specify the Service Principal Name (SPN) using the fully-qualified hostname of the OAM Server (or the load balancer that represents the OAM Cluster), followed by the Realm name.
For this example the names in Table 44-1 are used.
| Name | Description |
|---|---|
|
|
KDC hostname KDC is a trusted network service that supplies session tickets and temporary session keys to users and computers within an Active Directory domain. The KDC runs on each domain controller as part of Active Directory Domain Services and is implemented as a domain service. The KDC uses Active Directory as its account database. In implementations of the Kerberos protocol, the KDC is a single process that provides two services: Authentication Service (AS) and Ticket Granting Service (TGS). |
|
|
AdminServer hostname This is the same as the KDC hostname. |
|
|
OAM Server hostname |
|
|
Default Active Directory Realm Second Active Directory Realm The realm name identifies the location of the user account. A realm name can be either a prefix or a suffix. When an access client sends user credentials, a user name is often included. Within the user name are two elements: a user account name and user account location. |
|
HTTP/fully_qualified_OAMServerhostname@REALM_NAME (in CAPITAL letters |
Service Principal Names (SPNs) are needed for user accounts (the name by which a client uniquely identifies an instance of a service). Note: If you install multiple instances of a service on computers throughout a forest, each instance must have its own Service Principal Name. |
Commands in the following procedure are for a Unix Operating System. Command syntax will vary depending on the specific Operating System in your environment.
To prepare Active Directory and kerberos
Check the Oracle certification matrix to ensure you are installing a supported version of Active Directory for this integration:
https://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html
Install and configure Active Directory as follows:
Multi-Forest topology with requisite trust relationships configured and functional, including:
a. User accounts to map Kerberos services
b. Service Principal Names (SPNs) for these user accounts (the name by which a client uniquely identifies an instance of a service).
c. Key tab files
Active Directory Global Catalog (ADGC) enabled and functional within each forest
Multi-Forest Deployment: In this case, ensure there exists a naming attribute (available in global catalog) that uniquely identifies the users originating from various forests. Generally, userprincipalname is unique for the forest and samAccountName is unique for the domain
One domain that is directly or indirectly trusted by every other domain, regardless of forest affiliation.
Create a user for Access Manager, use during WNA authentication and record this username for generating the keytab file (no DES encryption).
Record the OAM Server hostname. For example:
oam11g.example.com
Record the KDC hostname and the Active Directory domain/realm:
KDC = kdc.lm.example.com Default AD Realm = lm.example.com
Create the Service Principal Name (SPN) of the Active Directory user that the OAM Server client is using, and record the results (including encryption type). For example:
ktpass -princ <protocol/oamserver_host> -pass <mypassword> -mapuser <user from step 1> -out <path_to_filename>
ktpass -princ HTTP/oam11g.example.com@lm.example.com -mapuser oam -pass examplepw -out c:\temp\oam.keytab C:\Users\Administrator>ktpass -princ HTTP/oam11g.example.com@LM.EXAMPLE.COM -mapuser oam -pass welcome1 -out c:\temp\oam.keytab Targeting domain controller: kdc.lm.example.com Using legacy password setting method Successfully mapped HTTP/oam11g.example.com to oam. WARNING: pType and account type do not match. This might cause problems. Key created. Output keytab to c:\temp\oam.keytab: Keytab version: 0x502 keysize 80 HTTP/oam11g.example.com@lm.example.com ptype 0 (KRB5_NT_ UNKNOWN) vno 3 etype 0x17 (RC4-HMAC) keylength 16 (0xa3a685f89364d4a 5182b028fbe79ac38)
Copy the newly created keytab file to the proper location on the OAM Server and ensure permissions are correct so that the user who created Access Manager can access this file for running ktpass command.
Create a simple OAM Server Kerberos krb5.conf or krb5.ini configuration. For example:
[libdefaults]
default_realm = lm.example.com
ticket_lifetime = 600
clock_skew = 600
[realms]
lm.example.com = { --
kdc = kdc.lm.example.com
admin_server = kdc.lm.example.com
default_domain = lm.example.com
}
[domain_realm]
lm.example.com =LM.EXAMPLE.COM
.lm.example.com = LM.EXAMPLE.COM
Note:
The OAM account is created in one domain that is trusted by all, lm.example.com. This is not required for lmsib.sprite.com.Verify the klist and kinits work using the keytab file and SPN of the Active Directory and Access Manager user created, then record the results.
kdestroy
klist [-k] [-t <keytab_filename>]. For example:
bash-3.2$ klist -k -t -K -e FILE:/refresh/home/oam.keytab Keytab name: FILE:/refresh/home/oam.keytab KVNO Timestamp Principal ---- ----------------- --------------------------------------------------- 3 12/31/69 19:00:00 HTTP/oam11g.example.com@lm.example.com (ArcFour with HMAC/md5)(0xa3a685f89364d4a5182b028fbe79ac38) bash-3.2$
kdestroy
kinit [-k] [-t <keytab_filename>] [<principal>]. For example:
klist -k -t -K -e FILE:/refresh/home/oam.keytab
bash-3.2$ kinit -V -k -t /refresh/home/oam.keytab
HTTP/oam11g.example.com@lm.example.com
Authenticated to Kerberos v5
klist -e
bash-3.2$ klist -e Ticket cache: FILE:/tmp/krb5cc_8000 Default principal: HTTP/oam11g.example.com@lm.example.com Valid starting Expires Service principal 02/25/12 18:46:55 02/25/12 18:56:55 krbtgt/LM.EXAMPLE.COM@LM.EXAMPLE.COM Etype (skey, tkt): ArcFour with HMAC/md5, AES-256 CTS mode with 96-bit SHA-1 HMAC Kerberos 4 ticket cache: /tmp/tkt8000 klist: You have no tickets cached bash-3.2$
Proceed as follows:
Successful: Continue with "Performing Oracle-Specific Prerequisite Tasks".
Not Successful: Stop and resolve the issue which is not related to this integration. Any failure at this point indicates Access Manager WNA cannot work.
You need a fully-functioning Access Manager deployment. The tasks in this section are required regardless of the approach you choose. See:
In this procedure you will install and register a WebGate, which configures an Application Domain to protect resources. Then you verify that the environment is working with an authentication scheme other than Kerberos.
Note:
Information in this chapter is based on Access Manager.See Also:
Oracle Fusion Middleware High Availability Guide for details about high availability environments with two or more Managed Servers configured to operate as a clusterTo validate your Access Manager environment
Log in to the Oracle Access Management Console using Administrator credentials, as described in the Chapter 2.
Verify the Default Identity Store connection.
Register and install Webgate (11.1.2) as an OAM Agent and accept automatic policy generation, as described in the Chapter 14.
Add resources to the Application Domain and customize the authentication policy protecting resources to use any Authentication Scheme other than Kerberos.
Test the configuration to ensure that resource protection and access are working as expected.
Proceed to "Enabling the Browser to Return Kerberos Tokens".
You can use the following procedures to configure the Internet Explorer or Mozilla Firefox browsers to return Kerberos tokens.
Note:
With Internet Explorer browsers, Integrated Windows Authentication is enabled by default and you might not need any changes to the default configuration for WNA to work.To enable Kerberos tokens in Internet Explorer
On a Windows host in the Active Directory domain, sign in as a domain user.
Open the Internet Explorer browser.
From the Tools menu, click Internet Options, click Security, click Local Intranet, click Advanced.
On the Advanced tab, Security section, check the box beside Enable Integrated Windows Authentication, and click OK.
Add Oracle Access Manager CC host or domain name to Local Intranet zone (use the format http://node.host:port (the port is not required)). For example:
http://oam11g.example.com
Restart the Internet Explorer browser to enable the change.
To enable Kerberos tokens in Mozilla Firefox
In the browser Address bar, enter about:config.
Add Oracle Access Manager CC host or domain name under network.negotiate-auth.trusted-uris as: network.negotiate-auth.trusted-uris=http://oam11g.example.com
Oracle Virtual Directory provides the ability to integrate LDAP-aware applications into diverse directory environments while minimizing or eliminating the need to change either the infrastructure or the applications. This section provides the tasks you must perform to configure Access Manager KerberosPlugin authentication for WNA with Oracle Virtual Directory.
This section provides the following topics with steps you can follow:
Task overview: Integrating Access Manager KerberosPlugin with Oracle Virtual Directory
Perform tasks in this section:
Configuring Access Manager for Windows Native Authentication
Oracle Virtual Directory communicates with other directories through adapters. Before you can start using Oracle Virtual Directory as an identity store, you must create adapters to each of the directories you want to use.
The procedure differs slightly, depending on the directory to which you are connecting. If you choose to use Oracle Internet Directory, Active Directory, Oracle Directory Server Enterprise Edition (ODSEE), or Oracle Unified Directory, the required adapters are created and configured while installing and configuring the Oracle Identity Management Server. For more information on managing the adapters, see "Managing Identity Virtualization Library (libOVD) Adapters" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.
In the following procedure you create an account for the OAM Server in the trusted domain. Additionally, you create two Active Directory Adapters (one for each forest) using the fully-qualified domain names as namespaces.
By default Active Directory uses dc to construct the root context distinguished name. If this is different in your deployment, adjust your adapter namespaces accordingly.
To deploy Oracle Virtual Directory for this integration
Perform tasks described in "Confirming Access Manager Operation".
Install Oracle Virtual Directory, as described in Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management.
In Oracle Virtual Directory Console, create two Active Directory Adapters (one for each forest) using the fully-qualified domain names as namespaces as follows:
Adapter 1, EXAMPLE Adapter namespace (domain DNS lm.example.com):
dc=lm,dc=example,dc=com
Adapter 2, SPRITE Adapter namespace (domain DNS lmsib.sprite.com):
dc=lmsib,dc=sprite,dc=com
Shut down the OAM Cluster.
Restart the AdminServer and all OAM Servers.
Proceed with "Registering Oracle Virtual Directory as the Default Store for WNA".
Users with valid Oracle Access Management Administrator credentials can perform the following task to register Oracle Virtual Directory as the user store for Access Manager interoperating with Windows Native Authentication.
For Windows Native Authentication, the user credentials must reside in Microsoft Active Directory. Access Directory can be managed by Oracle Virtual Directory instance. For single sign-on with Access Manager, each User Identity Store must be registered to operate with Access Manager.
Typically, userprincipalname reflects the Windows login name. For WNA with Access Manager, either leave the User Search Base and Group Search Base blank or provide the distinguished name path that is common to both the adapters configured while performing prerequisite tasks.
Preparing Your Active Directory/Kerberos Topology
Performing Oracle-Specific Prerequisite Tasks
To register the Oracle Virtual Directory with Access Manager
From the Oracle Access Management Console, open the Data Sources node:
Click the User Identity Stores node, and then click the Add button in the tool bar.
Enter required values for your Oracle Virtual Directory instance. For example:
OVDldap://ovd_host.domain.com:389cn=Administrator,cn=users,dc=lm,dc=example,dc=com********dc=comuserprincipalnamedc=comDefault Store: Click the Default Store button to make this the user Identity Store for Access Manager.
Click Apply to submit the registration, then dismiss the Confirmation window.
Restart the AdminServer and OAM Servers.
Proceed to "Setting Up Authentication with Access Manager KerberosPlugin and OVD".
When a native authentication module does not offer enough flexibility for your needs, you can create a custom authentication module using plug-ins designed to meet specific needs.
The KerberosPlugin is a credential mapping module that matches the credentials (encrypted username in the kerberos ticket (SPNEGO token)) of the user who requests the resource. By default, KerberosPlugin maps the domain DNS name to the corresponding distinguished name using the dc component. However, if the mapping is different, you can specify the correct mapping as a semi-colon (;) separated list of name:value tokens. For example:
LM.EXAMPLE.COM:dc=lm,dc=example,dc=com;LMSIB.SPRITE.COM:dc=lmsib,dc=sprite,dc=com
Users with valid Oracle Access Management Administrator credentials can perform the following task to replace default KerberosPlugin steps with steps that enable integration for Windows Native Authentication using the Oracle Access Management Console.
To set up the Access ManagerKerberosPlugin for OVD
From the Oracle Access Management Console, open the:
On the KerberosPlugin page, click the Steps tab.
Steps Tab: Replace stepKTA, as described here, then click Save.
Click stepKTA then click the Delete (x) button to remove this step.
Click the Add (+) button and add the following step to the plug-in:
| Element | Description | |
|---|---|---|
| Name | stepKTA | |
| Class | KerberosTokenAuthenticator |
Step Details:
Confirm that this new stepKTA includes the parameter KEY_DOMAIN_DNS2DN_MAP (created earlier) and enter values for your deployment:
| Element | Description | |
|---|---|---|
| KEY_DOMAIN_DNS2DN_MAP | Active Directory Forests in your deployment. For example:
LM.EXAMPLE.COM:dc=lm,dc=example,dc=com;LMSIB.SPRITE.COM:dc=lmsib,dc=sprite,dc=com Note: By default, a DN domain name a.b.c is mapped into dc=a,dc=b,dc=c. Only if the mapping is different, one has to specify the parameter. Otherwise it is best not to use it and let the default behavior take its course. |
|
| Service Principal | HTTP/oam11g.example.com@LM.EXAMPLE.COM | |
| keytab.conf | keytab.conf location for stepKTA | |
| krb5.conf | krb5.conf location for stepKTA |
stepUIF Details: Configure as follows and click Save:
| Element | Description | |
|---|---|---|
| KEY_LDAP_FILTER | (samAccountName={KEY_USERNAME}) | |
| KEY_IDENTITY_STORE_REF | OVD | |
| KEY_SEARCHBASE_URL | Leave this empty |
stepUI and stepUA: Configure as follows and Save:
| KEY_IDENTITY_STORE_REF | OVD |
Save the changes.
Restart the OAM Cluster.
Proceed with "Configuring Access Manager for Windows Native Authentication".
In cases where Oracle Virtual directory deployment is not viable, and it is acceptable to perform search failover based on some order or hierarchy when finding the user, you can configure Access Manager as described in this section.
Task overview: Integrating Access ManagerKerberosPlugin with Search Failover
Completing tasks in the following earlier sections:
"Performing Oracle-Specific Prerequisite Tasks" (except "Preparing Oracle Virtual Directory for This Integration", which is not needed for Search Failover)
Performing tasks in this section:
"Configuring Access Manager for Windows Native Authentication"
Users with valid Oracle Access ManagementAdministrator credentials can perform the following task to register each Active Directory Global Catalog (ADGC), with relevant search bases and naming attributes, as an individual User Identity Store for Oracle Access Management.
A fully-configured Microsoft Active Directory authentication service should be set up with User accounts for mapping Kerberos services, Service Principal Names (SPNs) for those accounts, and Key tab files. For more information, see Oracle Fusion Middleware Securing Oracle WebLogic Server 11g Release 1 (10.3.3).
To register Microsoft Active Directory Global Catalogs with Access Manager
From the Oracle Access Management Console, open the Data Sources node:
Click the User Identity Stores node, and then click the Add button in the tool bar.
Enter required values for your first ADGC. For example:
ADGC1-EXAMPLEldap://ADGC1_host.domain.com:389cn=Administrator,cn=users,dc=lm,dc=example,dc=comdc=lm,dc=example,dc=comuserprincipalnamedc=lm,dc=example,dc=comDefault Store: Click the Default Store button.
Click Apply to submit the changes and dismiss the confirmation window.
Repeat these steps to add the second ADGC (ADGC2-SPRITE) with appropriate search bases and naming attributes.
ADGC2-SPRITEldap://ADGC2_host.domain.com:389cn=Administrator,cn=users,dc=lm,dc=example,dc=comdc=lmsib,dc=example,dc=comuserprincipalnamedc=lmsib,dc=example,dc=comRestart the AdminServer and OAM Servers.
Proceed to "Setting Up Access Manager KerberosPlugin for ADGCs".
When a native authentication module does not offer enough flexibility for your needs, you can create a custom authentication module using plug-ins designed to meet specific needs.
The KerberosPlugin is a credential mapping module that matches the credentials (username and password) of the user who requests a resource to the encrypted "kerberos ticket". By default, KerberosPlugin maps the domain DNS name to the corresponding distinguished name using the dc component. However, if the mapping is different, you can specify the correct mapping as a semi-colon (;) separated list of name:value tokens. For example:
LM.EXAMPLE.COM:dc=lm,dc=example,dc=com;LMSIB.SPRITE.COM:dc=lmsib,dc=sprite,dc=com
Users with valid Oracle Access Management Administrator credentials can perform the following task to replace or update KerberosPlugin steps with steps that point to the ADGCs you have created. These will operate in tandem with their counterparts (if the initial step and ADGC fail, the secondary ADGC is used).
Preparing Your Active Directory/Kerberos Topology
Performing Oracle-Specific Prerequisite Tasks
To set up the Access Manager KerberosPlugin for ADGCs
From the Oracle Access Management Console, open the:
On the KerberosPlugin page, click the Steps tab.
Steps Tab: Replace stepKTA, as described here, then click Save.
Click stepKTA then click the Delete (x) button to remove this step.
Click the Add (+) button and add the following step to the plug-in:
| Element | Description | |
|---|---|---|
| Name | stepKTA | |
| Class | KerberosTokenAuthenticator |
New stepKTA Details:
Confirm that this new stepKTA includes the parameter KEY_DOMAIN_DNS2DN_MAP (created earlier) and enter values for your deployment:
| Element | Description | |
|---|---|---|
| KEY_DOMAIN_DNS2DN_MAP |
LM.EXAMPLE.COM:dc=lm,dc=example,dc=com;LMSIB.SPRITE.COM:dc=lmsib,dc=sprite,dc=com |
|
| Service Principal | HTTP/oam11g.example.com@LM.EXAMPLE.COM | |
| keytab.conf | keytab.conf location for stepKTA. For example:
/refresh/home/oam.keytab |
|
| krb5.conf | krb5.conf location for stepKTA.
/etc/krb5.conf |
stepUIF: Step Details (configure as follows and save):
| Element | Description | |
|---|---|---|
| KEY_IDENTITY_STORE_REF | ADGC1-ORACLE | |
| KEY_SEARCHBASE_URL | {KEY_USERDOMAIN} | |
| KEY_LDAP_FILTER | (samAccountName={KEY_USERNAME}) |
stepUI and stepUA: Step Details (configure these steps and save):
| Element | Description | |
|---|---|---|
| KEY_IDENTITY_STORE_REF | ADGC1-ORACLE |
Save the changes.
Add stepUIF2: This will operate in tandem and execute if stepUIF fails:
| Element | Description | |
|---|---|---|
| KEY_IDENTITY_STORE_REF | ADGC2-SPRITE | |
| KEY_SEARCHBASE_URL | {KEY_USERDOMAIN} | |
| KEY_LDAP_FILTER | (samAccountName= {KEY_USERNAME}) |
Add stepUI2: This will operate in tandem and execute if stepUI fails:
| Element | Description | |
|---|---|---|
| KEY_IDENTITY_STORE_REF | ADGC2-SPRITE |
Add stepUA2: This executes when stepUI2 succeeds:
| Element | Description | |
|---|---|---|
| KEY_IDENTITY_STORE_REF | ADGC1-EXAMPLE and ADGC2-SPRITE, respectively |
Add Step Details: Common Configuration, Plugins, KerberosTokenAutheticator.
Enter values for your deployment:
| Element | Description | |
|---|---|---|
| keytab.conf | keytab.conf location for stepKTA. For example: /refresh/home/oam.keytab |
|
| krb5.conf | krb5.conf location for stepKTA. For example: /etc/krb5.conf |
Restart the OAM Cluster.
Proceed with "Configuring Access Manager for Windows Native Authentication".
Whether you are using Oracle Virtual Directory or Active Directory with Global Catalogs, this section provides the following topics with steps you can follow:
Creating the Authentication Scheme for Windows Native Authentication
Configuring Access ManagerPolicies for Windows Native Authentication
Users with valid Oracle Access Management Administrator credentials can perform the following task to define an authentication scheme for the Access Manager to use in policies protecting applications for Windows Native authentication.
Integrating KerberosPlugin with Oracle Virtual Directory
Or
Integrating Access Manager KerberosPlugin with Search Failover
To create the Kerberos authentication scheme for WNA
From the Oracle Access Management Console, open the Policy Configuration tab, expand the Authentication Schemes node.
Open KerbScheme to display its configuration details and set (or confirm) the following attributes:
Challenge Method: WNA
Authentication Module: KerberosPlugin
Finish configuring KerbScheme for your deployment.
Click Apply and close the confirmation window.
Proceed to "Configuring Access ManagerPolicies for Windows Native Authentication".
In this procedure you edit (or Create) an Application Domain and policies to protect resources for Windows Native Authentication.
Creating the Authentication Scheme for Windows Native Authentication
To set Access Manager policies for Windows Native Authentication
From the Oracle Access Management Console, open the Policy Configuration tab, expand the Application Domains node.
Open (or Create) the desired Application Domain, as described in "Managing Application Domains and Policies Using the Console".
Resource Definitions: Add Resource Definitions to the domain as described in "Adding and Managing Resource Definitions to be Added to Policies".
Authentication Policies:
Open the Authentication Policies node, and open (or Create) the desired Authentication Policy with the following attributes:
Authentication Scheme: KerbScheme as the and ensure that it includes the updated KerberosPlugin.
Choose KerbScheme as the Authentication Scheme and ensure that it includes the updated KerberosPlugin.
Click Apply, close the Confirmation window.
Resources for Authentication Policy: Add Resources to the Authentication Policy as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.
Complete the Authentication Policy with any desired Responses.
Authorization Policies: Complete the Authentication Policy with any desired Responses or Conditions as described in "Defining Authorization Policies for Specific Resources".
Proceed to "Verifying the Access Manager Configuration File".
Verify that the following are specified in the oam-config.xml file:
path to the krb5.conf file
path to the keytab file
a principal to connect with KDC
<Setting Name="KerberosModules" Type="htf:map">
<Setting Name="6DBSE52C" Type="htf:map">
<Setting Name="principal" Type="xsd:string">HTTP/oam11g.example.com@LM.EXAMPLE.COM
</Setting>
<Setting Name="name" Type="xsd:string">XYZKerberosModule</Setting>
<Setting Name="keytabfile" Type="xsd:string">/refresh/home/oam.keytab
</Setting>
<Setting Name="krbconfigfile" Type="xsd:string">/etc/krb5.conf</Setting>
</Setting>
</Setting>
Integrated Windows Authentication (IWA) is associated with Microsoft products that use SPNEGO, Kerberos, and NTLMSSP authentication protocols included with certain Windows operating systems. The term Integrated Windows Authentication (IWA) is used for the automatic authentication process that happens between Microsoft Internet Information Services, Internet Explorer, and Microsoft's Active Directory.
Note:
IWA is also known by other names such as HTTP Negotiate authentication, NT Authentication, NTLM Authentication, Domain authentication, Windows Integrated Authentication, Windows NT Challenge/Response authentication and Windows Authentication.WNA authentication occurs internally. When integrated with Access Manager:
The user is redirected to the Access Manager for authentication.
The OAM Server requests authentication with a www-negotiate header when the resource is protected by Access Manager with a challenge method of WNA.
The browser configured for Integrated Windows Authentication (IWA) sends the Kerberos SPNEGO token to the OAM Server for decryption.
The OAM Server decrypts the received user SPNEGO token (using keytab) and redirects the user back to the Agent with the cookie and gets access to the resource.
To validate WNA with Access Manager-protected resources
Log in to a Windows system in the Active Directory domain as a domain user.
Sign in to the Windows OS client using the Windows domain credentials stored in a hosted Active Directory that is registered with Access Manager.
Open an Internet Explorer browser window, and enter the URL for the OAM-protected application in your environment.
Confirm that you are logged in to the application with your Windows domain credentials with no additional login.
This section provides the following topics:
See Also:
Access Manager WNA Quick Start Guide on My Oracle Support, Knowledge Base note 1416903.1 at:https://support.oracle.com/Client not found in Kerberos database while getting initial credentials
This is Kerberos version of "User not found", which might be related to one of the following:
Misspelling or typo of the principal name
The principal was not added to the Kerberos database, the principal doesn't exist.
The user name does not exist in Active Directory or has not been registered as a Kerberos user.
The SPN is not unique.
On the Active Directory side one or more duplicate entries were found.
Have the Active Directory Administrator search the LDAP tree for duplicate entries of the SPN, and remove them.
Unable to access a resource protected by Access Manager-protected resource using WNA authentication scheme. Error: An incorrect Username or password was specified.
An incorrect username or password was specified.
The Identity Store used by Access Manager might not point to Windows Active Directory. By default, the identity store is Embedded LDAP.
Register Active Directory: Oracle Access Management Console, System Configuration, Data Sources, User Identity Store, Create ActiveDirectory.
Set Active Directory as the Default Store, as described in "Setting the Default Store and System Store".