Thursday, April 8, 2010

Steps to configure a CDSSO sample in OpenSSO

Deployment example:
------------------
OpenSSO updat1 patch 3 server on machine avatar.red.iplanet.com
Glassfish 3.0 J2EE Policy Agent on machine rub-s10-6.sfbay.sun.com


Step-1: Install OpenSSO server. Configure agent profile, policies.

Step-2: Install J2EE Policy Agent 3.0

Step-3: In container hosting agent, deploy mini agent sample application from http://developers.sun.com/identity/reference/techart/policyagents/agent-mini-app.zip

Step-4: In container hosting agent, deploy agentapp.war This is not installed by default. It is available in the following location:
/opt/lakshman/installations/agents/j2ee_agents/appserver_v9_agent/etc

Step-5: Configure agent profile for 3 properties mentioned in the link:
http://docs.sun.com/app/docs/doc/820-5816/aeabl?a=view
In my sample, the values are (Agent Profile -> SSO tab):
a) Enabled "Cross Domain SSO" checkbox
b) CDSSO Servlet URL: http://avatar.red.iplanet.com:8080/opensso/cdcservlet
c) CDSSO Domain List: .sun.com

Step-6: Set property "CDSSO Clock Skew" if you have not synchronized time between two machines hosting OpenSSO and agent.

Step-7: Add agent machine domain name to Realm/DNS Aliases

Step-8: Restart both containers hosting OpenSSO and glassfish server.

Trouble shooting tips:
----------------------
1. Do not add /agentapp/sunwCDSSORedirectURI to not-enforced-list. This has been discussed some places in a google search.

*************
Related docs:
*************
CDSSO Config
CDSSO Block Diagram
Mini agent sample deployment

Wednesday, March 24, 2010

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

Friday, March 12, 2010

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

Tuesday, December 22, 2009

Dev. tip to change default auth modules through back door entry

1. Open Sun DS Console or any LDAP browser and connect to backend DS configured for AM Server.

2. Browse to following DN :
ou=default,ou=OrganizationConfig,ou=1.0,ou=iPlanetAMAuthService,ou=services,dc=sfbay,dc=sun,dc=com

3. Edit attribute sunkeyvalue attribute by modifying iplanet-am-auth-allowed-modules from UNIX to LDAP
sunkeyvalue: iplanet-am-auth-allowed-modules=LDAP

4. Restart AM.

Thursday, September 3, 2009

nsRole attribute for AM Identitites

Step-1: Create a new user identity testuser1

Step-2: Create a new role identity testrole1

Step-3: Assign testrole1 to testuser1.
Sun AM uses nsRole attribute of DS to store roles for user identity. If you want to verify this, you can do ldapsearch on DS:
ldapsearch -b "dc=red,dc=iplanet,dc=com" -D "cn=Directory Manager" -w -h jackal.red.iplanet.com -p 7389 -s sub "uid=testuser1" nsRole

Step-4: Delete testrole1, then DS takes care of deleting testrole1 DN in testuser1 - nsRole attribute. This works only if Referential integrity plugin is enabled in DS. You can check if referential integrity is enabled or disabled by using:

dsconf get-server-prop -p 7389 -h jackal.red.iplanet.com -D "cn=Directory Manager" -w /opt/pass.txt | grep ref-integrity-enabled

ref-integrity-enabled : on

where dsconf if a tool obtained from DSEE installation. It is available in the following location:
/opt/SUNWdsee/ds6/bin
/opt is the default location of Sun DSEE installation.

Wednesday, September 2, 2009

command to check if referential integrity plugin is enabled on Sun DS?

dsconf get-server-prop -p 389 -h jackal.red.iplanet.com -D "cn=Directory Manager" -w /opt/pass.txt | grep ref-integrity-enabled

where dsconf if a tool obtained from DSEE installation. It is available in the following location:
/opt/SUNWdsee/ds6/bin
where /opt is the default location.

Wednesday, August 26, 2009

Debug DSEE 6.3 Sun DS on machine restart

------------- Step 1 ---------------

bash-3.00# /opt/SUNWdsee/dscc6/bin/dsccsetup initialize
***
DSCC Application is already registered
***
DSCC Agent is already registered
***
DSCC Registry has already been created
***

------------- Step 2 ---------------

bash-3.00# /opt/SUNWdsee/dscc6/bin/dsccsetup status
***
DSCC Application is registered in Sun Java (TM) Web Console
***
DSCC Agent is registered in Cacao
***
DSCC Registry has been created
Path of DSCC registry is /var/opt/SUNWdsee/dscc6/dcc/ads
Port of DSCC registry is 3998
DSCC registry is not running. You may start it using:
/opt/SUNWdsee/ds6/bin/dsadm start /var/opt/SUNWdsee/dscc6/dcc/ads
***

------------- Step 3 ---------------

bash-3.00# /opt/SUNWdsee/ds6/bin/dsadm start /var/opt/SUNWdsee/dscc6/dcc/ads
Server started: pid=2510

------------- Step 4 ---------------

bash-3.00# /opt/SUNWdsee/dscc6/bin/dsccsetup status
***
DSCC Application is registered in Sun Java (TM) Web Console
***
DSCC Agent is registered in Cacao
***
DSCC Registry has been created
Path of DSCC registry is /var/opt/SUNWdsee/dscc6/dcc/ads
Port of DSCC registry is 3998
***

------------- Step 5 ---------------

bash-3.00# cacaoadm status
default instance is DISABLED at system startup.
default instance is not running.

bash-3.00# cacaoadm start

------------- Step 6 ---------------

bash-3.00# smcwebserver start
Access Sun Java Web Console at port 6789 (default)

Wednesday, May 6, 2009

cookies in case of session upgrade vs forceauth

In case of Access Manager session upgrade, a new session is created by copying contents of old session and old session is destroyed. So if you observe the content of iPlanetDirectoryProCookie, it changes its value.

In case of Access Manager forceauth, it will be the same session. So, if you observe the content of iPlanetDirectoryProCookie, it does not change its value.

How to test this forceauth behavior?

1. http://host:port/amserver/UI/Login?module=DataStore. Complete successful authentication.

2. http://host:port/amserver/UI/Login?module=LDAP&ForceAuth=true. This will now kick in force auth.

Wednesday, April 15, 2009

Configuring kerberos on Solaris-10 to setup Access Manager

It is a painful task. The document provided by MIT does not help at all.
We need to use Solaris security services admin guide to get this working. Thanks to Kerberos team in Sun.

The kdcmgr utility mentioned in the document is not available on Solaris-10 by default. For simplicity, use same password in all steps to get this thing working.

The step-by-step procedure that I had followed is documented below:
-----------------------------------------------------
bash-3.00# cat krb5.conf
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
dns_lookup_realm = false
dns_lookup_kdc = false
default_keytab_name = /etc/krb5/kadm5.keytab
default_realm = RED.IPLANET.COM
default_tkt_enctypes = des-cbc-md5
default_tgs_enctypes = des-cbc-md5
kdc_timesync = 0
kdc_default_options = 0x40000010
clockskew = 300
check_delegate = 0
ccache_type = 3
kdc_timeout = 60000

[realms]
RED.IPLANET.COM = {
kdc = avatar.red.iplanet.com:88
admin_server = avatar.red.iplanet.com:749
default_domain = red.iplanet.com
}

[domain_realm]
.red.iplanet.com = RED.IPLANET.COM
red.iplanet.com = RED.IPLANET.COM

[appdefaults]
pam = {
debug = true
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}

bash-3.00# cat kdc.conf
#
# Copyright 1998-2002 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
#
#ident "@(#)kdc.conf 1.2 02/02/14 SMI"

[kdcdefaults]
kdc_ports = 88,750

[realms]
RED.IPLANET.COM = {
profile = /etc/krb5/krb5.conf
database_name = /var/krb5/principal
admin_keytab = /etc/krb5/kadm5.keytab
acl_file = /etc/krb5/kadm5.acl
kadmind_port = 749
max_life = 8h 0m 0s
max_renewable_life = 7d 0h 0m 0s
sunw_dbprop_enable = true
sunw_dbprop_master_ulogsize = 1000
}


bash-3.00# cat kadm5.acl
#
# Copyright (c) 1998-2000 by Sun Microsystems, Inc.
# All rights reserved.
#
#pragma ident "@(#)kadm5.acl 1.1 01/03/19 SMI"

*/admin@RED.IPLANET.COM *


bash-3.00# ./kdb5_util create -s
Initializing database '/var/krb5/principal' for realm 'RED.IPLANET.COM',
master key name 'K/M@RED.IPLANET.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:

bash-3.00# ./kadmin.local
Authenticating as principal root/admin@RED.IPLANET.COM with password.

kadmin.local: addprinc kws/admin
WARNING: no policy specified for kws/admin@RED.IPLANET.COM; defaulting to no policy
Enter password for principal "kws/admin@RED.IPLANET.COM":
Re-enter password for principal "kws/admin@RED.IPLANET.COM":
Principal "kws/admin@RED.IPLANET.COM" created.

kadmin.local: addprinc -randkey kiprop/avatar.red.iplanet.com
WARNING: no policy specified for kiprop/avatar.red.iplanet.com@RED.IPLANET.COM; defaulting to no policy
Principal "kiprop/avatar.red.iplanet.com@RED.IPLANET.COM" created.

kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/avatar.red.iplanet.com
Entry for principal kadmin/avatar.red.iplanet.com with kvno 3, encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/avatar.red.iplanet.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/avatar.red.iplanet.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/avatar.red.iplanet.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.

kadmin.local: ktadd -k /etc/krb5/kadm5.keytab changepw/avatar.red.iplanet.com
Entry for principal changepw/avatar.red.iplanet.com with kvno 3, encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/avatar.red.iplanet.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/avatar.red.iplanet.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/avatar.red.iplanet.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.

kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/changepw
Entry for principal kadmin/changepw with kvno 3, encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.

kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kiprop/avatar.red.iplanet.com
Entry for principal kiprop/avatar.red.iplanet.com with kvno 3, encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/avatar.red.iplanet.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/avatar.red.iplanet.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/avatar.red.iplanet.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.

kadmin.local: quit

bash-3.00# svcadm enable -r network/security/krb5kdc
bash-3.00# svcadm enable -r network/security/kadmin

bash-3.00# /usr/sbin/kadmin -p kws/admin
Authenticating as principal kws/admin@RED.IPLANET.COM with password.
kadmin: Incorrect password while initializing kadmin interface
bash-3.00#

bash-3.00# cat /etc/resolv.conf
domain red.iplanet.com
search red.iplanet.com sfbay.sun.com sun.com
nameserver 129.145.155.55
nameserver 129.145.155.170
nameserver 192.18.120.21
nameserver 192.18.120.24
#nameserver 129.148.9.196
#nameserver 129.148.9.197
#nameserver 129.147.9.5
#nameserver 129.145.155.220

avatar# touch /var/log/kadmind.log /var/log/krb5kdc.log
> /var/log/krb5libs.log
> avatar# svcadm restart krb5kdc
> avatar# svcadm restart kadmin
> avatar# kadmin -p kws/admin
> Authenticating as principal kws/admin@RED.IPLANET.COM with password.
> Password for kws/admin@RED.IPLANET.COM:
> kadmin: listprincs
> K/M@RED.IPLANET.COM
> changepw/avatar.red.iplanet.com@RED.IPLANET.COM
> kadmin/admin@RED.IPLANET.COM
> kadmin/avatar.red.iplanet.com@RED.IPLANET.COM
> kadmin/changepw@RED.IPLANET.COM
> kadmin/history@RED.IPLANET.COM
> kiprop/avatar.red.iplanet.com@RED.IPLANET.COM
> krbtgt/RED.IPLANET.COM@RED.IPLANET.COM
> kws/admin@RED.IPLANET.COM
> kadmin:

bash-3.00# ./kadmin -p kws/admin
Authenticating as principal kws/admin@RED.IPLANET.COM with password.
Password for kws/admin@RED.IPLANET.COM:
kadmin: addprinc -randkey host/avatar.red.iplanet.com
WARNING: no policy specified for host/avatar.red.iplanet.com@RED.IPLANET.COM; defaulting to no policy
Principal "host/avatar.red.iplanet.com@RED.IPLANET.COM" created.

kadmin: addprinc clntconfig/admin
WARNING: no policy specified for clntconfig/admin@RED.IPLANET.COM; defaulting to no policy
Enter password for principal "clntconfig/admin@RED.IPLANET.COM":
Re-enter password for principal "clntconfig/admin@RED.IPLANET.COM":
Principal "clntconfig/admin@RED.IPLANET.COM" created.
kadmin: quit

bash-3.00# kadmin -p kws/admin
Authenticating as principal kws/admin@RED.IPLANET.COM with password.
Password for kws/admin@RED.IPLANET.COM:
kadmin: ktadd host/avatar.red.iplanet.com
kadmin: Cannot write to specified key table while adding key to keytab
kadmin: quit

bash-3.00# ./kadmin.local
Authenticating as principal root/admin@RED.IPLANET.COM with password.
kadmin.local: ktadd -k /etc/krb5/kadm5.keytab host/avatar.red.iplanet.com
Entry for principal host/avatar.red.iplanet.com with kvno 4, encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal host/avatar.red.iplanet.com with kvno 4, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal host/avatar.red.iplanet.com with kvno 4, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal host/avatar.red.iplanet.com with kvno 4, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local: quit

bash-3.00# /usr/sbin/kadmin.local
Authenticating as principal root/admin@RED.IPLANET.COM with password.
kadmin.local: listprincs
1 K/M@RED.IPLANET.COM
2 changepw/avatar.red.iplanet.com@RED.IPLANET.COM
3 clntconfig/admin@RED.IPLANET.COM
4 host/avatar.red.iplanet.com@RED.IPLANET.COM
5 kadmin/admin@RED.IPLANET.COM
6 kadmin/avatar.red.iplanet.com@RED.IPLANET.COM
7 kadmin/changepw@RED.IPLANET.COM
8 kadmin/history@RED.IPLANET.COM
9 kiprop/avatar.red.iplanet.com@RED.IPLANET.COM
10 krbtgt/RED.IPLANET.COM@RED.IPLANET.COM
11 kws/admin@RED.IPLANET.COM
kadmin.local: quit

bash-3.00# svcs -a | grep secur
disabled 20:24:27 svc:/network/security/krb5_prop:default
online 20:24:27 svc:/network/security/ktkt_warn:default
online 10:15:30 svc:/network/security/krb5kdc:default
online 10:15:32 svc:/network/security/kadmin:default

************ Configuration on AM ******************
kadmin.local: addprinc root
kinit root
klist

kadmin.local: addprinc -randkey HTTP/avatar.red.iplanet.com
kadmin.local: ktadd -k /opt/SUNWam/avatar.HTTP.keytab HTTP/avatar.red.iplanet.com
kinit -k -t /opt/SUNWam/avatar.HTTP.keytab HTTP/avatar.red.iplanet.com
klist -k /opt/SUNWam/avatar.HTTP.keytab

mv /opt/SUNWam/avatar.HTTP.keytab /etc/opt/SUNWam/config/

Service Principal: HTTP/avatar.red.iplanet.com@RED.IPLANET.COM
Keytab File Name: /etc/opt/SUNWam/config/avatar.HTTP.keytab
Kerberos Realm: RED.IPLANET.COM
Kerberos Server Name: avatar.red.iplanet.com
Return Principal with Domain Name: Disabled
Authentication Level: 0

- Restart AM WebServer

The debug file amAuthWindowsDesktopSSO should show the following debug messages if auth succeeded:
04/18/2009 11:56:39:944 PM PDT: Thread[service-j2ee-3,5,main]
**********************************************
04/18/2009 11:56:39:944 PM PDT: Thread[service-j2ee-3,5,main]
WindowsDesktopSSO params:
principal: HTTP/avatar.red.iplanet.com@RED.IPLANET.COM
keytab file: /etc/opt/SUNWam/config/avatar.HTTP.keytab
realm : RED.IPLANET.COM
kdc server: avatar.red.iplanet.com
domain principal: false
auth level: 0
04/18/2009 11:56:39:944 PM PDT: Thread[service-j2ee-3,5,main]
Init WindowsDesktopSSO. This should not happen often.
04/18/2009 11:56:39:945 PM PDT: Thread[service-j2ee-3,5,main]
New Service Login ...
04/18/2009 11:56:40:586 PM PDT: Thread[service-j2ee-3,5,main]
Service login succeeded.
04/18/2009 11:56:40:704 PM PDT: Thread[service-j2ee-3,5,main]
SPNEGO token:
60 82 02 79 06 06 2b 06 01 05 05 02 a0 82 02 6d
30 82 02 69 a0 0d 30 0b 06 09 2a 86 48 86 f7 12
01 02 02 a1 04 03 02 01 02 a2 82 02 50 04 82 02
4c 60 82 02 48 06 09 2a 86 48 86 f7 12 01 02 02
01 00 6e 82 02 37 30 82 02 33 a0 03 02 01 05 a1
03 02 01 0e a2 07 03 05 00 00 00 00 00 a3 82 01
4b 61 82 01 47 30 82 01 43 a0 03 02 01 05 a1 11
1b 0f 52 45 44 2e 49 50 4c 41 4e 45 54 2e 43 4f
4d a2 29 30 27 a0 03 02 01 03 a1 20 30 1e 1b 04
48 54 54 50 1b 16 61 76 61 74 61 72 2e 72 65 64
2e 69 70 6c 61 6e 65 74 2e 63 6f 6d a3 81 fd 30
81 fa a0 03 02 01 11 a1 03 02 01 05 a2 81 ed 04
81 ea 8e 55 1d 11 a8 8d 23 ed 34 b5 87 f9 97 0c
bb ef ed 30 ee be c7 95 33 77 84 06 97 a5 da 3e
b8 8d 25 a0 0c dd 06 b3 b4 02 ba ea 50 22 37 b8
29 db 00 40 d3 74 f1 f6 80 1f c9 ff 62 ab 5b 02
4a ed be 75 dd 3c d6 cf 63 3a 49 5c d7 24 74 1d
2c 3d 3b 2d 7d 94 9e b2 2d 05 3b 8a e1 94 30 9d
14 42 9f a1 b4 c4 e7 16 ff 9f c7 3e 89 24 db 13
e4 18 fb 8d f5 50 f7 47 59 6e 86 26 a3 3b 33 0c
a3 89 de 54 77 e2 fd 99 ba 16 cb 1b f2 5f 31 f1
c5 dd 6b 5a e2 d4 d6 23 6e e1 32 a8 ab 83 70 be
f6 ef 50 cb fe cd 20 b3 1a 9f 76 fd 55 59 a1 48
40 38 87 8e 17 96 18 8e 46 44 18 e9 af 1c 23 9e
09 d1 6a b3 55 2e 17 38 1b 9c ae 22 83 04 46 7b
92 ed cc d5 df 28 31 1e 15 00 fc 1b 9d 9d a5 64
1b b0 3c c8 79 3a 85 45 dc 7c e6 80 a4 81 ce 30
81 cb a0 03 02 01 03 a2 81 c3 04 81 c0 51 af 58
86 db 73 b8 8b ba 07 cf 8c 40 46 0b b6 46 8c d0
6b 4c ad 3f 2a 0d a6 ec e8 8c 29 f6 3c ac a5 27
ac 34 95 1f cd d3 cf 78 5b b7 40 2a c3 d4 f8 fb
e5 7e d0 f2 d9 41 c3 b6 48 6f fa 8d ee de d0 fc
76 d4 48 55 a2 98 9c 88 07 7a 87 18 37 bb ac 16
89 17 ee 04 95 5f 58 2d 4e 2f ff da b7 12 2c 2a
2a a0 82 ef c6 43 ae 67 f3 e3 31 9a 77 b2 64 51
5f f4 28 84 0c be 8a 08 da 2e df 0b 77 33 c7 6a
1a 70 8f bd 56 10 bc 5a 6c 8d 82 21 8c be d5 88
69 7b 60 81 a1 31 02 60 73 ed a3 bb 5d b1 fc cc
86 2f 33 96 a1 6d bb 4a 10 94 07 ff 62 9f c6 7c
2c e7 66 89 99 ed 74 69 e8 a3 62 01 14
04/18/2009 11:56:40:705 PM PDT: Thread[service-j2ee-3,5,main]
token tag:60
04/18/2009 11:56:40:705 PM PDT: Thread[service-j2ee-3,5,main]
SPNEGO OID found in the Auth Token
04/18/2009 11:56:40:705 PM PDT: Thread[service-j2ee-3,5,main]
DerValue: found init token
04/18/2009 11:56:40:705 PM PDT: Thread[service-j2ee-3,5,main]
DerValue: 0x30 constructed token found
04/18/2009 11:56:40:712 PM PDT: Thread[service-j2ee-3,5,main]
Kerberos token retrieved from SPNEGO token:
60 82 02 48 06 09 2a 86 48 86 f7 12 01 02 02 01
00 6e 82 02 37 30 82 02 33 a0 03 02 01 05 a1 03
02 01 0e a2 07 03 05 00 00 00 00 00 a3 82 01 4b
61 82 01 47 30 82 01 43 a0 03 02 01 05 a1 11 1b
0f 52 45 44 2e 49 50 4c 41 4e 45 54 2e 43 4f 4d
a2 29 30 27 a0 03 02 01 03 a1 20 30 1e 1b 04 48
54 54 50 1b 16 61 76 61 74 61 72 2e 72 65 64 2e
69 70 6c 61 6e 65 74 2e 63 6f 6d a3 81 fd 30 81
fa a0 03 02 01 11 a1 03 02 01 05 a2 81 ed 04 81
ea 8e 55 1d 11 a8 8d 23 ed 34 b5 87 f9 97 0c bb
ef ed 30 ee be c7 95 33 77 84 06 97 a5 da 3e b8
8d 25 a0 0c dd 06 b3 b4 02 ba ea 50 22 37 b8 29
db 00 40 d3 74 f1 f6 80 1f c9 ff 62 ab 5b 02 4a
ed be 75 dd 3c d6 cf 63 3a 49 5c d7 24 74 1d 2c
3d 3b 2d 7d 94 9e b2 2d 05 3b 8a e1 94 30 9d 14
42 9f a1 b4 c4 e7 16 ff 9f c7 3e 89 24 db 13 e4
18 fb 8d f5 50 f7 47 59 6e 86 26 a3 3b 33 0c a3
89 de 54 77 e2 fd 99 ba 16 cb 1b f2 5f 31 f1 c5
dd 6b 5a e2 d4 d6 23 6e e1 32 a8 ab 83 70 be f6
ef 50 cb fe cd 20 b3 1a 9f 76 fd 55 59 a1 48 40
38 87 8e 17 96 18 8e 46 44 18 e9 af 1c 23 9e 09
d1 6a b3 55 2e 17 38 1b 9c ae 22 83 04 46 7b 92
ed cc d5 df 28 31 1e 15 00 fc 1b 9d 9d a5 64 1b
b0 3c c8 79 3a 85 45 dc 7c e6 80 a4 81 ce 30 81
cb a0 03 02 01 03 a2 81 c3 04 81 c0 51 af 58 86
db 73 b8 8b ba 07 cf 8c 40 46 0b b6 46 8c d0 6b
4c ad 3f 2a 0d a6 ec e8 8c 29 f6 3c ac a5 27 ac
34 95 1f cd d3 cf 78 5b b7 40 2a c3 d4 f8 fb e5
7e d0 f2 d9 41 c3 b6 48 6f fa 8d ee de d0 fc 76
d4 48 55 a2 98 9c 88 07 7a 87 18 37 bb ac 16 89
17 ee 04 95 5f 58 2d 4e 2f ff da b7 12 2c 2a 2a
a0 82 ef c6 43 ae 67 f3 e3 31 9a 77 b2 64 51 5f
f4 28 84 0c be 8a 08 da 2e df 0b 77 33 c7 6a 1a
70 8f bd 56 10 bc 5a 6c 8d 82 21 8c be d5 88 69
7b 60 81 a1 31 02 60 73 ed a3 bb 5d b1 fc cc 86
2f 33 96 a1 6d bb 4a 10 94 07 ff 62 9f c6 7c 2c
e7 66 89 99 ed 74 69 e8 a3 62 01 14
04/18/2009 11:56:40:712 PM PDT: Thread[service-j2ee-3,5,main]
In authenticationToken ...
04/18/2009 11:56:40:724 PM PDT: Thread[service-j2ee-3,5,main]
Context created.
04/18/2009 11:56:41:124 PM PDT: Thread[service-j2ee-3,5,main]
Token returned from acceptSecContext:

04/18/2009 11:56:41:124 PM PDT: Thread[service-j2ee-3,5,main]
Context establised !
04/18/2009 11:56:41:125 PM PDT: Thread[service-j2ee-3,5,main]
User authenticated: HTTP/avatar.red.iplanet.com@RED.IPLANET.COM
04/18/2009 11:56:41:127 PM PDT: Thread[service-j2ee-3,5,main]
WindowsDesktopSSO authentication succeeded.

***********************************************************************

bash-3.00# /usr/sbin/kadmin.local
Authenticating as principal HTTP/admin@RED.IPLANET.COM with password.
kadmin.local: listprincs
1 HTTP/avatar.red.iplanet.com@RED.IPLANET.COM
2 K/M@RED.IPLANET.COM
3 changepw/avatar.red.iplanet.com@RED.IPLANET.COM
4 clntconfig/admin@RED.IPLANET.COM
5 demo1@RED.IPLANET.COM
6 demouser1@RED.IPLANET.COM
7 host/avatar.red.iplanet.com@RED.IPLANET.COM
8 kadmin/admin@RED.IPLANET.COM
9 kadmin/avatar.red.iplanet.com@RED.IPLANET.COM
10 kadmin/changepw@RED.IPLANET.COM
11 kadmin/history@RED.IPLANET.COM
12 kiprop/avatar.red.iplanet.com@RED.IPLANET.COM
13 krbtgt/RED.IPLANET.COM@RED.IPLANET.COM
14 kws/admin@RED.IPLANET.COM
15 root@RED.IPLANET.COM
kadmin.local: