43 Configuring Access Manager for Windows Native Authentication

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:

43.1 What is New in this Release?

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.

43.2 Introduction to Access Manager with Windows Native Authentication

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 at https://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

For 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:

43.2.1 Access Manager WNA Login and Fall Back Authentication

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 at https://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

This section describes several WNA login scenarios.

Process overview: Successful Access ManagerWNA Authentication

  1. The Browser is configured for Integrated Windows Authentication (IWA).

  2. A resource protected by Access Manager and WNA is called.

  3. A valid Kerberos ticket is present - Http headers... Authorization: Negotiate YIIJ/...

  4. 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

  1. The Browser is configured for Integrated Windows Authentication (IWA).

  2. A resource protected by Access Manager WNA is requested.

  3. No ticket is present (NTLM/Kerberos) - Http headers... Authorization: Basic

  4. A basic authentication window pops up.

  5. The user enters a valid username/password.

  6. The requested resource is displayed (WNA Fallback works).

43.2.2 Supported Integration Approaches

Access Manager supports the following approaches:

43.3 Preparing Your Active Directory/Kerberos Topology

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.

Sample Forests and Trust

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.

Suffixes and Inheritance

  • 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.

Encryption Type

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.1

Domain Requirements

In 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.

Sample Naming

For this example the names in Table 43-1 are used.

Table 43-1 Sample Naming

Name Description

kdc.lm.example.com

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).

kdc.lm.example.com

AdminServer hostname

This is the same as the KDC hostname.

oam11g.example.com

OAM Server hostname

LM.EXAMPLE.COM

LMSIB.SPRITE.COM

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

  1. 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
    
  2. 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.

  3. Create a user for Access Manager, use during WNA authentication and record this username for generating the keytab file (no DES encryption).

  4. Record the OAM Server hostname. For example:

    oam11g.example.com
    
  5. Record the KDC hostname and the Active Directory domain/realm:

    KDC = kdc.lm.example.com
    Default AD Realm = lm.example.com
    
  6. 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)
    
  7. 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.

  8. 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.

  9. 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.

    1. kdestroy

    2. 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$
      
    3. kdestroy

    4. 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
      
    5. 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$
      
  10. 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.

43.4 Performing Oracle-Specific Prerequisite Tasks

You need a fully-functioning Access Manager deployment. The tasks in this section are required regardless of the approach you choose. See:

43.4.1 Confirming Access Manager Operation

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 cluster

To validate your Access Manager environment

  1. Log in to the Oracle Access Management Console using Administrator credentials, as described in the Chapter 2.

  2. Verify the Default Identity Store connection.

  3. Register and install Webgate (or 11.1.2) as an OAM Agent and accept automatic policy generation, as described in the Chapter 13.

  4. Add resources to the Application Domain and customize the authentication policy protecting resources to use any Authentication Scheme other than Kerberos.

  5. Test the configuration to ensure that resource protection and access are working as expected.

  6. Proceed to "Enabling the Browser to Return Kerberos Tokens".

43.5 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

  1. On a Windows host in the Active Directory domain, sign in as a domain user.

  2. Open the Internet Explorer browser.

  3. From the Tools menu, click Internet Options, click Security, click Local Intranet, click Advanced.

  4. On the Advanced tab, Security section, check the box beside Enable Integrated Windows Authentication, and click OK.

  5. 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
    
  6. Restart the Internet Explorer browser to enable the change.

To enable Kerberos tokens in Mozilla Firefox

  1. In the browser Address bar, enter about:config.

  2. 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

43.6 Integrating KerberosPlugin with Oracle Virtual Directory

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

  1. Perform tasks in this section:

  2. Configuring Access Manager for Windows Native Authentication

  3. Enabling the Browser to Return Kerberos Tokens

  4. Validating WNA with Access Manager-Protected Resources

43.6.1 Preparing Oracle Virtual Directory for Integration

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

  1. Perform tasks described in "Confirming Access Manager Operation".

  2. Install Oracle Virtual Directory, as described in Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management.

  3. In Oracle Virtual Directory Console, create two Active Directory Adapters (one for each forest) using the fully-qualified domain names as namespaces as follows:

    1. Adapter 1, EXAMPLE Adapter namespace (domain DNS lm.example.com):

      dc=lm,dc=example,dc=com
      
    2. Adapter 2, SPRITE Adapter namespace (domain DNS lmsib.sprite.com):

      dc=lmsib,dc=sprite,dc=com
      
  4. Shut down the OAM Cluster.

  5. Restart the AdminServer and all OAM Servers.

  6. Proceed with "Registering Oracle Virtual Directory as the Default Store for WNA".

43.6.2 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.

Prerequisites

Preparing Your Active Directory/Kerberos Topology

Performing Oracle-Specific Prerequisite Tasks

See Also:

Chapter 4

To register the Oracle Virtual Directory with Access Manager

  1. From the Oracle Access Management Console, open the Data Sources node:

    System Configuration tab
    Common Configuration section
    Data Sources node
  2. Click the User Identity Stores node, and then click the Add button in the tool bar.

  3. Enter required values for your Oracle Virtual Directory instance. For example:


    Name: OVD
    LDAP Url: ldap://ovd_host.domain.com:389
    Principal: cn=Administrator,cn=users,dc=lm,dc=example,dc=com
    Credential: ********
    User Search Base: dc=com
    User Name Attribute: userprincipalname
    Group Name: cn
    Group Search Base: dc=com
    LDAP Provider: Oracle Virtual Directory
  4. Default Store: Click the Default Store button to make this the user Identity Store for Access Manager.

  5. Click Apply to submit the registration, then dismiss the Confirmation window.

  6. Restart the AdminServer and OAM Servers.

  7. Proceed to "Setting Up Authentication with Access Manager KerberosPlugin and OVD".

43.6.3 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.

See Also:

Chapter 11

To set up the Access ManagerKerberosPlugin for OVD

  1. From the Oracle Access Management Console, open the:


    System Configuration tab
    Access Manager section
    Authentication Modules node
    Custom Authentication Modules node
    KerberosPlugin
  2. On the KerberosPlugin page, click the Steps tab.

    Steps Tab: Replace stepKTA, as described here, then click Save.

    1. Click stepKTA then click the Delete (x) button to remove this step.

    2. 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


  3. 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


  4. stepUI and stepUA: Configure as follows and Save:

     

    KEY_IDENTITY_STORE_REF

    OVD


  5. Save the changes.

  6. Restart the OAM Cluster.

  7. Proceed with "Configuring Access Manager for Windows Native Authentication".

43.7 Integrating Access Manager KerberosPlugin with Search Failover

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

  1. Completing tasks in the following earlier sections:

  2. Performing tasks in this section:

  3. "Configuring Access Manager for Windows Native Authentication"

  4. "Validating WNA with Access Manager-Protected Resources"

43.7.1 Registering Microsoft Active Directory Instances with Access Manager

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.

Prerequisites

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).

See Also:

Chapter 4 for details about registering data sources

To register Microsoft Active Directory Global Catalogs with Access Manager

  1. From the Oracle Access Management Console, open the Data Sources node:

    System Configuration tab
    Common Configuration section
    Data Sources node
  2. Click the User Identity Stores node, and then click the Add button in the tool bar.

  3. Enter required values for your first ADGC. For example:


    Name: ADGC1-EXAMPLE
    LDAP Url: ldap://ADGC1_host.domain.com:389
    Principal: cn=Administrator,cn=users,dc=lm,dc=example,dc=com
    Credential: ********
    User Search Base: dc=lm,dc=example,dc=com
    User Name Attribute: userprincipalname
    Group Search Base: dc=lm,dc=example,dc=com
    LDAP Provider: AD
  4. Default Store: Click the Default Store button.

  5. Click Apply to submit the changes and dismiss the confirmation window.

  6. Repeat these steps to add the second ADGC (ADGC2-SPRITE) with appropriate search bases and naming attributes.


    Name: ADGC2-SPRITE
    LDAP Url: ldap://ADGC2_host.domain.com:389
    Principal: cn=Administrator,cn=users,dc=lm,dc=example,dc=com
    Credential: ********
    User Search Base: dc=lmsib,dc=example,dc=com
    User Name Attribute: userprincipalname
    Group Search Base: dc=lmsib,dc=example,dc=com
    LDAP Provider: AD
  7. Restart the AdminServer and OAM Servers.

  8. Proceed to "Setting Up Access Manager KerberosPlugin for ADGCs".

43.7.2 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).

Prerequisites

Preparing Your Active Directory/Kerberos Topology

Performing Oracle-Specific Prerequisite Tasks

See Also:

Chapter 11 for plug-in details

To set up the Access Manager KerberosPlugin for ADGCs

  1. From the Oracle Access Management Console, open the:


    System Configuration tab
    Access Manager section
    Authentication Modules node
    Custom Authentication Modules node
    KerberosPlugin
  2. On the KerberosPlugin page, click the Steps tab.

    Steps Tab: Replace stepKTA, as described here, then click Save.

    1. Click stepKTA then click the Delete (x) button to remove this step.

    2. 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


  3. 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})


  4. stepUI and stepUA: Step Details (configure these steps and save):


    Element Description
     

    KEY_IDENTITY_STORE_REF

    ADGC1-ORACLE


  5. Save the changes.

  6. 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})


  7. Add stepUI2: This will operate in tandem and execute if stepUI fails:


    Element Description
     

    KEY_IDENTITY_STORE_REF

    ADGC2-SPRITE


  8. Add stepUA2: This executes when stepUI2 succeeds:


    Element Description
     

    KEY_IDENTITY_STORE_REF

    ADGC1-EXAMPLE and ADGC2-SPRITE, respectively


  9. 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


  10. Restart the OAM Cluster.

  11. Proceed with "Configuring Access Manager for Windows Native Authentication".

43.8 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:

43.8.1 Creating the Authentication Scheme 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.

Prerequisites

Integrating KerberosPlugin with Oracle Virtual Directory

Or

Integrating Access Manager KerberosPlugin with Search Failover

See Also:

Chapter 16 for authentication scheme details

To create the Kerberos authentication scheme for WNA

  1. From the Oracle Access Management Console, open the Policy Configuration tab, expand the Authentication Schemes node.

  2. Open KerbScheme to display its configuration details and set (or confirm) the following attributes:

    Challenge Method: WNA

    Authentication Module: KerberosPlugin

  3. Finish configuring KerbScheme for your deployment.

  4. Click Apply and close the confirmation window.

  5. Proceed to "Configuring Access ManagerPolicies for Windows Native Authentication".

43.8.2 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.

Prerequisites

Creating the Authentication Scheme for Windows Native Authentication

See Also:

Chapter 17 for details about managing policies

To set Access Manager policies for Windows Native Authentication

  1. From the Oracle Access Management Console, open the Policy Configuration tab, expand the Application Domains node.

  2. Open (or Create) the desired Application Domain, as described in "Managing Application Domains and Policies Using the Console".

  3. Resource Definitions: Add Resource Definitions to the domain as described in "Adding and Managing Resource Definitions to be Added to Policies".

  4. Authentication Policies:

    1. 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.

    2. Click Apply, close the Confirmation window.

    3. Resources for Authentication Policy: Add Resources to the Authentication Policy as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

    4. Complete the Authentication Policy with any desired Responses.

  5. Authorization Policies: Complete the Authentication Policy with any desired Responses or Conditions as described in "Defining Authorization Policies for Specific Resources".

  6. Proceed to "Verifying the Access Manager Configuration File".

43.8.3 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

Example: oam-config.xml

<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>

43.9 Validating WNA with Access Manager-Protected Resources

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

  1. Log in to a Windows system in the Active Directory domain as a domain user.

  2. Sign in to the Windows OS client using the Windows domain credentials stored in a hosted Active Directory that is registered with Access Manager.

  3. Open an Internet Explorer browser window, and enter the URL for the OAM-protected application in your environment.

  4. Confirm that you are logged in to the application with your Windows domain credentials with no additional login.

43.10 Troubleshooting WNA Configuration

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/

43.10.1 Kinit Fails

Error

Client not found in Kerberos database while getting initial credentials

Cause

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.

Solution

Have the Active Directory Administrator search the LDAP tree for duplicate entries of the SPN, and remove them.

43.10.2 Unable To Access a Protected Resource Using WNA Authentication Scheme

Unable to access a resource protected by Access Manager-protected resource using WNA authentication scheme. Error: An incorrect Username or password was specified.

Error

An incorrect username or password was specified.

43.10.3 User Identity Store is Not Active Directory

Cause

The Identity Store used by Access Manager might not point to Windows Active Directory. By default, the identity store is Embedded LDAP.

Solution

  1. Register Active Directory: Oracle Access Management Console, System Configuration, Data Sources, User Identity Store, Create ActiveDirectory.

  2. Set Active Directory as the Default Store, as described in "Setting the Default Store and System Store".