Basic deployment test case for OpenSSO - Windows Desktop SSO Feature with Active Directory Domain Controller

This example uses:
Active Directory on Windows Server 2003 Standard Edition Service Pack 2
AD Domain name : SUST.IDM.COM
Windows Server machine name: parrot
IE Version : 7.0.5730.13
OpenSSO update-1 Patch-2
OpenSSO host name : avatar.red.iplanet.com

*****************************************************
Step-1: Active Directory Configuration:
*****************************************************
1. Login as administrator to the Windows Server.

2. Open "Manage Your Server" wizard
(Start Menu -> Administrative tools -> Manager Your Server)

3. Choose "Add or remove a role" option

4. Navigate to next screen "Configure Your Server Wizard".
(In the navigation process, if you run into any network connection warnings,
click continue and go ahead")

5. Choose "Domain Controller (Active Directory)" option

6. In the new wizard that pops up, choose default values.

7. Continue navigating. When you get a screen to enter Domain name, enter
SUST.IDM.COM - all capital letters. NetBIOS name as SUST (default value).

8. Navigate till you get an error for DNS.
Accept "Install and configure DNS on this server" option.

9. Complete installation process, restart the machine.

10. Login to the new domain just created SUST as Administrator

*****************************************************
Step-2: Create user account for OpenSSO server in AD
*****************************************************
1. Open "Manage Your Server" wizard.

2. Choose "Manage users and computers in Active Directory" option under Domain Controller role.

3. Go to "Users" menu under SUST.IDM.COM domain

4. Create a new user object with first name, last name, full name, logon name as: avatar
This is the name of the opensso host name so that you can easily remember.The default
password policy in Windows enforces atleast one capital letter and atleast one number. So
choose Password123 for simplicity.
NOTE: Do not have spaces in "Full Name" or logon name.
Else you will get DnsCrack error in the next configuration steps.

5. Open command prompt

6. CD to the directory where you want to have keytab file.

7. Run the following ktpass command:
C:\userData\lakshman>ktpass /princ HTTP/avatar.red.iplanet.com@SUST.IDM.COM /pass Password123 +DesOnly /crypto DES-CBC-CRC /ptype KRB5_NT_PRINCIPAL /mapuser avatar /out avatar.HTTP.keytab

Expected output in command prompt:
Targeting domain controller: parrot.SUST.IDM.COM
Successfully mapped HTTP/avatar.red.iplanet.com to avatar.
Key created.
Output keytab to avatar.HTTP.keytab:
Keytab version: 0x502
keysize 67 HTTP/avatar.red.iplanet.com@SUST.IDM.COM ptype 1 (KRB5_NT_PRINCIPAL)
vno 3 etype 0x1 (DES-CBC-CRC) keylength 8 (0x98628cd615045bc8)
Account avatar has been set for DES-only encryption.

8. ftp (in binary format) this keytab (avatar.HTTP.keytab) file to OpenSSO machine. In this example, ftp to the machine avatar.red.iplanet.com to the directory: /work/installations/opensso/patch/ad/

*****************************************************
Step-3: Validate keytab file on OpenSSO host name
*****************************************************

Command-1:
bash-3.00# klist -ek -t avatar.HTTP.keytab

Expected output in bash shell is:

Keytab name: FILE:avatar.HTTP.keytab
KVNO Timestamp Principal
---- ----------------- ---------------------------------------------------------
3 12/31/69 16:00:00 HTTP/avatar.red.iplanet.com@SUST.IDM.COM (DES cbc mode with CRC-32)


Command-2:
In "Active Directory Users and Computer" wizard on Windows Server 2003 machine, open user profile for avatar. Click on Account sub tab. Check that the value of field "User logon name as:
HTTP/avatar.red.iplanet.com

********************************************************
Step-4: Configure windows desktop SSO module in OpenSSO
********************************************************
1. Create a new authentication module - winsso. The parameters are:

Service Principal: HTTP/avatar.red.iplanet.com@SUST.IDM.COM

Keytab File Name: /work/installations/opensso/patch/ad/avatar.HTTP.keytab

Kerberos Realm: SUST.IDM.COM

Kerberos Server Name: parrot.red.iplanet.com

Return Principal with Domain Name: Disable check box

Authentication Level: 0

********************************************************
Step-6: Create Administrator profile in OpenSSO
********************************************************
1. Create a profile for Administrator in OpenSSO under Realm -> Subjects
For simplicity fill all name fields as Administrator and a password of your choice.

********************************************************
Step-7: Synchronize time & Restart
********************************************************
1. Synchronize time on both Windows Server 2003 machine and OpenSSO host name.
Seconds difference is acceptable in the synch process.

2. Restart container hosting OpenSSO war application - I mean OpenSSO server.

********************************************************
Step-8: Configure browser on Windows Server 2003 machine
********************************************************
1. This test scenario will use browser on Windows Server 2003 Domain Controller to test Windows Desktop SSO feature.

2. IE Browser (above 6.0 version):
a. Go to: Tools Menu -> Internet Options -> Security
b. Choose Local Intranet.
c. Click on Sites
d. Add OpenSSO machine name URL to the list. In this example
http://avatar.red.iplanet.com

3. Mozilla Firefox:
a. Open browser, enter about:config
b. Accept warnings, promises.
c. Double click the Preference Name network.negotiate-auth.trusted-uris.
d. In the values text box that pops up, enter http://,https://

********************************************************
Step-9: Testing
*******************************************************
1. Login as Administrator to SUST.IDM.COM domain on Windows Server 2003 machine.
2. Open IE browser. Enter http://avatar.red.iplanet.com:8080/opensso/UI/Login?module=winsso
3. You should see end user profile page for administrator in OpenSSO
4. Repeat test with Mozilla firefox and verify.


*******
NOTES:
*******

Expected OpenSSO debug file output:
------------------------------------
The debug file Authentication on OpenSSO should have the following snippet in "message" mode.
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:351 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
New Service Login ...
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:423 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
Service login succeeded.
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:430 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
SPNEGO token:
60 82 04 f1 06 06 2b 06 01 05 05 02 a0 82 04 e5
30 82 04 e1 a0 24 30 22 06 09 2a 86 48 82 f7 12
01 02 02 06 09 2a 86 48 86 f7 12 01 02 02 06 0a
2b 06 01 04 01 82 37 02 02 0a a2 82 04 b7 04 82
.... REALLY BIG BLOB ...
d0 f1 bc e3 fc d0 2c 7a 59 a3 c8 2a 35 cc 71 f6
d9 cd e6 c0 2e bb 7e 37 c9 6e fd 1a bc 14 82 7e
fe a0 29 3b a7
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:431 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
token tag:60
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:431 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
SPNEGO OID found in the Auth Token
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:431 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
DerValue: found init token
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:431 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
DerValue: 0x30 constructed token found
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:435 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
Kerberos token retrieved from SPNEGO token:
60 82 04 af 06 09 2a 86 48 86 f7 12 01 02 02 01
00 6e 82 04 9e 30 82 04 9a a0 03 02 01 05 a1 03
02 01 0e a2 07 03 05 00 20 00 00 00 a3 82 03 c2
.... REALLY BIG BLOB ...
bc e3 fc d0 2c 7a 59 a3 c8 2a 35 cc 71 f6 d9 cd
e6 c0 2e bb 7e 37 c9 6e fd 1a bc 14 82 7e fe a0
29 3b a7
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:435 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
In authenticationToken ...
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:452 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
Context created.
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:489 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
Token returned from acceptSecContext:
60 68 06 09 2a 86 48 86 f7 12 01 02 02 02 00 6f
59 30 57 a0 03 02 01 05 a1 03 02 01 0f a2 4b 30
49 a0 03 02 01 03 a2 42 04 40 04 60 a6 63 ef 08
b8 98 b6 69 f6 8a c5 7a 14 af b6 c3 03 1f 92 96
26 84 28 03 5e f8 6d 13 30 1b a4 d3 8d 17 4d 55
23 eb eb 8d c8 2e 56 46 a9 d2 a1 4f ec 10 3c 59
4b e9 34 15 ea 18 6a 40 68 7e
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:489 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
Context establised !
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:490 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
User authenticated: Administrator@SUST.IDM.COM
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:493 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
WindowsDesktopSSO authentication succeeded.
amLoginModule:03/24/2010 04:15:20:493 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
Login NEXT State : -1
amLoginModule:03/24/2010 04:15:20:493 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
amLoginModule:03/24/2010 04:15:20:493 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
SETTING Module name.... :winsso
amAuth:03/24/2010 04:15:20:493 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
Module name is .. winsso
amAuth:03/24/2010 04:15:20:493 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
successModuleSet is : [winsso]
amJAAS:03/24/2010 04:15:20:493 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
login success
amLoginModule:03/24/2010 04:15:20:494 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
AMLoginModule.commit():Succeed,principal=WindowsDesktopSSOPrincipal: Administrator
amLoginModule:03/24/2010 04:15:20:494 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
Done added user to principal
amJAAS:03/24/2010 04:15:20:494 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
commit success

Possible errors while configuring Windows Desktop SSO feature.

************
Problem-1:
************
Type:
-----
ktpass configuration on Windows Domain Controller.

Error:
-------
ktpass command gives error "Failed to retrieve user info if you configure it in two stages"

Solution:
----------
Use the following syntax to do both mapping and keytab generation in one step:

C:\userData\lakshman>ktpass /princ HTTP/avatar.red.iplanet.com@SUST.IDM.COM /pas
s Password123 +DesOnly /crypto DES-CBC-CRC /ptype KRB5_NT_PRINCIPAL /mapuser avata
r /out avatar.HTTP.keytab
Targeting domain controller: parrot.SUST.IDM.COM
Successfully mapped HTTP/avatar.red.iplanet.com to avatar.
Key created.
Output keytab to avatar.HTTP.keytab:
Keytab version: 0x502
keysize 67 HTTP/avatar.red.iplanet.com@SUST.IDM.COM ptype 1 (KRB5_NT_PRINCIPAL)
vno 3 etype 0x1 (DES-CBC-CRC) keylength 8 (0x98628cd615045bc8)
Account avatar has been set for DES-only encryption.

************
Problem-2:
************
Type:
-----
ktpass configuration on Windows Domain Controller.

Error:
-------
Executing ktpass command gives "DnsCrack error"

Solution:
---------
Do not have spaces in user name that you are trying to map. Make sure "Full Name" and Logon name does not have any spaces.

************
Problem-3:
************
Type:
-----
Specifying correct algorithm while running ktpass command.

Solution:
---------
If AM is using Java 1.5_08 or below, must use DesOnly and crypto as DES-CBC-CRC.
To avoid running into this algorith problems, always use DesOnly and DES-CBC-CRC for testing. This is supported on all java versions above and below 1.5_08.

************
Problem-4:
************
Type:
-----
Domain name on AD is not all capital letters like SUST.IDM.COM Instead it is sust.idm.com

Solution:
---------
This is acceptable and will work. Use capital letters as in example below while running ktpass command if domain name is small letters.
C:\userData\lakshman>ktpass /princ HTTP/avatar.red.iplanet.com@SUST.IDM.COM /pas
s Password123 +DesOnly /crypto DES-CBC-CRC /ptype KRB5_NT_PRINCIPAL /mapuser avata
r /out avatar.HTTP.keytab

windows cross-platform authentication + WinSSO auth module on AM/OpenSSO

1. When the logged-on user requests a resource from the Web server, it sends the initial HTTP GET verb.

2. The Web server, running the SPNEGO Token Handler code, requires authentication and issues a 401 Access Denied, WWW-Authenticate: Negotiate response.

3. The client calls AcquireCredentialsHandle()and InitializeSecurityContext() with the SPN to build the Security Context that requests the session ticket from the TGS(KDC).

4. The TGS/KDC supplies the client with the necessary Kerberos Ticket (assuming the client is authorized) wrapped in a SPNEGO Token.

5. The client re-sends the HTTP GET request + the Negotiate SPNEGO Token in an Authorization: Negotiate base64(token) header.

6. The Web server's SPNEGO Token Handler code accepts and processes the token through GSS API, authenticates the user and responds with the requested URL.





Process flow for Windows Desktop SSO module in AM code



1. When the logged-on user (browser client) requests a protected resource from the Web server, it sends the initial HTTP GET verb.

2. The policy agent intercepts the request, sees SSO token in cookie is not present. It redirects it to the web server hosting Sun Access Manager which has WinSSO auth module code (SPNEGO Token Handler code).

3. The Web server, running the SPNEGO Token Handler code (Access Manager Windows desktop SSO auth module), requires authentication to access that resource. So Access Manager code on web server issues a 401 Access Denied, WWW-Authenticate: Negotiate response to the browser client.

4. The browser client calls AcquireCredentialsHandle()and InitializeSecurityContext() with the SPN to build the Security Context. In this process, SPNEGO capable browser requests the session ticket from the Ticket Granting Server (TGS - could be windows domain controller or unix kdc server). This direct interaction between browser and KDC will provide
a) Ticket Granting Ticket (TGT - if not already present)
b) Kerberos or NTLM ticket depending upon configuration. Note AM works only with Kerberos ticket. AM does not support NTLM ticket.
This is wrapped in a SPNEGO token which is presented to AM.

5. The TGS/KDC supplies the client (browser) with the necessary Kerberos Ticket (assuming the client is authorized) wrapped in a SPNEGO Token.

6. The client re-sends the HTTP GET request + the Negotiate SPNEGO Token in an Authorization: Negotiate base64(token) header to Windows Desktop SSO module of Access Manager running on Unix web server.

7. The SPNEGO Token Handler code in Windows Desktop SSO module of Access Manager running on Unix web server accepts and processes the token through GSS API, authenticates the user. After successful authentication, AM prepares SSO Token in a cookie.

8. AM sends back response to browser with HTTP code - 200. Now browser has SSO Token wrapped in a cookie.

9. Browser sends HTTP Get request to web server hosting policy agent so that it can handle the protected resource request.


References:
===========
MSDN Article-1
MSDN Article-2
MSDN Article-3
OpenSSO doc Article-1