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

ktpass.exe –princ HTTP/[email protected] –mapuser bieesvr1 –pass password -crypto all -ptype KRB5_NT_PRINCIPAL –out C:\bieesvr1.keytab

/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

to HTTP/. Also, consistently, the keytab is generated for a principal named HTTP/. 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.

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

• Create the file following file krb5.conf

[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

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:

• keytab-file is the keytab file
• account-name is the service principal name

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

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

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

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.

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.

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.

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

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.

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

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

• 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

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

• 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

• Stop and delete the previous analytics application. OBI 11G does not support updating the analytics.ear file. Stop and delete the previous analytics.ear file, before deploying the new one.
• Install as an application on the bi_server. More see OBIEE 11g: How To Re-deploy the Analytics.ear File
• Restart the whole system

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.

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.

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

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

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

Procedure:

• OBIEE 11g: Configuring Authentication and SSO with Active Directory and Windows Native Authentication
• Enabling SSO Authentication
• How To Configure Browser-based SSO with Kerberos/SPNEGO and Oracle WebLogic Server - by Abhijit Patil

Others:

• How To Disable/Remove The Default Authenticator From Weblogic For OBIEE 11g
• OBIEE 11g: How To Setup ADSI LDAP Security Provider
• Oracle® Fusion Middleware Securing Oracle WebLogic Server 11g Release 1 (10.3.5) - Configuring Single Sign-On with Microsoft Clients

Debug:

• WebLogic Server Support Pattern: Kerberos and SPNEGO Configuration Issues