Konfiguracja SSO z wykorzystaniem Kerberos

The article describes the list of steps necessary to set up auto login on a system using Kerberos authentication in a Windows environment.

Step-by-step guide

Get the required information:
1. domain name
2. the address of the domain controller (e.g. using the echo %logonserver% command)
3. the name and password of the account used to communicate with the domain controller
4. the address of the server that will be used to test the solution
5. the test account that is in the domain
Make sure that the SPN (Service Principal Name) for the account used to communicate with the domain controller has been properly configured on the domain controller

To view all SPNs for a given account: setspn /l <domain>\<user>
To register the required SPNs for a given account:
setspn -s HTTP/<PlusWorkflow server name> <domain>\<user>
setspn -s HTTP/<PlusWorkflow server name>.<domain> <domain>\<user>
eg.
setspn -s HTTP/plusworkflow_test suncode\ldap_account
setspn -s HTTP/plusworkflow_test.suncode.com suncode\ldap_account
Add a test account that is in your domain to the PlusWorkflow system
1. login: <domain>/<user>
2. leave the password blank
Add a LDAP server to the PlusWorkflow system in Administration -> System Configuration -> LDAP Servers
In the system parameters, enable auto login and set the account to connect to the domain controller

Modify the WEB-INF/krb5.conf file

[libdefaults]
	default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc
	default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc
	permitted_enctypes   = aes256-cts-hmac-sha1-96 aes128-cts rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc 
	default_realm = suncode.com
[realms]
	suncode.com  = {
		kdc = KDC.suncode.com
		default_domain = suncode.com 
}
[domain_realm]
	.suncode.com = suncode.com
	suncode.com = suncode.com

where:

kdc = FQDN for Key Distribution Center (most likely domain controller)
default_tkt_enctypes orad default_tgs_enctypes = available ticket encryption algorithms

It is recommended to move the krb5.conf file to the <plusworkflow.home>/config/kerberos/krb5.conf location. This eliminates the need to store this file in the client project. The system reads this file from the system's home directory first.

There may be cases where you need to modify the WEB-INF/login.conf file (in most cases you don't need to do this). In this case, too, it is best to move the file to the <plusworkflow.home>/config/kerberos/login.conf location to avoid storing it in the client project.
Configure the browsers
1. Mozilla Firefox
  1. type about:config in the address bar
  2. search for network.negotiate-auth.trusted-uris configuration
  3. set as parameter value the path to the server on which PlusWorkflow is running, e.g. http://plusworkflow_test
2. Internet Explorer
  1. add the system URL to trusted sites in Internet Options -> Security tab -> Trusted Sites
  2. check the Enable Windows Integrated Authentication option in Internet Options -> Advanced tab -> Security
  3. below Trusted Sites, click Custom Level and in the User Authentication section, check Log in automatically with the current username and current password
Restart the system
Test the operation of SSO
1. log in to the computer in the domain using the account you previously added to the PlusWorkflow system
2. delete all tickets from the system using the klist purge command
3. log in to the system automatically by typing the system address in the browser bar (log in by server name, not address)

Troubleshooting

Once properly configured and attempted to log in automatically, the klist command should display tickers similar to the following:
Make sure that the case of the user's login in the domain controller is identical to the case of the user's login in the PW system.
When checking the checkboxes in the username settings, change the password to another new one and re-enter it in the system (system parameters and LDAP if the same account defined there)

Verify that the setspn command has been executed correctly on the AD server by executing (usually this must be done by the client since we do not have access to that server) a script in powershell:

Skrypt Powershell

$serviceType="HTTP"

$spns = @{}

$filter = "(servicePrincipalName=$serviceType/*)"
$domain = New-Object System.DirectoryServices.DirectoryEntry
$searcher = New-Object System.DirectoryServices.DirectorySearcher
$searcher.SearchRoot = $domain
$searcher.PageSize = 1000
$searcher.Filter = $filter
$results = $searcher.FindAll()


foreach ($result in $results){
 $account = $result.GetDirectoryEntry()
 foreach ($spn in $account.servicePrincipalName.Value){
  if($spn.contains("$serviceType/")){
   $spns[$("$spn`t$($account.samAccountName)")]=1;
  }
 }
}
$spns.keys | sort-object

The result of this script should be sent to us by the client. You should then check if there is a PlusWorkflow server with the indicated username in the list of spn records.

Step-by-step guide

Troubleshooting

Related articles

4 Comments

Tomasz Wojciechowski

Tomasz Wojciechowski

Dział Wdrożeń

Dział Wdrożeń