The tasks in this section are required regardless of the approach you choose. However, none of this is Oracle specific.
Note:
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 a sample scenario, consider two Active Directory forests operating within a company.
| Forest | Domain Name |
|---|---|
|
ORACLE |
|
|
SPRITE |
|
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.
The suffixes and inheritance are:
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 user names formed as DOMAIN\USERNAME, are not supported.
For integration with WNA, the User Name Attribute defined for the Default Identity Store can be any attribute whose value matches the Active Directory user's samAccountName.
You also 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
In the trusted domain (for example, the root domain lm.example.com), it is required that you follow the 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 57-1 are used.
Table 57-1 Sample Naming
| 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. |
You can prepare Active Directory and Kerberos.
Commands are for a Unix Operating System. Command syntax will vary depending on the specific Operating System in your environment.
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 user name 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).
The user name should be in the format user_name@example.com where example.com is the domain name of the Active Directory. For example:
ktpass -princ <protocol/oamserver_host> -pass <mypassword> -mapuser <user from step 3> -out <path_to_filename>
Note:
Ensure that the case of the user name is consistent when entering it with the ktpass, kinit and klist commands. If you enter the user name in lower case when running one command, it must be entered in lower case when running the other commands.
For example, the case used in the commands to create the keytabs and the configuration in /etc/krb5.conf file need to match. When ktpass is run to create the keytab (as below), the host name of the KDC server is lm.example.com. Since this is all lower case, the configuration in the /etc/krb5.conf file must also be lower case. Case sensitivity is not the issue as long as the case matches.
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)
Note:
If the user is not part of the Administrators group, follow this procedure to explicitly allow a remote desktop connection for the user.
From the Oracle Access Management Console, navigate to the Remote tab through Control Panel -> Remote Settings -> System Properties.
Select the "allow connections from computers running any version of Remote Desktop" option.
Click Select Users.
Add the user.
Click Apply.
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 "Confirming Access Manager Operations".
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.
When trust relationships are not established between forests, you should configure Kerberos authentication for multiple forests or domains using KerberosPlugin instead of Kerberos authentication module.
Each forest needs to have a Service Principal Name (SPN) that will be used by OAM to authenticate using WNA. You need to add a KTA Plugin for each forest and specify the SPN corresponding to the forest. For appropriate fallback to KTA Plugins, modify failure and error conditions in the Steps Orchestration tab for each KTA Plugin. Meeting the success condition ensures that the Kerberos Token is validated against the specific forest using the specified SPN.