Configuring single sign-on for IBM Lotus Connections in the Kerberos environment

In this article, we discuss the configuration of a Kerberos-based single sign-on solution from a Microsoft® Windows® desktop to IBM® Lotus® Connections running on IBM WebSphere® Application Server.

Yang Chao Feng (yangcf@cn.ibm.com), Software Engineer, IBM

Yang Chao Feng works in the IBM China software development lab in Beijing on IBM Lotus Connections. You can reach him at yangcf@cn.ibm.com.



Li Sheng Shuang (lishengs@cn.ibm.com), Software Engineer, IBM

Li Sheng Shuang works in the IBM China software development lab in Beijing on IBM Lotus Connections. You can reach her at lishengs@cn.ibm.com.



Yu Xiao Feng (yuxiaof@cn.ibm.com), Staff Software Engineer, IBM

Yu Xiao Feng is a Staff Software Engineer with rich Web solutions experience, working at the IBM China Software Development Lab in Shanghai. You can reach him at yuxiaof@cn.ibm.com.



02 February 2010

Also available in Russian Portuguese

Editor's note: Know a lot about this topic? Want to share your expertise? Participate in the IBM Lotus software wiki program today.

Introduction

Before we start our discussion of configuring single sing-on in IBM Lotus Connection, we need to review some concepts first: Kerberos and SPNEGO. Kerberos is a computer network authentication protocol, designed and developed by MIT, which allows nodes communicating over a nonsecure network to prove their identity to one another in a secure manner. Kerberos version 5 authentication protocol is an RFC (Request For Comments) standard.

SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) is a GSSAPI pseudo-mechanism that is used to negotiate one of a number of possible real mechanisms. Its most visible use is in Microsoft's HTTP Negotiate authentication extension. The negotiable submechanisms include NTLM (NT LAN Manager) and Kerberos, both used in Microsoft Active Directory. More information can be found here.

Lotus Connections can leverage the WebSphere Application Server SPNEGO TAI (trust association interceptor) to provide the single sign-on (SSO) capability, enabling users to sign on to the Microsoft Windows desktop and then be automatically signed in to Lotus Connections features without having to authenticate.

Figure 1 shows the request/response data flow in the WebSphere Application Server SPNEGO environment.

Figure 1. SPNEGO data flow diagram
SPNEGO data flow diagram

You can read more about the WebSphere Application Server SPNEGO TAI in its Information Center.

In this article, we illustrate how you can enable Lotus Connections to provide the single sign-on (SSO) capability for users based on the deployment shown in figure 2.

Figure 2. Lotus Connections SPNEGO deployment toplogy
Lotus Connections SPNEGO deployment toplogy

Active Directory and Kerberos KDC (key distribution center) are deployed on a Microsoft Windows 2003 Server Enterprise Edition system. The Microsoft Windows client system is the users’ Windows client system with browsers and other applications deployed. Lotus Connections 2.5 server is the Lotus Connections 2.5 environment using Active Directory as the LDAP directory; Lotus Connections 2.5 server can be a multiple-nodes cluster or one single-node environment. In this article, we deploy Lotus Connections 2.5 server on the Microsoft Windows system.


Prerequisite tasks on Active Directory and Kerberos KDC host

There are several prerequisite tasks to be finished by the system administrators on the Active Directory and Kerberos KDC host before we can proceed.

Install Active Directory on Microsoft Windows 2003

Refer to http://technet.microsoft.com/en-us/library/aa998088.aspx on How to install Active Directory on Windows 2003 Server Enterprise Edition. After you have successfully installed Active Directory, make sure that the Kerberos key distribution center system services is configured correctly in the Services list. Double-click the Kerberos Key Distribution Center service to select the Kerberos Key Distribution Center properties as shown in figure 3. Make sure that the Startup type field is selected as Automatic (Automatic is selected by default).

Figure 3. Kerberos Key Distribution Center properties
Kerberos Key Distribution Center properties

The KDC service enables users to log on to the network using the Kerberos V5 authentication protocol. If this service is stopped, users are unable to log on to the domain and access services. On a non-KDC-enabled system (not a domain controller), the KDC service startup type is disabled.

You can read more about the Microsoft Windows KDC service.

You can learn how to modify the Kerberos protocol registry entries and KDC configuration keys in Microsoft Windows Server 2003. We use the default values in this configuration.

Make sure that you install a DNS server on this Windows 2003 system as detailed in step 9 of this process. On the DNS Registration Diagnostics page, follow these steps:

  1. Click Install and configure the DNS server on this computer.
  2. Set this computer to use this DNS server as its preferred DNS server.
  3. Click Next.
  4. The DNS service runs on this Microsoft Windows 2003 Server. Double-click the DNS Server service to select the DNS Server properties as shown in figure 4. Make sure that the Startup type field is selected as Automatic (Automatic is selected by default).
Figure 4. DNS Server Properties window
DNS Server Properties window

Time synchronization for the Kerberos environment

The Microsoft Windows Server 2003 hosting Active Directory is used as the domain controller.

If time synchronization is not a problem in your enterprise intranet, you can ignore this section.

Kerberos requires that the clocks of the involved hosts are synchronized. The tickets have a time availability period, and if the host clock is not synchronized with the Kerberos server clock, the authentication fails.

We often use the domain controller as the time server and run the Windows Schedule task on the involved Lotus Connections server hosts to do time synchronization with the domain controller. Figure 5 shows an example task that invokes the sample TimeSyn.bat every minute.

Figure 5. Windows Scheduled Tasks for time synchronization
\Windows Scheduled Tasks for time synchronization

In our example, users need to create a batch file named TimeSyn.bat in C:\. If example.yourdomain.com is the domain controller and an NTP time server, the TimeSyn.bat looks like the code shown in listing 1.

Listing 1. Sample code for TimeSyn.bat
w32tm /config /manualpeerlist:acme.yourdomain.com.com,0x8 /syncfromflags:MANUAL
net stop w32time
net start w32time
w32tm /resync

Install Microsoft Windows support tools

Install Microsoft Windows support tools on the Windows 2003 Server Enterprise Edition.

You need this tool to run the ktpass command on the domain controller to set SPN for the service account and to generate the keytab file.

You can get details about how the Kerberos protocol works in Microsoft Windows Server 2003.

Configure the Lotus Connections server to support the Kerberos environment. When the prerequisite tasks have been finished we can start the configuration on the Lotus Connections server.


Configure Lotus Connections to use Active Directory as a user repository

Refer to the Lotus Connections Information Center to learn how to configure the security to use Active Directory as a user repository and how to populate the Profiles database.

Create a service account to hold SPN in Active Directory

An SPN (service principal name) is needed for Lotus Connections in the Kerberos environment to identify the Lotus Connections server. A service account is needed in Active Directory to hold that SPN.

To create the service account, log in to the domain controller, go to Manage Your Server - Domain Controller (Active Directory) - Manage users and computers in Active Directory, and click the button.

On the Account page, make sure that you select the User cannot change password and Password never expires options as shown in figure 6.

Figure 6. New user account properties
New user account properties

Set SPN and generate the keytab file

Run the ktpass command on the domain controller to set SPN for the service account and generate the keytab file:

ktpass –princ <SPN> -out <path_to_keytab> -mapuser <account_name>
-mapOp set –pass <account_password>

where
<SPN> is the Kerberos service principal name.

A Kerberos principal is divided into three parts: the primary, the instance, and the realm. The format of a typical Kerberos principal is primary/instance@REALM. If Lotus Connections is hosted on the system SVTLCSPNEGO.cn.example.com and the domain name is CN.EXAMPLE.COM, the SPN is HTTP/SVTLCSPNEGO.cn.example.com@CN.EXAMPLE.COM.

  • <path_to_keytab> is the location where you want to save the keytab file.
  • <account_name> is the service account name.
  • <account_password> is the password to the service account name.

Assume that the user account created in step 1 is lcserver01 and that the password to the service account is Password1. You want to save the keytab file as C:\SVTLCSPNEGO.keytab, so the command looks like the following code:

ktpass -princ HTTP/SVTLCSPNEGO.cn.ibm.com@CN.IBM.COM -out
c:\SVTLCSPNEGO.keytab -mapuser lcserver01 -mapOp set -pass Passw0rd1

The command output is shown in listing 2.

Listing 2. ktpass command output
Targeting domain controller: SVTLCSPNEGO.cn.ibm.com
Using legacy password setting method
Successfully mapped HTTP/SVTLCSPNEGO.cn.ibm.com to lcserver01.
WARNING: pType and account type do not match. This might cause  problems.
Key created.
Output keytab to c:\SVTLCSPNEGO.keytab:
Keytab version: 0x502
keysize 68 HTTP/SVTLCSPNEGO.cn.ibm.com@CN.IBM.COM ptype 0 (KRB5_NT_UNKNOWN) vno 4 ety
pe 0x17 (RC4-HMAC) keylength 16 (0x5858d47a41e40b40f294b3100bea611f)

In a Lotus Connections cluster, you only need to select the IBM HTTP server name or the virtual host name (users access the IBM HTTP server or the virtual host to experience Lotus Connections features) as the instance name in the Kerberos service principal name. It is unnecessary to generate the keytab file for all nodes in the Lotus Connections cluster.

Configure SPNEGO TAI in WebSphere Application Server

Configure SPNEGO TAI in the WebSphere Application Server administrative console by taking these steps:

  1. Navigate to Security - Secure administration, applications, and infrastructure, and expand Web Security. Click Trust association.
  2. Select the Enable trust association option to enable TAI.
  3. Select Interceptors - com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl - Custom properties.
  4. Add the custom properties shown in listing 3.
    Listing 3. Custom properties for SPNEGO TAI
    com.ibm.ws.security.spnego.SPN1.hostName=< hostname>
    com.ibm.ws.security.spnego.SPN1.NTLMTokenReceivedPage=<TAIRedirectPage_location>
    com.ibm.ws.security.spnego.SPN1.spnegoNotSupportedPage=<TAIRedirectPage_Location>
    com.ibm.ws.security.spnego.SPN1.filter=request-url!=/seedlist/authverify;request-url!=/seedlist/
    server;request-url!=/seedlist/myserver;request-url!=noSPNEGO
    com.ibm.ws.security.spnego.SPN1.filterClass=com.ibm.ws.security.spnego.HTTPHeaderFilter

where

  • <hostname> is the name of the server with which Lotus Connections is accessed (for example, the IBM HTTP server name or the virtual host name).
  • <TAIRedirectPage_Location> is where the SPNEGO TAI redirect page is created on the local file system, for instance file:///Z:/share/TAIRedirect.html.

You need to create that HTML file manually. The content is the code shown in listing 4.

Listing 4. SPNEGO TAI redirect page TAIRedirect.html
<!DOCTYPE HTML PUBLIC "-//W3C/DTD HTML 4.0 Transitional//EN">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html">
<!--
Notes:
	- This file should be served from an unprotected web site. Alternatively, it can 
	be loaded from the WebSphere Application Server filesystem.
	- Any imbedded graphics/javascript/css MUST BE loaded from an unprotected web site.
	- This file will be loaded once when the WebSphere Application Server is initialized. 
	If changes to this file are necessary, the Application Server should be restarted.
	- This file will be returned whenever the SPNEGO TAI receives an NTLM token for 
	ANY application in the cell. In other words, this file is generic for all applications. 
	However, by using the Javascipt document.location, we can get the original URL, 
	and redirect to that original URL with the "?noSPNEGO" text added - thus forcing 
	the standard application userid/password challenge.
-->
<html>
<script language="javascript">
	var origUrl=""+document.location;
   	if (origUrl.indexOf("noSPNEGO")<0) {
		if (origUrl.indexOf('?')>=0) origUrl+="&noSPNEGO";
			else origUrl+="?noSPNEGO";
	}
	function redirTimer() {
		self.setTimeout("self.location.href=origUrl;",0);
	}
</script>

<META HTTP-EQUIV = "Pragma" CONTENT="no-cache">
<script language="javascript">
	document.write("<title> Redirect to "+origUrl+ " </title>");	
</script>
<head>
</head>
<body onLoad="redirTimer()"/>
</html>
  1. Click OK to save the changes.

Figure 7 is a screen capture of what dispays in a real deployment.

Figure 7. WebSphere administrative console screen capture for SPNEGO TAI custom properties
WebSphere Admin Console Snapshot for SPNEGO TAI Custom properties

Listing 5 is the sample JACL code that can fulfill the WebSphere SPNEGO TAI setup from the wsadmin interface. Name the file as ConfigTA.jacl and run it like this:

wsadmin -f ConfigTA.jacl

Remember to replace the com.ibm.ws.security.spnego.SPN1.hostName value with your real configuration variable.

Listing 5. ConfigTA.jacl for WebSphere SPNEGO TAI setup
###################################################
proc saveConfig {} {
	global AdminConfig
	$AdminConfig save
}
proc configTA {} {
	global AdminConfig
	
	set trustAssocConfigId [$AdminConfig list TrustAssociation]
	set trust_attrib {}
	
	set matchFound 0
	set	trust_assocEnabled y
	set	trust_interceptorClassName com.ibm.ws.security.spnego.
	TrustAssociationInterceptorImpl
	
        if {$trust_assocEnabled != {}} {
		if {[regexp $trust_assocEnabled y]} {
			lappend trust_attrib [list enabled "true"]
		} else {
			lappend trust_attrib [list enabled "false"]
		}
		$AdminConfig modify $trustAssocConfigId $trust_attrib 
	}
	if {$trust_interceptorClassName != {}} {
		set listOfTAI [$AdminConfig list TAInterceptor]
		foreach tai $listOfTAI {
			set className [$AdminConfig showAttribute $tai interceptorClassName]
			if {[string compare $className $trust_interceptorClassName] == 0} {
				set matchFound 1
				###
				break
			}
		}
	}
	if {$matchFound == 1} {			
		set interceptorConfigId $tai		
		###################################################
		set trust_propertyName com.ibm.ws.security.spnego.SPN1.hostName
		#replace with your IHS host
		set trust_propertyValue < !! please replace with your IHS host !!>
		set trust_propertyRequired false
		set options_attrib {}		
		lappend options_attrib [list name $trust_propertyName]
		lappend options_attrib [list value $trust_propertyValue]
		lappend options_attrib [list required $trust_propertyRequired]	
			
		$AdminConfig modify $interceptorConfigId [list 
		[list trustProperties [list $options_attrib]]]
		set trustAttrs [$AdminConfig showall $interceptorConfigId]
		puts stdout "trustAttrs=$trustAttrs"
		###################################################
		set trust_propertyName com.ibm.ws.security.spnego.SPN1.filterClass		
		set trust_propertyValue com.ibm.ws.security.spnego.HTTPHeaderFilter
		set trust_propertyRequired false
		set options_attrib {}
		
		lappend options_attrib [list name $trust_propertyName]
		lappend options_attrib [list value $trust_propertyValue]
		lappend options_attrib [list required $trust_propertyRequired]	
			
		$AdminConfig modify $interceptorConfigId [list [list trustProperties
		[list $options_attrib]]]
		set trustAttrs [$AdminConfig showall $interceptorConfigId]
		puts stdout "trustAttrs=$trustAttrs"
		###################################################
		set trust_propertyName com.ibm.ws.security.spnego.SPN1.filter
		set trust_propertyValue "request-url!=/seedlist/authverify;request-url!=
		/seedlist/server;request-url!=/seedlist/myserver;request-url!=noSPNEGO"
		set trust_propertyRequired false
		set options_attrib {}
		
		lappend options_attrib [list name $trust_propertyName]
		lappend options_attrib [list value $trust_propertyValue]
		lappend options_attrib [list required $trust_propertyRequired]		
			
		$AdminConfig modify $interceptorConfigId [list [list trustProperties 
		[list $options_attrib]]]
		set trustAttrs [$AdminConfig showall $interceptorConfigId]
		puts stdout "trustAttrs=$trustAttrs"
		###################################################
		set trust_propertyName com.ibm.ws.security.spnego.
		SPN1.spnegoNotSupportedPage
		set trust_propertyValue file:///z:/TAIRedirect.html
		set trust_propertyRequired false
		set options_attrib {}
		
		lappend options_attrib [list name $trust_propertyName]
		lappend options_attrib [list value $trust_propertyValue]
		lappend options_attrib [list required $trust_propertyRequired]	
			
		$AdminConfig modify $interceptorConfigId [list [list trustProperties 
		[list $options_attrib]]]
		set trustAttrs [$AdminConfig showall $interceptorConfigId]
		puts stdout "trustAttrs=$trustAttrs"
		###################################################
		set trust_propertyName com.ibm.ws.security.spnego.
		SPN1.NTLMTokenReceivedPage
		set trust_propertyValue file:///z:/TAIRedirect.html
		set trust_propertyRequired false
		set options_attrib {}
	 
		lappend options_attrib [list name $trust_propertyName]
		lappend options_attrib [list value $trust_propertyValue]
		lappend options_attrib [list required $trust_propertyRequired]	
			
		$AdminConfig modify $interceptorConfigId [list [list trustProperties 
		[list $options_attrib]]]
		set trustAttrs [$AdminConfig showall $interceptorConfigId]
		puts stdout "trustAttrs=$trustAttrs"
		###################################################
		
	}	     
	
}
#############################################################
#  Main procedure
#############################################################
puts stdout "Run like this: wsadmin -f ConfigTA.jacl"

puts ">configTA"
configTA
saveConfig

Create the Kerberos configuration file

Before using SPNEGO TAI in WebSphere Application Server, you need to create the Kerberos configuration file. First, copy the keytab file to the server where Lotus Connections is installed. Then run the createKrbConfigFile script with the wsadmin command line utility, by issuing the command shown in listing 6.

Listing 6. wsadmin command to create the Kerberos configuration file
$AdminTask createKrbConfigFile 
    {    
         -krbPath <appserver>\java\jre\lib\security\krb5.conf 
         -realm <REALM> 
         -kdcHost <kdc_hostname> 
         -dns <dns_hostname> 
         -keytabPath <path_to_keytab>
    }

where

  • <appserver> is the path to the WebSphere Application Server location, not the Lotus Connections location.
  • <REALM> is the Kerberos realm and must be shown in all uppercase letters.
  • <kdc_hostname> is the name of the key distribution center host.
  • <dns_hostname> is the DNS server name.
  • <path_to_keytab> is the location of the keytab file generated on the domain controller.

Enable the WebSphere SPNEGO TAI

To enable SPNEGO TAI, log in to the WebSphere Application Server administrative console, and navigate to Servers - Application servers. Select the server name (typically server1), expand Java and Process Management, and select Process Definition - Java Virtual Machine - Custom Properties.

Add two custom properties:

com.ibm.ws.security.spnego.isEnabled = true
java.security.krb5.conf =<path_to_krb5.conf>

If you install Lotus Connections in multiple server instances, you need to repeat this step for all server instances.

Listing 7 is the sample Jython code that can fulfill the task from the wsadmin interface. Name the file as configspnegojvm.py and run it like this:

wsadmin -lang jython -user wasadmin -password wasadmin -f configspnegojvm.py
Your_Cell_Name Your_Node_Name Your_ServerInstance_Name.

Listing 7. configspnegojvm.py for enabling JVM SPNEGO custom properties
def configspnegojvm(cellName, nodeName, serverName):
   global AdminConfig
   
   krb5conf = "C:/IBM/WebSphere/AppServer/java/jre/lib/security/krb5.conf"   
   javasrv = AdminConfig.getid("/Cell:" + cellName + "/Node:" + nodeName + 
   "/Server:" + serverName + "/")
   
   # Checking for existence of server
   print "Checking for existence of server " + serverName
   if len(javasrv) == 0:
      print "Error -- server not found for name " + serverName + " :: /Cell:" + 
      cellName + "/Node:" + nodeName + "/Server:" + serverName + "/"
      return
   else:
      print "OK. " + javasrv
         
   #======================add JVM Custom Properties=====================
   javaproc = AdminConfig.list('JavaProcessDef', javasrv)
   prop = AdminConfig.list('Property', javaproc)
   jvmp = AdminConfig.list('JavaVirtualMachine', javaproc)
   
   if (prop.find("com.ibm.ws.security.spnego.isEnabled") >= 0):
   		print "INFO: JVM properties seem already exist:"
   		print prop
   		return
   
  
   AdminConfig.create('Property', jvmp, [['name', 'com.ibm.ws.security.
   spnego.isEnabled'], ['value', 'true'], ['required', 'false']])
   AdminConfig.create('Property', jvmp, [['name', 'java.security.krb5.conf'], 
   ['value', krb5conf], ['required', 'false']])      
   AdminConfig.save()
   print "==========Current JVM Custom Properties=========="
   prop = AdminConfig.list('Property', jvmp)
   print prop
   

#Main:
#./wsadmin -lang jython -user wasadmin -password wasadmin -f configspnegojvm.py 
Your_Cell_Name Your_Node_Name Your_ServerInstance_Name

if (len(sys.argv) != 3):
   print "This script requires 3 parameters"
   print "e.g.:./wsadmin -lang jython -user wasadmin -password wasadmin -f 
   configspnegojvm.py Your_Cell_Name Your_Node_Name Your_ServerInstance_Name" 
else:
   cellName = sys.argv[0]
   nodeName = sys.argv[1]
   serverName = sys.argv[2]

   print "cellName: " + cellName
   print "nodeName: " + nodeName
   print "serverName: " + serverName
   print
   configspnegojvm(cellName, nodeName, serverName)

Configure the Ajax proxy for the LtpaToken cookie

Add the following part into the proxy-config.tpl file to configure the Ajax proxy to proxy LtpaToken cookies. You can do this task with the wsadmin utility to extract the configuration files first, add the following content, and check in the configuration. You need to restart the server instances to pick up the changes. See listing 8.

Listing 8. proxy-config.tpl settings for Ajax proxy LtpaToken cookie
<proxy:cookies>
    <proxy:cookie>JSESSIONID</proxy:cookie>
    <proxy:cookie>LtpaToken</proxy:cookie>
    <proxy:cookie>LtpaToken2</proxy:cookie>
</proxy:cookies>

Configure HTTP rewrite rules to log out to an unprotected URI

Set URL rewrite rules in the IBM HTTP Server configuration file named httpd.conf to log out to an unprotected Web page, so that SPNEGO authentication doesn't happen again to log in the user automatically. Follow these steps:

  1. Open the httpd.conf file on the IBM HTTP Server, and uncomment the following lines (remove the #):
    #LoadModule rewrite_module modules/mod_rewrite.so
  2. Then add the code shown in listing 9.
Listing 9. HTTP rewrite rules
RewriteEngine On
RewriteCond %{REQUEST_URI} /(.*)/ibm_security_logout(.*)
RewriteCond %{QUERY_STRING}  !=logoutExitPage=<your-logout-url>
RewriteRule /(.*)/ibm_security_logout(.*)
    /$1/ibm_security_logout?logoutExitPage=<your-logout-url>
   [noescape,L,R]

where

<your-logout-url> is the unprotected URL to which the user is redirected after logout. It is an unprotected URL to prevent SPNEGO authentication.

Be sure to configure the URL rewrite rule for both HTTP and HTTPS.


Configuring the client browser to use SPNEGO

Users need to configure their clients before they can use the Lotus Connections services in the Kerberos environment.

User client system to join the domain

First, the user client system joins the domain. The client system's DNS server value is set as the domain controller address in the TCP/IP Properties window as shown in figure 8.

Figure 8. TCP/IP Properties on the client system
TCP/IP Settings on the user client

Next, follow the link http://support.microsoft.com/kb/295017 to join the domain. . After the client successfully joins the domain, the administrator of the domain controller can see the newly joined member in the Active Directory Users and Computers view as shown in figure 9.

Figure 9. Computers list belongs to the specific domain
Computers list belongs to the specific domain

User client browser configuration

Second, users need to configure their client browsers to use SPNEGO.

If you are using Microsoft Internet Explorer, follow these steps:

  1. In the Internet Explorer window, select Tools - Internet Options - Security.
  2. Select the Local intranet icon, and click Sites.
  3. In the window that displays, click Advanced. In the Add this Web site to the zone field, enter the Web address of the host name so that single sign-on (SSO) can be enabled to the list of Web sites shown in the Web sites field.
  4. Click Close, and then click OK to complete this step and close the Local intranet window.

    Figure 10. Local intranet settings
    Local intranet settings
  5. In the section of the widow titled Security level for this zone, click Custom Level. In the Security Settings window that displays, scroll to User Authentication - Logon and select the Automatic logon only in Intranet zone option. Click OK to close the Security Settings window. See figure 11.

    Figure 11. Security settings for the local intranet zone
    Security settings for the local intranet zone
  6. In the Internet Options window, click the Advanced tab and scroll to Security settings. Make sure that the Enable Integrated Windows Authentication (requires restart) option is selected. See figure 12.

    Figure 12. Internet Options setting
    Internet Options setting
  7. Click OK. Restart your Internet Explorer browser to activate this configuration.

If you are using the Mozilla Firefox browser, follow these steps:

  1. Open Firefox.
  2. In the address field, enter  about:config.
  3. In the Filter field, enter  network.n.
  4. Double click .negotiate-auth.trusted-uris. This preference lists the sites that are permitted to engage in SPNEGO authentication with the browser. Enter a comma-delimited list of trusted domains or URLs.

    NOTE: You must set the value for network.negotiate-auth.trusted-uris as shown in figure 13.

    Figure 13. Mozilla Firefox browser setting
    Mozilla Firefox Browser setting
  5. If the deployed SPNEGO solution uses the advanced Kerberos feature of credential delegation, double-click network.negotiate-auth.delegation-uris. This preference lists the sites for which the browser can delegate user authorization to the server. Enter a comma-delimited list of trusted domains or URLs.
  6. Click OK. The configuration displays as updated.
  7. Restart your Firefox browser to activate this configuration.

Access Lotus Connections with the single sign-on capability in the Kerberos environment

After all tasks in the preceding steps are finished, users can start to experience Lotus Connections with single sign-on. They need to log on to their systems, and they will not be challenged when using Lotus Connections features. Figure 14 is a screen capture taken from an actual deployment. User Aamir_000_000 logs on to his Windows client (which has joined the domain controlled by the domain controller), opens the Firefox browser, enters the Lotus Connections home page address, and logs on to Lotus Connections automatically.

Figure 14. Automatically loaded Lotus Connections home page
Automatically loaded Lotus Connections home page

Troubleshooting

If you have any problems when using Lotus Connections in the SPNEGO environment, you can enable tracing on SPENGO and Kerberos using these settings:

JVM custom property setting

com.ibm.security.jgss.debug = all
com.ibm.security.krb5.Krb5Debug = all

Logs and trace setting

com.ibm.ws.security.*=all: com.ibm.ws.security.spnego.*=all


Conclusion

This article introduced the Microsoft Windows single sign-on SPNEGO concept and configurations for Lotus Connections 2.5, providing detailed explanations for each configuration step. The sample code listings, which are useful for automating system administration work, in the article have been verified by the system test team.

The configuration steps can also be applied to other Web applications.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into IBM collaboration and social software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Lotus
ArticleID=466132
ArticleTitle=Configuring single sign-on for IBM Lotus Connections in the Kerberos environment
publish-date=02022010