Kerberos Archive

Multiple Users Forest SSO

In our lab we created 3 new forests with 3 domains, with 3 DNS servers to simulate complex  environment.
Forest DomainA.com
DomainA.com
Domain Controller: DCNL01.domainA.com
WorkStation: DSKNL01
Test user : userA pass:Pumpkin1
sso binding user: ssoA pass: Pumpkin1App
LDAP principal :  WLSAdminA@domaina.com pass:Pumpkin1
Forest DomainB.com
DomainB.com
DC: DCNL02.domainB.com
WorkStation: DSKNL02
Test user: userB pass:Pumpkin1
sso binding user: ssoB pass:Pumpkin1App
LDAP principal :WLSAdminB@domainb.com pass:Pumpkin1

Forest DomainApp.com
DomainApp.com
DC: DCNL03.domainApp.com
WorkStation: DSKNL03
Test user: userApp pass:Pumpkin1
sso binding user: ssoApp pass:Pumpkin1App
V11CON01.domainApp.com – Weblogic  server
LDAP: WLSAdminApp pass:Pumpkin1

Application (Weblogic)  server installed in DomainApp.com
Application  Users created in all 3 domains.
Service users for LDAP and SSO created in each domain.
Important:   KRB Principal should all have the same passwords, key version numbers, and encryption types.
sso user: ssoApp@domainapp.com pass:Pumpkin1App
sso user: ssoB@domainb.com pass:Pumpkin1App
sso user: ssoA@domaina.com pass: Pumpkin1App

DNS resolution need to be in place.

LDAP

Weblogic configured with 3 LDAP authentications. Order is important. If you put asserter before DomainB, domainB will do only LDAP.

SSO

SSO command run on each DC:
DCNL03.domainApp.com
Setspn:  setspn -A HTTP/v11con01.domainapp.com ssoApp
Ktpass run: ktpass   -out SSOKeyTabFile  -kvno 0 -princ HTTP/v11con01@DOMAINAPP.COM -mapuser ssoApp -pass Pumpkin1App  -crypto RC4-HMAC-NT
Ssokeytab collected (out SSOKeyTab) and we will use it for our Weblogic.
Full output of ktpass command :

DCNL01.domaina.com
Setspn:  setspn -A HTTP/v11con01.domainapp.com ssoa
Ktpass run: ktpass   -kvno 0 -princ HTTP/v11con01@DOMAINAPP.COM -mapuser domain\ssoa -pass Pumpkin1App  -crypto RC4-HMAC-NT

DCNL02.domainb.com
Setspn:  setspn -A HTTP/v11con01.domainapp.com ssob
Ktpass run: ktpass   -kvno 0 -princ HTTP/v11con01@DOMAINAPP.COM -mapuser domainb\ssob -pass Pumpkin1App  -crypto RC4-HMAC-NT

Files for SSO created on application server

Krb5.ini (Located in C:\Winnt)

krb5login.conf

 

SSOKeyTabFile (generated on the first DC)

After deploying our application we can test sso:

Tickets from workstation in domaina.com

 

Tickets from workstation in domainApp.com

 

Tickets from workstation in domainB

Natalya (natalya.luke@gmail.com)

What is Kerberos?

Three parties are involved in Kerberos Based Authentication – Client, Server and a Kerberos Distribution Centre.

The diagram below clearly demonstrates how the interactions between the three parties happen.

1 – Client requests for a TGT (Ticket to Get Tickets) from the KDC (Key Distribution Centre). Client sends its username in plain text format to get the TGT.

2 – KDC returns a TGT to the client. The TGT has the Session Key (SK) which is encrypted with a Key derived from the Client’s password. Hence only the Client will be able to retrieve the Session Key. This Session Key is used for all furthur communications between the Client and the KDC.

3 – The Client requests for a Service Ticket (ST) to the KDC by providing the Service name along with the Session Key for its own identification. The KDC will be able to provide the ST only if the Service is already registered with it.

4 – The KDC creates the Service Ticket. The Service Ticket has the Client’s Authentication Data and a Sub Sesion Key (SSK). The Service Ticket is then encrypted with a Key Derived from the Server’s Key which is shared with the KDC. This ensures that the Service Ticket can only be decrypted by the Server. The KDC then authors a message containing the Service Ticket and a Sub Session Key. The whole message is then encrypted with the Session Key so that only the intended Client can decrypt it.

Pictorially the Message looks like this.

5 – The Client decrypts the Message with the Session Key, retrieves the Service Ticket and the Sub Session Key. It sends the Service Ticket to the Server. This Service Ticket is the SPNEGO Token. The Server decrypts the Service Ticket with its Key and authenticates the Client based on the Clients Authentication Data. Also it gets a copy of a Sub Session Key from the Service Ticket. Now both the Client and the Server have a common key, Sub Session Key, which they use for all further communication.

6 – A session is established and no further authentication is required.

References :-

http://technet.microsoft.com/en-us/library/bb742516.aspx

Windows 7: DES encryption support for kerberos authentication

By default Windows 7 doesn’t support DES encryption, so this can prevent kerberos authentication from working.

So to enable DES encryption support we need to do following configuration at Windows 7 client machine.

Go to Local Security Policies(By typing “Local Security Policies” in run dialog)->Local Policies->Security Options->Network security: Configure encryption types allowed for Kerberos:
Here select checkboxes against DES_CBC_CRC, DES_CBC_MD5 and RC4_HMAC_MD5.

Refer below snap:

After doing this configuration you should be able to successfully run kerberos authentication at your Windows 7 client.

Kerberos in a Proxy/Load Balancer/ Weblogic Cluster

Recently one of my colleague pointed out that I did not cover few aspects of Kerberos configurations in an earlier post. He had few queries such as how should he set the service principal name if a proxy is there in front of Weblogic Server. Or for that matter if there is a cluster of Weblogic Server.

Here are the answers.

If the proxy server is on the same machine as WLS, then the steps remain the same (outlined in an earlier post). The Kerberos ticket will be propagated to WLS.

If it’s in a different machine, then both the proxy url and the WLS url should be registered with WLS.

e.g.

WLS Server Machine: beaiis
Proxy Server Machine: beaproxy

setspn -a HTTP/ beaiis.BEATEST.COM beawin
setspn -a HTTP/ beaproxy.BEATEST.COM beawin

And then configure your client browser with the proxy server url.

For a cluster of Managed servers running on different machine.

WLS Server Machine1 : beaiisone
WLS Server Machine2 : beaiistwo
WLS Server Machine3 : beaiisthree
Proxy Server Machine :beaproxy

Then we have to register all the urls with the KDC

setspn -a HTTP/ beaiisone.BEATEST.COM beawin
setspn -a HTTP/ beaiistwo.BEATEST.COM beawin
setspn -a HTTP/ beaiisthree.BEATEST.COM beawin
setspn -a HTTP/ beaproxy.BEATEST.COM beawin

And then verify

setspn -L beawin
Registered ServicePrincipalNames for CN=beawin,CN=Users,DC=BEATEST,DC=COM

HTTP/beaproxy.BEATEST.COM
HTTP/beaiisone.BEATEST.COM
HTTP/beaiistwo.BEATEST.COM
HTTP/beaiisthree.BEATEST.COM

Each Server will have the same keytab and krb5Login.conf file, preferably copied to the domains directory on all machines. And in the Client browser the local internet setting should have the proxy url.

Troubleshooting Kerberos Issues with Weblogic Server

Found NTLM token when expecting SPNEGO

The browser is not set up correctly to send a spnego token, go back to the client configuration, and double check the browser configuration. IE needs to be configured with Integrated Windows Authentication should be turned on and the site listed in the Intranet domain. IE also needs to be configured with automatic logon. After making these changes, make sure to restart IE.

Refer to this link for IE Settings:-

http://msdn.microsoft.com/en-us/library/ms995329.aspx

Something is wrong in your SPN definition. Either no SPN was defined for this service, or you have duplicate SPNs, which means that the SPN resolved in more than one principal associated with it. You can verify this by typing:

LDIFDE -d DC=yourdomain ,DC=com -f c:\export.txt

This will export the list of AD objects to the file export.txt. Then look for your service (HTTP/) in the values of the attribute
ServicePrincipalName. If it shows more than once or not at all, you to overcome this exception remove the user account in AD and create again. Start all over the procedure from all over again.

Failure unspecified at GSS-API level (Mechanism level: Invalid argument (400) – Cannot find key of appropriate type to decrypt AP REP – RC4 with HMAC)

Active Directory account is configured to use the default
encryption type on Windows (RC4-HMAC). You can switch to use DES, by selecting “use DES encryption” in the AD account settings. After you switching to DES, reset the password.

In order to use RC4-HMAC, you’ll need to update the Kerberos configuration file to specify the encryption type.

default_tkt_enctypes = rc4-hmac
default_tgs_enctypes = rc4-hmac

Ref: – http://java.sun.com/javase/6/docs/technotes/guides/security/jgss/jgss-features.html

Pre-authentication information was invalid (24)

This means that the service account password in the Active Directory and the password in the keytab file does not match. Make sure you have the correct password specified while generating the keytab file. Also, this error could be due to invalid principal name in the krb5login.conf file. When generating the keytab file using the ktpass utility, the principal name will be changed to HTTP/. Make sure you specify the principal name in the keytab file as HTTP/.

Double check the validity of your keytab, or of the password that you have entered. If you are confident about your password, many times, refreshing the password for the user in the AD server may solve the problem. (by right clicking on the user, selecting “Reset Password” and re-entering the same password specified earlier).

Another reason for that problem to happen is if there exist another
principal with the same short name in the AD server (different DNs but same CN).This is likely to happen if the host that runs WebLogic server already belongs to the network domain, then it will have an account in the Computers section,and a password there too. In that case, you will run into SPN issues as well.

The best way out of this is to create a new user account, with a different CN, and map the HTTP SPN to the new account, (and remove the SPN from any other account).

If the WebLogic server host is also on the same domain (or registerd with the same KDC/AD) where you are creating the SPN then there must a machine name already exists which has the mapping for the same URL which you want to map with SPN. In such cases best way is to create a DNS alias for WebLogic host and map the DNS alias with the machine name.

Ref: – http://forums.oracle.com/forums/thread.jspa?threadID=876942&tstart=0

Known issue with Windows Server 2003 SP1. Contact Microsoft for a fix.
-http://support.microsoft.com/kb/919557/en-us
http://hotfixv4.microsoft.com/Windows%20Server%
202003/sp2/Fix183877/3790/free/277896_ENU_i386_zip.exe

Failure unspecified at GSS-API level (Mechanism level: Checksum failed)

If the keytab files being generated by the ( Ktab\ktpass) JDK shipped with either WLS 9.x or WLS 10.0, the SSO is getting failed. If the keytab files being generated with JDK < 1.5.0_8, SSO getting failed with unsupported algorithm exception for WLS 10 server.Use JDK >= 1.5.0_8 to generate keytab files, then issue solves and the SSO works.

Even applying the following HOT FIX Might Help

http://support.microsoft.com/default.aspx?scid=kb;en-us;833708

Client not found in Kerberos database while getting initial credentials

This means that the principal does not exist in AD. Check and make sure that the <serviceaccount@domain> matches exactly the user logon name in AD.

KDC has no support for encryption type (14)’ error.

Cause 1: Your KDC does not support the encryption type requested.
Solution 1: Sun’s implementation of Kerberos supports the following encryption types: des-cbc-md5, des-cbc-crc and des3-cbc-sha1.
Applications can select the desired encryption type by specifying following tags in the Kerberos Configuration file krb5.conf:
[libdefaults]
default_tkt_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
default_tgs_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
permitted_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1

If not specified, the default value is:
des-cbc-md5 des-cbc-crc des3-cbc-sha1

Cause 2: This exception is thrown when using native ticket cache on some Windows platforms. Microsoft has added a new feature in which they no longer export the session keys for Ticket-Granting Tickets (TGTs). As a result, the native TGT obtained on Windows has an “empty” session key and null EType. The effected platforms include: Windows Server 2003, Windows 2000 Server Service Pack 4 (SP4) and Windows XP SP2.
Solution 2: You need to update the Windows registry to disable this new feature. The registry key allowtgtsessionkey should be added–and set correctly–to allow session keys to be sent in the Kerberos Ticket-Granting Ticket.
On the Windows Server 2003 and Windows 2000 SP4, here is the required registry setting:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Value Name: allowtgtsessionkey
Value Type: REG_DWORD
Value: 0x01 ( default is 0 )
By default, the value is 0; setting it to “0x01” allows a session key to be included in the TGT.
Here is the location of the registry setting on Windows XP SP2:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\
Value Name: allowtgtsessionkey
Value Type: REG_DWORD
Value: 0x01

Ref:-

http://java.sun.com/j2se/1.5.0/docs/guide/security/jgss/tutorials/Troubleshooting.html

GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new ACCEPT credentials failed!

There are multiple reasons for this exception:

The principal exists in kerberos but the password is wrong. This is a
password problem. Double check the validity of your keytab, or of the password that you have entered. If you are confident about your password, many times, refreshing the password for the user in the AD server may solve the problem. (by right clicking on the user, selecting “Reset Password” and re-entering the same password specified earlier).

If there exist another principal with the same short name in the AD server (different DNs but same CN). This is likely to happen if the host that runs WebLogic server already belongs to the network domain, then it will have an account in the Computers section, and a password there too. In that case, you will run into SPN issues as well. The best way out of this is to create a new user account, with a different CN, and map the HTTP SPN to the new account, and remove the SPN from any other account).
If the WebLogic server host is also on the same domain (or registerd with the same KDC/AD) where you are creating the SPN then there must a machine name already exists which has the mapping for the same URL which you want to map with SPN. In such cases best way is to create a DNS alias for WebLogic host and map the DNS alias with the machine name.

Clock skew – If the time on the KDC and on the client differ significanlty (typically 5 minutes), this error can be returned. Synchronize the clocks (or have a system administrator do so).

The Kerberos realm name is not all uppercase. Make the Kerberos realm name all uppercase. Note: It is recommended to have all uppercase realm names. For details, refer to the Naming Conventions for the Realm Names and Hostnames section of this tutorial.

Ref: –

http://java.sun.com/j2se/1.5.0/docs/guide/security/jgss/tutorials/Troubleshooting.html

There is a known issue reported from SUN JDK 1.4.2_14, which also affects Jrockit JVM also.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6605907

This issue is fixed in JDK 1.4.2_18. http://java.sun.com/j2se/1.4.2/ReleaseNotes.html#142_18
(Check for the bug number: 6570062).

Also, the same issue is fixed in JRockit R27.6.2 also.

GSSException: Failure unspecified at GSS-API level (Mechanism level: Integrity check on decrypted field failed (31)

In case of multiple domain controllers where there is one root domain beatest.com and two children domains viz. child-a.beatest.com and
child-b.beatest.com, SSO works for request from user logged in child-a but fails when sent from a user logged in child-b with the following exception:

GSSException: Failure unspecified at GSS-API level (Mechanism level:
Integrity check on decrypted field failed (31))

This error occurs when you haven’t sufficiently purged your tickets. Meaning you changed the SPN but the client tried to use an old ticket so the server couldn’t decrypt it with the service principal key. Make sure you purge your tickets with kerbtray.exe after you set the password on the service account.

Ref:-

http://forums.sun.com/thread.jspa?threadID=5358178&tstart=0

Configuring Kerberos with Weblogic Server

Details

Domain Name: BEATEST.COM
Domain Controller Name: BEAAD (This machine runs Active Directory)
WL Server Machine Name: beaiis (This machine runs Weblogic server).

For BEAAD:-

Username : beauser
Password :

For beaiis :-

Username : beaiis
Password : Secure04

Steps on Domain Controller (BEAAD)

1) Create a User beawin in Active Directory. Go to user properties > account and under account options, select Use DES encryption types for this account. After this, reset the password for this user.

2) Set the Service Principal Name.

setspn -a HTTP/ beaiis.BEATEST.COM beawin

3. Test the service principal name.

setspn –L beawin

3) Generate a key tab using ktab

ktab -k beawin.keytab –a beawin@BEATEST.COM

4) Test the keytab file

klist –k beawin.keytab

Note: klist is a jdk utility

5) Copy the generated keytab file (beawin.keytab) to the domain directory of weblogic.
D:\bea922\user_projects\domains\Kerberos_New

6) Place krb5.ini file in C:\winnt folder. Content of the file shown later in the document.

Steps on Machine Hosting Weblogic Server (beaiis)

1) Set the environment and run the kinit utility

java -Dsun.security.krb5.debug=true sun.security.krb5.internal.tools.Kinit -k -t D:\bea922\user_projects\domains\Kerberos_New\beawin.keytab beawin@BEATEST.COM

This should generate a new Kerberos key and place it in the user’s home folder.

2) Make sure you have all the parameters correctly set in

C:\WinNT\krb5.ini

krb5.ini

[libdefaults]
default_realm = BEATEST.COM
kdc_timesync = 1
ccache_type = 4
ticket_lifetime = 600
clockskew = 1200

[realms]
BEATEST.COM = {
kdc = 192.168.1.1
admin_server = BEAAD
default_domain = BEATEST.COM
}

[domain_realm]
.beatest.com = BEATEST.COM

[appdefaults]
autologin = true
forward = true
forwardable = true
encrypt = true

3) Create a krb5login.conf file with the following entries in your domain directory D:\bea922\user_projects\domains\Kerberos_New

krb5login.conf

com.sun.security.jgss.initiate {
com.sun.security.auth.module.Krb5LoginModule required
principal=”beawin@BEATEST.COM” useKeyTab=true
keyTab=beawin.keytab storeKey=true debug=false;
};
com.sun.security.jgss.accept {
com.sun.security.auth.module.Krb5LoginModule required
principal=”beawin@BEATEST.COM” useKeyTab=true
keyTab=beawin.keytab storeKey=true debug=false;
};

4) Add the following parameters in the startup script startweblogic.cmd

-Djava.security.auth.login.config=krb5Login.conf -Djavax.security.auth.useSubjectCredsOnly=false -Dweblogic.security.enableNegotiate=true

5) Configure NegotiateIdentityAsserter from the console

Home > Summary of Security Realms > myrealm > Providers > Authentication >
Create new NegotiateIdentityAsserter

Leave the default Active Types
Under Provider Specific, uncheck Form Based Negotiation Enabled

Activate the changes and restart the server.

7) Create a user beawin in Weblogic Server.

8) Deploy the web application

Web.xml

<web-app>
<display-name>SEC81</display-name>
<security-constraint>
<display-name>Security Constraint for SSO </display-name>
<web-resource-collection>
<web-resource-name>My webapp</web-resource-name>
<description>Group of Users</description>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>SSOrole</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>
<security-role>
<description>Role description</description>
<role-name>SSOrole</role-name>
</security-role>
</web-app>

Weblogic.xml

<weblogic-web-app>
<security-role-assignment>
<role-name>SSOrole</role-name>
<principal-name>beawin</principal-name>
</security-role-assignment>
</weblogic-web-app>
28. Deploy the web app in weblogic.
29. Start the weblogic server.

Configuring Internet Explorer

NOTE: THIS STEPS NEEDS TO BE DONE ON EACH CLIENT MACHINE THAT BROWSES THE PROTECTED WEB APPLICATION

1. Got to Tools –> Internet Options
2. Select the “Security” tab
3. Click on “Local Intranet” Icon. This will enable the “Sites” button.
4. Click “Sites” button. This will show a “Local Intranet” Popup.
5. Make sure the option “Include all local (intranet) sites not listed in other zones” option selected. (Windows XP Only).
6. Click on “Advanced” Button. In the new popup window add the URL for the machine hosting weblogic.
7. Click OK to save your settings.
8. In the “Security” tab, Click “Custom Level” button.
9. In the “Security Settings” dialog, under “User Authentication” section, make sure “Automatic logon only in Intranet zone” option is selected.
10. Click OK to save your settings.
11. Go to “Connections” tab —> LAN Settings.
12. If you have a proxy server enabled, Click on “Advanced” button. Make sure you add the URL for the machine hosting weblogic in the “Exceptions” box.
13. In the “Internet Options —> Advanced” tab, make sure “Enable Integrated Windows Authentication (requires restart)” option is checked. Click “OK”. (If this option is not selected previously, you need to close all browser instances for the setting to take effect).