Configure Kerberos / SPNEGO with Connections

The HCL Connections documentation describes the process for configuring Windows desktop single-sign-on in a somewhat complicated way. Here are the necessary steps for setting up with the highest possible encryption.

Windows Settings

Service user for Kerberos delegation

For security, I registered an AD User svc-cnx as a standard user for Kerberos.

It’s important to enable these two options now, as the user needs a password change to actually use the higher encryption ciphers!

Create keytab (as Windows Administrator)

I tried using the commands from the official documentation, but without -ptype KRB5_NT_PRINCIPAL -crypto AES256-SHA1 it didn’t work. It created a keytab, but showed this warning:

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

Here’s the working command to generate the keytab file:

ktpass -out cnx8_aes.keytab
       -princ HTTP/cnx8.stoeps.home@AD.STOEPS.HOME
       -mapuser svc-cnx@ad.stoeps.home
       -mapOp set -pass Passw0rd1
       -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL

I registered the SPN to the first webserver - in this case, the nginx server which sends part of the traffic to the customizer and the other part to IHS.

To check the content of your keytab

ktpass -in cnx8_aes.keytab

Existing keytab:

Keytab version: 0x502
keysize 87 HTTP/cnx8.stoeps.home@AD.STOEPS.HOME ptype 1 (KRB5_NT_PRINCIPAL) vno 5 etype 0x12 (AES256-SHA1) keylength 32 ...

WARNING: No principal name specified.

The keytab file without the -ptype KRB5_NT_PRINCIPAL -crypto AES256-SHA1 switches (even with the AES option activated in the user profile):

ktpass -in .\Desktop\cnx8.keytab
Existing keytab:

Keytab version: 0x502
keysize 71 HTTP/cnx8.stoeps.home@AD.STOEPS.HOME ptype 0 (KRB5_NT_UNKNOWN) vno 3 etype 0x17 (RC4-HMAC) keylength 16 ...

WARNING: No principal name specified.

The KRB8_NT_UNKNOWN type broke my SSO.

Delegate SPN

Go back to Active Directory Users and Computers and open the svc-cnx user account.

WebSphere register kdc

$AdminTask createKrbConfigFile { -krbPath /opt/IBM/SharedArea/kdc/krb5.conf -realm AD.STOEPS.HOME -kdcHost dc.ad.stoeps.home -dns dc.ad.stoeps.home -keytabPath /opt/IBM/SharedArea/kdc/cnx8_aes.keytab }

I recommend copying the krb5.conf and keytab to a folder on the Connections Shared Directory. If you use the path from the documentation, you’ll need to replicate/copy the files on each WebSphere node.

Additional configuration in Integrated Solutions Console

Create a new SPNEGO Filter:

Copy the filter from Configuring SPNEGO (and Kerberos optionally) on WebSphere® Application Server .

Activate the two options Trim Kerberos realm from principal name and Enable delegation of Kerberos credentials. Save your changes with OK.

Back at SPNEGO web authentication page, add the path to your keytab and krb5.conf files.

Do not enable Use the alias host name for the application server, or you’ll need to register a keytab file for each WebSphere Application server.

A word about the WebSphere Realm Name

In several SPNEGO and troubleshooting guides, you’ll find tips to change the realm name from defaultWIMFileBasedRealm to the LDAP server hostname and to use a Windows account for the admin user in connectionsAdmin and WebSphere. I’ve never had issues using the default realm name or a local user for SPNEGO. This hasn’t been necessary since at least WebSphere Application server 8.0.

Test single-sign on

I typically test with Firefox on a Windows Desktop that’s a member of the AD domain.

Open Firefox config with about:config and search for negotiate.

Add the Connections URL to network.negotiate-auth.delegation-uris and network.negotiate-auth.trusted-uris.

Now access the Connections Profiles (e.g. https://cnx8.stoeps.home/profiles) and check if SSO is working. I don’t use /homepage because SSO hasn’t worked with Homepage since early Connections 8.0.

I got /homepage working with a change in Enterprise Applications > Homepage > Security role to user/group mapping (Thanks Martin for the tip):

Troubleshooting

On Windows desktop, check klist:

You can delete all Kerberos tickets with klist purge, and they’ll be recreated when you access a service secured by Kerberos. To verify if SSO is working, delete all tickets, clear the browser cookies for your Connections host, and load Connections again.

Enable Kerberos traces

Application servers > AppServer hosting Profiles > Process definition > Java Virtual Machine > Custom properties

To disable, set both to off.

Kerberos messages will now be logged to the application server SystemOut.log.

Configure Time Synchronization in Redhat 9 and Windows 2019

Clock synchronization is crucial for Kerberos authentication (which SPNEGO uses) because it relies heavily on timestamps for security. Here’s why it’s so important:

Kerberos uses a timestamp-based mechanism to prevent replay attacks. When a ticket is issued, it contains timestamps that indicate when the ticket was created and when it expires. All parties in the authentication process check these timestamps.

If the clocks aren’t synchronized:

1. Ticket validation fails: If the server clock is significantly ahead of the client, it might reject valid tickets as “not yet valid” or already expired.
2. Premature expiration: If the server clock is ahead, tickets might be considered expired before their actual lifetime ends.
3. Replay attack vulnerability: If clocks are too far out of sync, the time window used to detect replay attacks becomes ineffective.
4. Authentication failures: The Kerberos protocol typically allows only a small time skew (usually around 5 minutes by default) between systems. Beyond this threshold, authentication attempts will fail with errors like the one you’re seeing.

Kerberos implementations use these strict time requirements as a security feature. If an attacker captured a Kerberos ticket, they would only have a limited time window to use it. Without synchronized clocks, this security mechanism breaks down.

For WebSphere specifically, the JVM hosting the application passes the Kerberos authentication requests to the operating system’s security mechanisms, which enforce these time synchronization requirements.

Windows 2019

PS C:\Users\Administrator> W32tm /register
W32Time successfully registered.
PS C:\Users\Administrator> W32tm /dumpreg

Value Name             Value Type          Value Data
--------------------------------------------------------

Type                   REG_DWORD           32
Start                  REG_DWORD           2
ErrorControl           REG_DWORD           1
ImagePath              REG_EXPAND_SZ       %SystemRoot%\system32\svchost.exe -k LocalService
DisplayName            REG_SZ              @%SystemRoot%\system32\w32time.dll,-200
ObjectName             REG_SZ              NT AUTHORITY\LocalService
Description            REG_SZ              @%SystemRoot%\system32\w32time.dll,-201
FailureActions         REG_BINARY          80510100000000000000000003000000140000000100000060EA000001000000C0D401000000000000000000
ServiceSidType         REG_DWORD           1
RequiredPrivileges     REG_MULTI_SZ        SeAuditPrivilege, SeChangeNotifyPrivilege, SeCreateGlobalPrivilege, SeSystemTimePrivilege, SeImpersonatePrivilege
DelayedAutostart       REG_DWORD           1

PS C:\Users\Administrator> w32tm /config /syncfromflags:manual /manualpeerlist:"0.de.pool.ntp.org 1.de.pool.ntp.org 2.de.pool.ntp.org 3.de.pool.ntp.org" /update
PS C:\Users\Administrator> w32tm /resync /force

Restart the Windows Time Service from the Services Tool.

Redhat 9 on Libvirt

This is only needed when the virtual machine is running on LibVirt:

echo ptp_kvm > /etc/modules-load.d/ptp_kvm.conf
echo "refclock PHC /dev/ptp0 poll 2" >> /etc/chrony.conf
systemctl restart chrony

chrony

Use chrony to synchronize time on RedHat 9 VMs.

Configure timezone

timedatectl set-timezone Europe/Amsterdam