The basis is that you have to use an Active Directory server ( W2K or higher ).
In order to make use of the SPNEGO function you have to logon to an AD domain.

When logged in to the AD domain you will receive a kerberos ticket and this is
what is nessecary to make this whole thing rolling.

Besides this requirement you will have to take the following things in consideration.

- AD domain ( W2K or higher )
- WebSphere Application Server 6.1 ( any OS )
- Security enabled for WAS
- A configured User Repository, stand-alone or federared both can be used.
- Type of User Repository can be any of the supported ones by WAS.
( NOTE:
There has to be a link between the login names in the
AD LDAP and the ones in the User Repository used by WAS.

Example: Login attribute in AD is samAccountName, the login attribute
of our WAS Domino User Repo is CN.

samAccountName = MEn
cn = Marco Ensing

Because Domino can use multple CN’s you will have to take care that the
name “MEn” needs to become a CN value in the domino LDAP.
)

For me of course enabling SSO with Lotus Connections is what I’am
looking for but this feature can be used with any Portal or
WebSphere Application server app. running on WAS version 6.1.

Found a two links that were very helpfull for me understanding the
whole concept of SNPEGO in combination with WebSphere.

Step-by-step guide enabling SPNEGO

SPNEGO TAI: Using single sign-on from Windows to WebSphere Application Server

Theory how-it-works

WebSphere with a side of SPNEGO

One handy tool that I found on the web is kerbtray.exe, I was
configuring SPNEGO for a customer running Portal 6.1 in a
Windows 2000 Domain.

When following the documentation mentioned above I
should use the encryption type of DES-MD5 for the keytab file.

Configuring everything to make use of this encryption type I
dug myself in trying serveral variations of the keytab file and
the non-stoppable reboots for the portal server.

But when I ran this tool, kerbtray.exe on one of the client
stations I saw that the encryption type used was RC4-HMAC,
one that only should be used in a Windows 2003 AD domain.

Had now clue why this was happening, but I created a new
keytab file with the encryption type RC4-HMAC thing
that then came above was that everything started working .

( Domain was formed by two Windows 2000 Domain Controlers
and a number of 10 Windows 2003 Domain Controllers.
The forest was Windows 2000 in mixed mode )

Think I have to find a explanation for this behaviour from
the Windows administrators corner.

Windows 2000 Resource Kit Tool: Kerbtray.exe