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.