OBIEE 11G - SSO Authentication with Windows Native Authentication (WNA)

> Reporting and Data Access Tools > Oracle Business Intelligence (OBIEE/Siebel Analytics)

1 - About

This article will go through an SSO Authentication with Windows Native Authentication (WNA) and kerberos

3 - Prerequisites

Advertising

4 - Architecture

5 - Steps

5.1 - Domain Controller

A Windows 2000 (or later release) Server domain controller can serve as the Kerberos Key Distribution Center (KDC) server for Kerberos-based client and host systems. On any domain controller, the Kerberos Service and the Active Directory (AD) Service will be running automatically, and it is impossible to stop these services.

5.1.1 - Enabling DES Encryption on Windows Server 2008 R2

Windows 7 and Windows Server 2008 R2 by default have DES encryption disabled.

  • Group Policy Management Console (GPMC) (secpol.msc) > Computer Configuration\ Windows Settings\ Security Settings\ Local Policies\ Security Options
  • Network security: Configure encryption types allowed for Kerberos option.
  • Check the (six) check boxes for the encryption types.

5.1.2 - Create an account for the WLS server

Create a new user that will represent the WLS server. This user must have the following properties on the “Account” tab:

  • Check the box: “Use DES encryption types for this account”.
  • Check not: “Do not require Kerberos pre-authentication” (i.e. Weblogic DO require Kerberos pre-authentication)

Verify that you can make a LDAP connection with this account. Setting the encryption type may corrupt the password

Advertising

5.1.3 - Create a keytab file for your Weblogic server

The primary advantage of a keytab is that it isolates the credentials in a separate file and can be used directly by various Kerberos software.

On Unix/Linux machines, the ktpass command should run on the AD domain controller as it will both create the keytab and the SPN simultaneously.

ktpass enables an administrator to configure a non-Windows Server Kerberos service as a security principal in the Windows Server Active Directory.

ktpass.exe –princ HTTP/bieesvr1.xyz2.com@XYZCORP.COM –mapuser bieesvr1 –pass password -crypto all -ptype KRB5_NT_PRINCIPAL –out C:\bieesvr1.keytab

where:

  • bieesvr1.xyz2.com is the qualified name of the weblogic server
  • XYZCORP.COM is the AD domain
  • bieesvr1 is the weblogic AD account
  • and password its password

The keytab file must then be copied to the Weblogic server domain directory i.e. :

/u01/app/oracle/product/fmw/user_projects/domains/bifoundation_domain/bieesvr1.keytab

Ktpass has a side effect; it will change the principal name in the AD server from <account-name> to HTTP/<account-name>. Also, consistently, the keytab is generated for a principal named HTTP/<account-name>. However, sometimes the name change may not happen. If this is the case, you should do it manually in the AD server; otherwise the keytab you have generated will not work properly.

5.2 - Machine (Weblogic Server but can also client)

The WebLogic Server host must be provided with KDC information but the steps below could be also tested on your local machine.

5.2.1 - Configure a machine to find the KDC server

The krb5-1.8 release disables single-DES cryptosystems by default. As a result, you may need to add the libdefaults setting “allow_weak_crypto = true” to communicate with existing Kerberos infrastructures if they do not support stronger ciphers.

[libdefaults]
default_realm = XYZCORP.COM
default_tkt_enctypes = des-cbc-crc
default_tgs_enctypes = des-cbc-crc
ticket_lifetime = 600
[realms]
XYZCORP.COM = {
kdc = 10.221.61.122
admin_server = addc.xyzcorp.com
default_domain = XYZCORP.COM
}
[domain_realm]
.xyzcorp.com = XYZCORP.COM
[appdefaults]
autologin = true
forward = true
forwardable = true
encrypt = true

where:

  • XYZCORP.COM is the real name (ie domain name)
  • 10.221.61.122 is the IP of the domain controller
  • addc.xyzcorp.com is the host name of the domain controller
Advertising

5.2.2 - Kerberos Configuration Verification

5.2.2.1 - kinit

Use the kinit utility to verify that Kerberos is set up properly and that your principal and keytab are valid.

The kinit utility may be used to obtain and cache Kerberos ticket-granting tickets. You can run the kinit utility by entering the following command:

kinit -V -k -t keytab-file account-name

where:

Ie:

kinit -V -k -t exalytics-01.keytab HTTP/exalytics-01.hotitem.local

The output should be similar to the following:

New ticket is stored in cache file /path/krb5cc_myhost

of

Authenticated to Kerberos v5
5.2.2.2 - klist

With klist, you can also see your ticket:

> klist
Ticket cache: FILE:/tmp/krb5cc_501
Default principal: HTTP/[email protected]

Valid starting     Expires            Service principal
07/14/14 14:38:11  07/14/14 14:48:11  krbtgt/[email protected]


Kerberos 4 ticket cache: /tmp/tkt501
klist: You have no tickets cached

5.3 - Weblogic Server

5.3.1 - Configure Weblogic Login Module

5.3.1.1 - krb5Login.conf

JAAS allows dynamic configuration of login modules, so we need to create a JAAS configuration file that specifies the Kerberos login modules.

Create a file named krb5Login.conf in the Weblogic domain directory

/u01/app/oracle/product/fmw/user_projects/domains/bifoundation_domain/krb5Login.conf
com.sun.security.jgss.krb5.accept {
   com.sun.security.auth.module.Krb5LoginModule required
   principal=”<Service principal account>@<Kerberos realm>”
   keyTab=<Name of the keytab file we created, relative to Weblogic domain directory>
   useKeyTab=true
   storeKey=true
   debug=true;
};
com.sun.security.jgss.krb5.accept {
   com.sun.security.auth.module.Krb5LoginModule required
   principal="HTTP/[email protected]"
   keyTab=exalytics-01.keytab
   useKeyTab=true
   storeKey=true
   debug=true;
};

5.3.2 - setDomainEnv.sh

Modify the file setDomainEnv.sh in the bin directory of the domain (bifoundation_domain\bin\) with the following lines:

## Add this part
EXTRA_JAVA_PROPERTIES="-Djava.security.auth.login.config=krb5Login.conf -Djavax.security.auth.useSubjectCredsOnly=false -DWeblogic.security.enableNegotiate=true -Dsun.security.krb5.debug=true ${EXTRA_JAVA_PROPERTIES}"
export EXTRA_JAVA_PROPERTIES
 
 
## before this part
JAVA_PROPERTIES="${JAVA_PROPERTIES} ${EXTRA_JAVA_PROPERTIES}"
export JAVA_PROPERTIES

You can also add this property:

-Djava.security.krb5.conf=<path>/krb5.conf 

if the krb5 file configuration is not in its default location.

5.3.3 - New Negotiate Identity Assertion provider

WebLogic Server includes a security provider, the Negotiate Identity Assertion provider, to support single sign-on (SSO) with Microsoft clients. This identity assertion provider decodes Simple and Protected Negotiate (SPNEGO) tokens to obtain Kerberos tokens, validates the Kerberos tokens, and maps Kerberos tokens to WebLogic users.

The new provider must be below the AD provider.

The Negotiate Identity Assertion provider is used for SSO with Microsoft clients that support the SPNEGO protocol. Specifically, it decodes SPNEGO tokens to obtain Kerberos tokens, validates the Kerberos tokens, and maps Kerberos tokens to WebLogic users. The Negotiate Identity Assertion provider utilizes the Java Generic Security Service (GSS) Application Programming Interface (API) to accept the GSS security context via Kerberos. For more information about the Java GSS API

The Negotiate Identity Assertion provider interacts with the WebLogic Servlet container which handles:

  • WWW-Authenticate
  • and WWW-Authorization

headers, adding the appropriate Negotiate header.

By default, the Negotiate Identity Assertion provider is available but not configured in the WebLogic default security realm. The Negotiate Identity Assertion provider can be used instead of or in addition to the WebLogic Identity Assertion provider.

5.3.4 - Identity Assertion provider

Identity Assertion providers are used as part of perimeter authentication process. See Identity Assertion Process

In perimeter authentication, a system outside of WebLogic Server establishes trust via tokens (and not via usernames and passwords).

  • When perimeter authentication is used, a token from outside of the WebLogic Server domain is passed to an Identity Assertion provider in a security realm that is responsible for validating tokens of that type and that is configured as “active.”
  • If the token is successfully validated, the Identity Assertion provider maps the token to a WebLogic Server username, and sends that username back to WebLogic Server, which then continues the authentication process. Specifically, the username is passed to each configured Authentication provider's LoginModule, so that the LoginModule can populate the subject with the appropriate principals.

5.3.5 - Weblogic Validation

  • Stop Weblogic
  • And start it in the console in order to see the process
  • If it starts successfully, start it in the background

5.4 - OBI Application Protection

In order for authentication to take place, the resource (JSP or Servlet) being accessed must be protected, and for the Web application to participate in Single Sign-On with the client, the authentication mechanism must be set to CLIENT-CERT. This will enable WebLogic authentication to rely on the Kerberos authentication information. However, the obtained user name must be found inside the WebLogic users repository. If WebLogic is configured to use the same AD server as the one associated to the KDC, then the user will certainly authenticate. Otherwise, you must make sure that such a user can be found in the WebLogic user repository.

Moreover, Kerberos does not handle authorization; this will be resolved within WebLogic. In order to authorize your Windows user to access the resource, you need to restrict access to the resource to a specific role. This role will translate into a set of principals. If the logged user of the Client machine belongs to that set of principals, then the resource will be automatically granted to the browser.

5.4.1 - Unpack

cd /u01/app/oracle/product/fmw/Oracle_BI1/bifoundation/jee
# backup
cp analytics.ear analytics.ear.20140714
# create a working dir
mkdir tmp_20140714
# Copy the analytics.ear file
cp analytics.ear tmp_20140714
cd tmp_20140714
# Use the Jdk of BI
export PATH=/u01/app/oracle/product/fmw/Oracle_BI1/jdk/bin:$PATH
jar -xvf analytics.ear
  created: META-INF/
 inflated: META-INF/MANIFEST.MF
 inflated: META-INF/application.xml
 inflated: analytics.war
 inflated: analytics-ws.war
 inflated: META-INF/weblogic-application.xml
  • Unpack the analytics.war file to a second temporary location; it contains a default.jsp file and five top-level directories
mkdir tmp_analytics
cp analytics.war tmp_analytics
cd tmp_analytics/
jar -xvf analytics.war
..........................
..........................
 inflated: workspace/resources/th/global.js
 inflated: workspace/resources/tr/biee.js
 inflated: workspace/resources/tr/global.js
 inflated: workspace/resources/zh-CN/biee.js
 inflated: workspace/resources/zh-CN/global.js
 inflated: workspace/resources/zh-TW/biee.js
 inflated: workspace/resources/zh-TW/global.js

5.4.2 - weblogic.xml

  • in the WEB-INF directory, modify or create the weblogic.xml file descriptor with the following nodes:
<?xml version = '1.0' encoding = 'US-ASCII'?>
<weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app">
 .......................
 .......................
	<context-root>analytics</context-root>
	<security-role-assignment>
		<role-name>SSORole</role-name>
		<principal-name>Weblogic Group/User 1</principal-name>
		<principal-name>Weblogic Group/User N</principal-name>
                <principal-name>BISystemUser</principal-name>
	</security-role-assignment>
</weblogic-web-app>

The name of the role is not important and the principal name is the group name (cn) of AD. All BI users will need to be members of at least one of the these groups.

5.4.3 - Web.xml

  • web.xml. Add below and above the login-config node, this two nodes:
        <security-constraint>
		<web-resource-collection>
			<web-resource-name>BI Analytics</web-resource-name>
			<url-pattern>/*</url-pattern>
		</web-resource-collection>
		<auth-constraint>
			<role-name>SSORole</role-name>
		</auth-constraint>
                <user-data-constraint>
                       <description>SSL not required</description>
                       <transport-guarantee>NONE</transport-guarantee>
                </user-data-constraint>
	</security-constraint>
 
	<login-config>
		<auth-method>CLIENT-CERT</auth-method>
	</login-config>
	<security-role>
		<role-name>SSORole</role-name>
	</security-role>

where login-config > auth-methode can have the following value

  • BASIC: Basic authentication uses the Web Browser to display a username/password dialog box. This username and password is authenticated against the realm.
  • FORM: Form-based authentication requires that you return an HTML form containing the username and password
  • CLIENT-CERT: Uses client certificates to authenticate the request

See The Java EE 6 Tutorial - Authentication Mechanisms

5.4.3.1 - SPNEGO

The Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) internet standard (RFC 2478) is used to negotiate either Kerberos, NTLM, or other authentication protocols supported by the operating system. SPNEGO is commonly referred to as the “negotiate” authentication protocol.

In the case of HTTP, SPNEGO is Kerberos-aware.

the SPNEGO authentication mechanism (Simple and Protected GSS-API Negotiation), also known as ‘integrated authentication’ or ‘negotiate authentication’.

The security constraint is there to request the SPNEGO/Kerberos authentication information

SPNEGO tokens are passed between an browser client and a web server by using HTTP headers. For cross-platform authentication to work, non-Windows web servers will need to parse SPNEGO tokens to extract Kerberos tokens and later build response tokens to send back to the browser

5.4.4 - Package

  • Create the jar file
rm analytics.war
jar cMf analytics.war *
cp analytics.war ..
cd ..
rm -rf tmp_analytics/
rm analytics.ear
jar cMf analytics.ear *
cp analytics.ear ..
cd ..
rm -rf tmp_20140714/
  • Verify that the file size are not really different

5.4.5 - Deploy the new application package

5.5 - Configure BI for SSO

6 - Client

6.1 - Account

Configure your user to comply with the Kerberos protocol:

The encryption type for this account must be DES, and the account must require Kerberos pre-authentication.

6.2 - Browser

https://developer.mozilla.org/en-US/docs/Integrated_Authentication

To enable SPNEGO, the URL in question must be whitelisted using the Firefox configuration setting network.negotiate-auth.trusted-uris.

7 - Support

7.1 - Log

When using kinit, you can check the events that are logged in the System log on the domain controller

7.2 - Enable Debug

Weblogic Console > Servers > [Server Name] (bi_server1 normally )> Debug > WebLogic > Security > atn (for Authentication) and atz (for Authorization) and enable 'DebugSecurityAtn'

7.3 - not SPNEGO NegTokenInit token

The following messages appear in the bi_server1.log when the user attemps to log:

<CERT auth type found for webapp> 
<All request headers:> 
<  Header: Accept : application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*> 
<  Header: Accept-Language : nl-NL> 
<  Header: User-Agent : Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; <  Header: Accept-Encoding : gzip, deflate> 
<  Header: Host : exalytics-01.hotitem.local:9704> 
<  Header: DNT : 1> 
<  Header: Connection : Keep-Alive> 
<  Header: Cookie : JSESSIONID=JvpbTTVGhQhVfLCJBhz0Wyqk4XvYKvXJxn2KVDFxL3BNvBhBj3pK!184693701> 
<  Header: Authorization : Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==> 
<    processing header: Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==> 
<SPNEGONegotiateToken.discriminate: not Application Constructed Object, not SPNEGO NegTokenInit token> 
<Token not supported by Negotiate Filter, ignoring: NTLM> 
<Negotiate filter: existing session, negotiation was started> 
<Request doesn't have Negotiate response, Negotiate filter ignoring> 
<Passing to next filter in the chain> 

See OBIEE 11g: After Apply A Microsoft Kerberos Patch, OBIEE Authentication Fails With "Error 401 Unauthorized" Using Kerberos SSO.

NTLM (NT LAN Manager) token is received rather than Kerberos token. NTLM token is much smaller than Kerberos one:

  • NTLM token:
Authorization : Negotiate TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFASgKAAAADw==>
  • Kerberos token:
Authorization : Negotiate YIIE7wYGKwYBBQUCoIIE4zCCBN+gJDAiBgkqhkiC9xIBAgIGCSqGSIb3EgEC
AgYKKwYBBAGCNwICCqKCBLUEggSxYIIErQYJKoZIhvcSAQICAQBuggScMIIEmKADAgEFoQMCAQ6iBwM
FACAAAACjggPAYYIDvDCCA7igAwIBBaEOGwxXV1NMLkJFQS5DT02iJzAloAMCAQKhHjAcGwRIVFRQGxR
zbHpvbmVzMDAuYmVhc3lzLmNvbaO

8 - Documentation / Reference

dat/obiee/wna.txt · Last modified: 2019/04/26 20:21 by gerardnico