Sso nac

SPNEGO SSO Multi Domain Configuration Guide
Multi domain setup
This document describes the step necessary to configure SPNEGO SSO to work in a multi domain setup. Note that the changes described below must be done after the general configuration is done according to the document “SPNEGO SSO Active Directory Setup Guide” and “SPNEGO SSO JAAS and JGSS configuration”. Briefly explained, thechanges needed to the configuration is purely based on Kerberos elements. The Kerberos GSSAPI must be able to know how to handle multiple SPN's and KEYTAB files. The Kerberos GSSAPI subsystem can only handle one KEYTAB file, which requires that data from individual domains must be merged into one KEYTAB file. When the SPNEGO SSO authenticator received the service ticket, it specifies the correct entryin the KEYTAB file to be used to decrypt and handle the ticket. The following steps describes the changes that is needed. Each step will be explained more thoroughly in the sections in this document. 1. SPN accounts must be created on each of the domains. Users in each domain will only have access to their separate domain and the domain controller can only issue tickets for that specific domain.When the SPN account in defined as described in this document, the KEYTAB file must be generated for each domain. 2. All KEYTAB files must be merged together into a single KEYTAB containing all the SPN names and keys. This is easiest done on a Unix or Linux machine with Kerberos subsystem installed. Below command will merge each file into the krb5.keytab file. 3. The krb5.conf must be updated toreflect the multiple domains. 4. Updating the spnego.properties file / setting the system properties. The GSSAPI SASL client does not support multiple domains. It will use the DEFAULT REALM as defined in the krb5.conf as basis of generating client credentials. This means that the property “dk.itp.spnego.useGssApi” must be set “false”. And when this property is set to false, JNDI credentials must bedefined in the configuration.

Merging KEYTAB files
The following commands run from a Unix or Linux prompt will merge the KEYTAB files from TST.NET and TEST.NET into one file webserver.keytab.

# /usr/sbin/ktutil ktutil: rkt tst.keytab ktutil: rkt test.keytab ktutil: wkt webserver.keytab ktutil: quit

The content of the file can be verified with the KTPASS command (on the windows platform)C:\Resource Kit>ktpass -in webserver.keytab ** 0x1 Failed to read leading bytes (probably done) Tacking on to existing keytab: Keytab version: 0x502 keysize 59 HTTP/webserver.test.net@TEST.NET ptype 1 (KRB5_NT_PRINCIPAL) vno 255 etype 0x3 (DES-CBC-MD5) keylength 8 (0xf11f0e1c1cb0a207) keysize 57 HTTP/webserver.tst.net@TST.NET ptype 1 (KRB5_NT_PRINCIPAL) vno 7 etype 0x3 (DESCBC-MD5) keylength 8(0xdff768f1fe40bc13)

Above output is an example only, as output depends on the SPN names and domains/REALM's used.

Updating krb5.conf with multiple domains
All the domains/realms must be defined in the KRB5.conf. An example:

[libdefaults] default_keytab_name = webserver.keytab default_realm = TEST.NET default_tkt_enctypes = des-cbc-md5 default_tgs_enctypes = des-cbc-md5 default_checksum= rsa-md5 kdc_timesync = 0 kdc_default_options = 0x40000010 clockskew = 300 check_delegate = 0 ccache_type = 3 kdc_timeout = 60000 forwardable = true [realms] TEST.NET = { kdc = SERVER1.TEST.NET SERVER2.TEST.NET } TST.NET = { kdc = SERVER1.TST.NET } [domain_realm] .test.net = TEST.NET test.net = TEST.NET .tst.net = TST.NET tst.net = TST.NET
Above example has two domains defined. The TEST and TSTdomains.

Updating spnego.properties with multiple domains
The GSSAPI SASL mechanism is not supported with multiple domains, which requires that the property

dk.itp.spnego.useGssApi=false

Setting this “false” requires a userid/password for each of the domains. Passwords can either be specified in plain text or encrypted. The following example describes the userid and plain text password...