In this article, we introduce Microsoft® Windows® single sign-on (SSO) support for IBM® Lotus® Connections 2.5, including configurations and best practices. This feature, new to version 2.5, enables users who already logged on to the Windows desktop to log on to Lotus Connections automatically without re-authenticating.

Introduction

Windows SSO support is a new feature in Lotus Connections 2.5, enabling users who are already logged on to a Windows desktop to log on to Lotus Connections automatically, without needing to re-authenticate.

The SSO is achieved by means of Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO), which is a GSSAPI "pseudo mechanism" used to negotiate one of a number of possible real mechanisms. The negotiable sub-mechanisms include Windows NT LAN Manager (NTLM) and Kerberos, both of which are supported by Microsoft Active Directory.

Windows SSO can be implemented in a variety of ways, including via WebSphere® Application Server SPNEGO Trust Association Interceptor (TAI), Tivoli® Access Manager, or other third-party access managers.

In Lotus Connections 2.5, the Windows SSO support is built on WebSphere Application Server SPNEGO TAI. Figure 1 illustrates how the SPNEGO authentication is performed with WebSphere SPNEGO TAI (excerpted from the developerWorks article titled, “Administering the SPNEGO TAI: Tips on using Kerberos service principal names”).

Figure 1. SPNEGO authentication process

In this article, we build upon the detailed instructions already available in the Lotus Connections 2.5 Information Center, explaining more about the meanings of the configuration parameters and introducing configuration and troubleshooting tips for Windows SSO.

Prerequisites

First, let's discuss what you need to get started.

Setting up Active Directory

Lotus Connections 2.5 only supports Active Directory on Windows Server 2003 for Windows SSO. For details on setting this up, refer to the Microsoft TechNet topic, “How to Install Active Directory on Windows Server 2003.”

NOTE: Since the security of Kerberos authentication is, in part, based on the timestamp in tickets, it is extremely important that the time difference between a client clock and a domain controller clock is not greater than the "Maximum tolerance for computer clock synchronization" value. The default maximum tolerance for clock synchronization is 5 minutes.

You will receive a “Client time too skewed” exception, if the client and server clock times are not in synchronization. For more details on setting up time synchronization on Windows, refer to the Microsoft Support article, “How to synchronize the time with the Windows Time service in Windows XP.”

Tip: In a DNS server configuration, always register your HTTP server and WebSphere Application Server as a DNS Host instead of a DNS Alias. This prevents you from experiencing the situation described in “PK84184: DYNAMIC MAPPING OF ALIAS HOSTNAME TO REAL HOSTNAME FOR SPNEGO SSO.”

Creating a Service Principal Name for Lotus Connections

The Service Principal Name (SPN) is used to identify a service in a Kerberos environment. A Kerberos service principal is divided into three parts: the primary, the instance, and the realm. The format of a typical Kerberos principal is primary/instance@REALM.

For example, if Lotus Connections is hosted on the host fvt195.cn.ibm.com, and the domain name is CN.IBM.COM, then the SPN will be HTTP/fvt195.cn.ibm.com@CN.IBM.COM.

Note that you only need a single SPN to identify the Lotus Connections service, unless Lotus Connections features are served from different IBM HTTP servers or Edge Servers.

To create a SPN, first you need an account in Active Directory in which to hold it. To create an account:

1. On the Domain Controller server, select Start > Manage Your Server > Manage users and computers in Active Directory, to open the user management console.
2. Click the  button on the toolbar and follow the wizard to create a new user.
3. In the left-hand tree, select Users; available users will be shown on the right. Right-click on the user you created and select Properties.
4. In the User Properties dialog box, select the Account tab and enable the options “User cannot change password” and “Password never expires” (see figure 2).

Figure 2. Account tab of User Properties

 

NOTE: Be sure to enable the above options, so you won't need to re-generate the key tab when the password is changed. Also, make sure to use a complex-enough password to protect the account that holds the SPN.

After the Active Directory account is created, you can map the SPN for Lotus Connections to the newly created account using ktpass, which is included in Windows 2003 support tools:

ktpass –princ  -out  -mapuser  -mapOp set –pass 

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

Targeting domain controller: fvt195.cn.ibm.com

Using legacy password setting method

Successfully mapped HTTP/virutal.cn.ibm.com to lcserver01.

WARNING: pType and account type do not match. This might cause problems.

Key created.

Output keytab to c:\VIRTUAL.keytab:

Keytab version: 0x502

keysize 68 HTTP/virtual.cn.ibm.com@CN.IBM.COM ptype 0 (KRB5_NT_UNKNOWN) vno 4 ety

pe 0x17 (RC4-HMAC) keylength 16 (0x5858d47a41e40b40f294b3100bea611f)

If ktpass is not already installed, follow the instructions in the Microsoft Support article, “Windows Server 2003 Service Pack 1 Support Tools.”

You can use the setspn command to verify whether the SPN has been mapped to the account successfully. Setspn is also included in Windows 2003 support tools. The -L option will list all registered SPNs within that account:

setspn -L 

C:\>setspn -L lcserver01

Registered ServicePrincipalNames for CN=lcserver,CN=Users,DC=cn,DC=ibm,DC=com:

HTTP/virutal.cn.ibm.com

Verifying mandatory iFixes

There are two mandatory WebSphere Application Server iFixes, PK77456 and PK76656. You must apply these iFixes before you configure Windows SSO, to avoid potential issues. You can download the iFixes from the IBM WebSphere Portal Support site. Refer to these IBM Support Technotes for more detailed information:

• Access denied when access Blogs front page with Windows Single Sign-on

• 404 File Not Found error when Windows Single Sign-on is configured

Installing Lotus Connections

For Windows SSO, it is recommended that Lotus Connections uses Active Directory as its user repository. You can use other directory services; however, if you do, you must write your own custom log-in module to map the received User Principal Name (UPN) to user IDs in the WebSphere federated user repository.

If you are installing the Profiles feature, you also need to populate the Profiles database with user information in Active Directory before installing Connections. You can do this manually or with the Profiles population wizard.

NOTE: You should map only the sAMAccountName user attribute in Active Directory to the UID field of the Profiles database. This mapping is provided by default in the bundled TDI scripts.

Figure 3 shows the mapping in the Profiles population wizard. If you are considering changing the mapping to the UID field, you should also consider introducing your own custom log-in module for the mapping from the UPN to the new attribute.

Figure 3. Mapping in the Profile population wizard

  

The remaining installation tasks are the same as installing Connections with no Windows SSO support (refer to the Lotus Connections 2.5 Information Center to complete the installation).

Tip: Make sure Lotus Connections is working properly before beginning to configure Windows SSO, to help you focus on the issues that occur only in the Windows SSO environment.

Configuring Windows SSO

Enabling WebSphere for Kerberos

For the SPNEGO TAI to work, you must first enable WebSphere Application Server [in fact, the Java Virtual Machine (JVM) on which WebSphere runs] for Kerberos by creating a Kerberos configuration file.

WebSphere Application Server provides a utility for creating the Kerberos configuration file creation that you can run with the wsadmin utility:

$AdminTask createKrbConfigFile 

{

-krbPath \java\jre\lib\security\krb5.conf

-realm

-kdcHost

-dns

-keytabPath

}

The krbPath parameter specifies the location of the generated Kerberos configuration file. It is recommended that the configuration file be created to its default place, java/jre/lib/security/krb5.conf, so that the JVM finds the configuration file without the explicit file location in the java.security.krb5.conf JVM custom property.

After the Kerberos configuration file is generated, your JVM is already a configured Kerberos client. You can verify your Kerberos configurations for the WebSphere Application Server JVM, using these Kerberos commands:

kinit 

: Used to obtain and cache Kerberos ticket-granting tickets:

C:\LSCONN\WebSphere\AppServer\java\jre\bin>kinit administrator

Password for administrator@CN.IBM.COM:

we1comeu

Done!

New ticket is stored in cache file C:\Documents and Settings\Administrator.FVT19

5\krb5cc_administrator

klist: Lists the entries in the local credentials cache

klist -k: Lists the entries in the default keytab specified in krb5.conf.

C:\LSCONN\WebSphere\AppServer\java\jre\bin>klist

Credentials cache: C:\Documents and Settings\Administrator.FVT195\krb5cc_adminis

trator

Default principal: administrator@CN.IBM.COM

Number of entries: 1

[1] Service principal: krbtgt/CN.IBM.COM@CN.IBM.COM

Valid starting: Monday, November 2, 2009 at 3:15:40 PM

Expires: Tuesday, November 3, 2009 at 1:15:40 AM

C:\LSCONN\WebSphere\AppServer\java\jre\bin>klist -k

Key table: C:\temp\virtual.keytab

Number of entries: 1

[1] principal: HTTP/virtual.cn.ibm.com@CN.IBM.COM

KVNO: 3

Setting up SPNEGO TAI

When WebSphere Application Server is successfully configured for Kerberos, it's time to configure the SPNEGO TAI. By default, TAIs are disabled, but you can enable them in the WebSphere administrative console, as follows:

1. Navigate to Security > Secure administration, applications, and infrastructure.
2. Expand Web Security, click Trust association, and place a check the Enable trust association check box.
3. You also need to add custom properties to com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl as described in Information Center topic, “Enabling a trust association interceptor for SPNEGO” (see table 1).

Table 1. SPNEGO TAI custom properties

Name	Value
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

In this table, hostname specifies the Lotus Connections hostname that is used in the SPN; and NTLMTokenReceivedPage and spnegoNotSupportedPage specify the page to return when the SPNEGO TAI receives NTLMToken, or the TAI determines the browser is not configured to support SPNEGO.

NOTE: The NTLMTokenReceivedPage and spnegoNotSupportedPage parameters are configured to switch the user to form-based authentication, if the browser is not configured for SPNEGO or the client machine has not joined an Active Directory domain.

If you want to disable form-based authentication, you may leave these two parameters blank. If you specify locations for these two parameters, make sure the locations exist and are accessible to WebSphere Application Server; otherwise, WebSphere will fail to load the SPNEGO TAI.

To finish enabling the SPNEGO TAI, we must set two more JVM custom properties. We need to set the JVM custom property for each WebSphere Application Server instance in your Lotus Connections deployment. The two custom properties are:

com.ibm.ws.security.spnego.isEnabled = true

java.security.krb5.conf =<path_to_krb5.conf>

Tip: If you generated the Kerberos configuration file in its default location, you don't even need to specify the java.security.krb5.conf custom property. You may, however, want to mark the location of configuration file explicitly.

Ajax Proxy settings

To make the Ajax Proxy work in the Windows SSO environment, we need to instruct the Ajax Proxy to proxy the correct cookies, that is, JSESSIONID, LtpaToken, and LtpaToken2. You can find the elements in the proxy-config.tpl file; make sure the following three lines are present:

<proxy:cookies>

<proxy:cookie>JSESSIONID</proxy:cookie>

<proxy:cookie>LtpaToken</proxy:cookie>

<proxy:cookie>LtpaToken2</proxy:cookie>

</proxy:cookies>

Log out configurations

Lotus Connections is a Web application and is not able to log out the user from the Windows desktop. There are, however, ways to log out from Lotus Connections and clean up private session information in the browser. Specifically, this is done via the following HTTP rewrite rules on IBM HTTP Server:

RewriteEngine On

RewriteCond %{REQUEST_URI} /(.*)/ibm_security_logout(.*)

RewriteCond %{QUERY_STRING} !=logoutExitPage=

RewriteRule /(.*)/ibm_security_logout(.*) /$1/ibm_security_logout?logoutExitPage= [noescape,L,R

The rewrite rules capture the log-out request to ibm_security_logout and set the log-out exit page as an unprotected URL, so that after WebSphere Application Server logs out the user, the user is redirected to that unprotected URL. In this way, the user logs out of Lotus Connections completely.

Note that the <your-logout-url> MUST be an unprotected URL so that the user will not be logged into Connections automatically again by Windows SSO.

Setting up the client

Besides configuring servers, we also must properly configure client machines to complete the Windows SSO setup. Specifically, we need to add the client machine to the Active Directory domain and configure the browser.

Join the Active Directory domain

The client machine must be joined in an Active Directory domain; otherwise, the logged-in user on that client will not be able to get the Kerberos Ticket Granting Ticket (TGT) for further communication. Refer to the Microsoft Support article, “How to change a computer name, join a domain, and add a computer description in Windows XP or in Windows Server 2003,” for more information.

You can use the klist utility that is included in the Windows Server 2003 Resource Kit Tools to verify whether a TGT was successfully obtained and to get its expiration time. Note that you should run this utility from the correct path on the client machine and that the JVM also provides the klist utility.

klist tgt:

Returns the cached ticket granting ticket

klist

tickets: Returns the cached tickets (short-term tickets)

C:\Program Files\Windows Resource Kits\Tools>klist tgt

Cached TGT:

ServiceName: krbtgt

TargetName: krbtgt

FullServiceName: Administrator

DomainName: CN.IBM.COM

TargetDomainName: CN.IBM.COM

AltTargetDomainName: CN.IBM.COM

TicketFlags: 0x40e00000

KeyExpirationTime: 1/1/1601 8:00:00

StartTime: 11/2/2009 16:11:03

EndTime: 11/3/2009 2:11:03

RenewUntil: 11/9/2009 16:11:03

TimeSkew: 1/1/1601 8:00:00

C:\Program Files\Windows Resource Kits\Tools>klist tickets

Cached Tickets: (2)

Server: krbtgt/CN.IBM.COM@CN.IBM.COM

KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)

End Time: 11/3/2009 2:11:03

Renew Time: 11/9/2009 16:11:03

Server: host/fvt195.cn.ibm.com@CN.IBM.COM

KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)

End Time: 11/3/2009 2:11:03

Renew Time: 11/9/2009 16:11:03

Browser configurations

Although the configuration instructions below in the Lotus Connections Information Center are quite straightforward, here we enhance the steps with figures 4 and 5 bellow for Microsoft Internet Explorer and Mozilla Firefox, respectively, to enhance your understanding.

To configure Internet Explorer:

1. From the Internet Explorer menu, select Tools > Internet Options, and then click the Security tab.
2. Click the Local intranet icon, and then click the Sites button.
3. Click the Advanced button, and then add the Web address of the host name of the Lotus Connections server into the “Add this website to the zone field.” For example: *.enterprise.example.com.
4. Click OK to save the change, and return to the main Security page.
5. Click the Custom level button, scroll to find User Authentication > Logon, and then select Automatic logon only in Intranet zone. Click OK.
6. Click the Advanced tab, scroll to find Security, and then select Enable Integrated Windows Authentication. Click OK.
7. Restart the Web browser to apply the configuration changes.

Figure 4. Configuring Internet Explorer

 

To configure Firefox:

Figure 5. Firefox configuration

 

Troubleshooting

Server trace log

To get complete information on SPNEGO authentication, you can set the WebSphere Application Server trace level as follows:

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

The trace below shows the case in which the WebSphere Application Server SPNEGO TAI has been loaded successfully:

[9/7/09 13:35:56:093 CST] 0000000a TrustAssociat A SECJ0121I: Trust Association Init class com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl loaded successfully

...

[9/7/09 13:35:56:125 CST] 0000000a ServerCredent I com.ibm.ws.security.spnego.ServerCredentialsFactory initializeServer CWSPN0016I: Ready to process host: virtual.cn.ibm.com.

[9/7/09 13:35:56:125 CST] 0000000a TrustAssociat I com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl initialize CWSPN0006I: SPNEGO Trust Association Interceptor initialization is complete. Configuration follows:

TAI configuration (JVM) properties:

com.ibm.ws.security.spnego.isEnabled=true

Server configuration:

Kerberos ServicePrincipalName=HTTP/virtual.cn.ibm.com@CN.IBM.COM

com.ibm.ws.security.spnego.SPN.filter=request-url!=/seedlist/authverify;request-url!=/seedlist/server;request-url!=/seedlist/myserver;request-url!=noSPNEGO

com.ibm.ws.security.spnego.SPN.filterClass=com.ibm.ws.security.spnego.HTTPHeaderFilter@47624762

com.ibm.ws.security.spnego.SPN.NTLMTokenReceivedPage=file:/c:/share/TAIRedirect.html

com.ibm.ws.security.spnego.SPN.spnegoNotSupportedPage=file:/c:/share/TAIRedirect.html cannonicalSupport=false

Server debugging

The Fiddler Web debugger can diagnose Windows SSO issues by capturing detailed HTTP request and response information. Figure 6 shows the 401 response status code and the www-authenticate: Negotiate response header for SPNEGO authentication in Fiddler.

Figure 6. Screenshot of Fiddler SPNEGO challenge

 

The following trace log shows when a protected URL is accessed; if the LtpaToken is not present, the SPNEGO TAI will be invoked and return a 401 status code for SPNEGO authentication:

[9/7/09 13:58:32:328 CST] 00000025 EJSWebCollabo 3 Request Context Path=/blogs, Servlet Path=, Path Info=/

[9/7/09 13:58:32:359 CST] 00000025 WebCollaborat > authorize Entry

[9/7/09 13:58:32:359 CST] 00000025 WebAuthentica > authenticate Entry

[9/7/09 13:58:32:359 CST] 00000025 TrustAssociat > getInterceptor() Entry

[9/7/09 13:58:32:375 CST] 00000025 WebAuthentica > handleSSO Entry

[9/7/09 13:58:32:375 CST] 00000025 WebAuthentica 3 Could not find LTPA cookie(s) in request.

[9/7/09 13:58:32:375 CST] 00000025 TAIWrapper > isTargetInterceptor() Entry

[9/7/09 13:58:32:375 CST] 00000025 TrustAssociat < com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl isTargetInterceptor: true RETURN

[9/7/09 13:58:32:375 CST] 00000025 WebAuthentica 3 TAI [com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl] is available for this request.

[9/7/09 13:58:32:375 CST] 00000025 TrustAssociat > com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl negotiateValidateandEstablishTrust ENTRY

[9/7/09 13:58:32:390 CST] 00000025 SpnegoHandler < com.ibm.ws.security.spnego.SpnegoHandler handleRequest: Handshake not finished RETURN

[9/7/09 13:58:32:390 CST] 00000025 TrustAssociat < com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl negotiateValidateandEstablishTrust RETURN com.ibm.wsspi.security.tai.TAIResult@7dd07dd0

[9/7/09 13:58:32:390 CST] 00000025 TAIWrapper < negotiateAndValidateEstablishedTrust(): status code = 401 Exit

Figure 7 shows the case in which the browser sends the SPNEGO authentication token to the server and it's authenticated by WebSphere Application Server. In the response, LtpaToken and LtpaToken2 are returned for subsequent communication.

Figure 7. Screenshot of Fiddler successful authentication

 

In the trace log below, we can see that there is no LtpaToken present in the request, but the SPNEGO authentication token is provided, so the SPNEGO TAI is invoked to process the authentication token.

Finally, the SPNEGO TAI authenticates the user, resolves the user principal name, maps that UPN to the user in the federated user repository, and returns a 200 status code. WebSphere log-in modules will continue processing the request to generate the LtpaTokens.

[9/7/09 13:58:32:406 CST] 00000025 EJSWebCollabo 3 Request Context Path=/blogs, Servlet Path=, Path Info=/

[9/7/09 13:58:32:421 CST] 00000025 WebCollaborat > authorize Entry

[9/7/09 13:58:32:421 CST] 00000025 WebAuthentica > authenticate Entry

[9/7/09 13:58:32:421 CST] 00000025 TrustAssociat > getInterceptor() Entry

[9/7/09 13:58:32:421 CST] 00000025 WebAuthentica > handleSSO Entry

[9/7/09 13:58:32:421 CST] 00000025 WebAuthentica 3 Could not find LTPA cookie(s) in request.

[9/7/09 13:58:32:421 CST] 00000025 TAIWrapper > isTargetInterceptor() Entry

[9/7/09 13:58:32:421 CST] 00000025 TrustAssociat < com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl isTargetInterceptor: true RETURN

[9/7/09 13:58:32:421 CST] 00000025 WebAuthentica 3 TAI [com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl] is available for this request.

[9/7/09 13:58:32:421 CST] 00000025 TrustAssociat > com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl negotiateValidateandEstablishTrust ENTRY

[9/7/09 13:58:32:421 CST] 00000025 SpnegoHandler 2 com.ibm.ws.security.spnego.SpnegoHandler handleRequest Found Authorization header, processing SPNEGO request token..

[9/7/09 13:58:32:468 CST] 00000025 SpnegoHandler 2 com.ibm.ws.security.spnego.SpnegoHandler handleRequest SPNEGO request token successfully processed.

[9/7/09 13:58:32:468 CST] 00000025 Context < com.ibm.ws.security.spnego.Context getPrincipalName RETURN Administrator@CN.IBM.COM

[9/7/09 13:58:32:468 CST] 00000025 TAIWrapper < negotiateAndValidateEstablishedTrust(): status code = 200 Exit

The following trace shows what happens when a request with a valid LtpaToken is processed by WebSphere Application Server. WebSphere handles SSO before SPNEGO TAI invocation; if the LtpaToken is valid, WebSphere will authenticate the user with the LtpaToken and therefore SPNEGO TAI is bypassed.

[9/7/09 13:59:06:546 CST] 00000025 EJSWebCollabo 3 Request Context Path=/blogs, Servlet Path=/roller-ui/scripts/authCheck.jsp, Path Info=null

[9/7/09 13:59:06:546 CST] 00000025 WebCollaborat > authorize Entry

[9/7/09 13:59:06:546 CST] 00000025 WebAuthentica > authenticate Entry

[9/7/09 13:59:06:562 CST] 00000025 WebAuthentica > handleSSO Entry

[9/7/09 13:59:06:562 CST] 00000025 WebAuthentica 3 Attempting primary cookie validation for: LtpaToken2

[9/7/09 13:59:06:562 CST] 00000025 WebAuthentica 3 The LTPA token was valid.

[9/7/09 13:59:06:562 CST] 00000025 WebAuthentica < handleSSO Exit

[9/7/09 13:59:07:890 CST] 00000025 WebAuthentica < authenticate Exit

[9/7/09 13:59:07:890 CST] 00000025 ContextManage > setCallerSubject Entry

[9/7/09 13:59:07:890 CST] 00000025 ContextManage 3 Setting caller subject: Subject:

Principal: Administrator@CN.IBM.COM

Principal: defaultWIMFileBasedRealm/administrator@cn.ibm.com

Public Credential: com.ibm.ws.security.auth.WSCredentialImpl@6ca86ca8

Private Credential: com.ibm.ws.security.token.SingleSignonTokenImpl@35d235d2

Private Credential: com.ibm.ws.security.token.AuthenticationTokenImpl@348c348c

Private Credential: com.ibm.ws.security.token.AuthorizationTokenImpl@9f609f6

Tip: When you look at the trace log with the trace on WebSphere Application Server security enabled, search for the keyword “Request Context”. This keyword will lead you to where WebSphere Application Server starts to process the inbound requests and will give you more details on these requests.

Client side debugging

Verify the TGT and service tickets. To verify whether TGT or service tickets are successfully received on the client machine, you can use the klist utility we introduced above in Section 4.1, Join the Active Directory domain.

You should see HTTP/@ in the cached service tickets list. If you don't see the correct cached tickets, there are two possible issues: (1) the browser is not configured properly or (2) the service ticket request fails. When the service ticket request fails, check the events in your Active Directory domain controller.

Audit account log-on events on domain controller. Available events on Windows 2003 are listed in table 2. Basically we need focus on the 672 and 673 events for successful log on.

Table 2. Windows 2003 Account Logon Events

Account Logon Events	Description
672	An authentication service (AS) ticket was successfully issued and validated.
673	A ticket granting service (TGS) ticket was granted.
674	A security principal renewed an AS ticket or TGS ticket.
675	Preauthentication failed. This event is generated on a Key Distribution Center (KDC) when a user types in an incorrect password.
676	Authentication ticket request failed. This event is not generated in Windows XP or in the Windows Server 2003 family.
677	A TGS ticket was not granted. This event is not generated in Windows XP or in the Windows Server 2003 family.
678	An account was successfully mapped to a domain account.
681	Logon failure. A domain account logon was attempted. This event is not generated in Windows XP or in the Windows Server 2003 family.
682	A user has reconnected to a disconnected terminal server session.
683	A user disconnected a terminal server session without logging off.

Refer to the Microsoft TechNet article, “Audit Account Logon Events,” for more detailed information on the Kerberos log-on event. To view the audited log-on events, on your Active Directory domain controller:

1. Open the Event Viewer via the Windows menu commands Start > Control Panel > Administrative Tools > Event Viewer.
2. On the left-hand side of the Event Viewer window, select Security; a list of the audited security events will display on the right-hand side.
3. Select a log-on event from the list; a successful service ticket request event looks like that shown in figure 8.

Figure 8. Event Properties window

 

Conclusion

This article briefly discussed the Windows single sign-on configurations for Lotus Connections 2.5, providing explanations and tips for each configuration step. We also introduced how to diagnose Windows SSO issues on both the WebSphere Application Server side and client side.

The configuration tips and troubleshooting steps offered here also apply to other Web applications that provide the Windows SSO feature with the WebSphere Application Server SPNEGO TAI.

Resources

• Refer to the Lotus Connections 2.5 Information Center.

• Refer to the IBM Lotus Connections product page.

• Refer to the WebSphere Application Server V6.1 Information Center.

• Participate in the discussion forum.

About the authors

Yu Xiao Feng

Staff Software Engineer

IBM China Software Development Lab

Shanghai, China

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

Li Sheng Shuang

Software Engineer

IBM China Software Development lab

Beijing, China

Li Sheng Shuang is a Software Engineer working on SVT for Lotus Connections at IBM's China Software Development Lab in Beijing. You can reach her at lishengs@cn.ibm.com.

Yang Chao Feng

Software Engineer

IBM China Software Development lab

Beijing, China

Yang Chao Feng is a Software Engineer working on SVT for Lotus Connections at IBM's China Software Development Lab in Beijing. You can reach him at yangcf@cn.ibm.com.