Active Directory Single Sign-On

This Guide describes how to set automatic Single Sign-On via Active Directory.

WMS Version: 5.X0 / 6.0X

Created: March 2019

Updated: January 2023

Permalink: https://wildix.atlassian.net/wiki/x/_QjOAQ


Step 1. Generate KeyTab file in Active Directory

The procedure works the same for Cloud PBX, Hardware and Virtual Machine PBXs. For Cloud PBX, PBX must access AD for sync user only. 

  1. Choose an arbitrary FQDN to connect your PBX. Enter name in the following format:

[SERVER].[LOCAL-DOMAIN]

Example: pbx.mycompany.local

Note: This address should resolve the PBX IP address.

2. Go to Active Directory Users and Computers -> Computers and create a new computer account:


Notes:

  • This account should not contain a user with the same name.
  • It is recommended to avoid upper case.


3. Create KeyTab file associated to this computer and check spn (service principal name) binding to the computer account, run the following commands with Domain Admin privileges:

ktpass -princ HTTP/some-name.example.com@EXAMPLE.COM -mapuser some-name$@EXAMPLE.COM -crypto ALL -ptype KRB5_NT_SRV_HST +rndpass -out d:\some-name.keytab
Reset SOME-NAME$'s password [y/n]? y

where

some-name$@EXAMPLE.COM - the computer's name in the asset directory (with $)

+ rndpass - the password that is generated for the computer account, where the domain is written in capital letters

4. You can check that KeyTab / SPN is well associated with following command:

setspn -Q HTTP/some-name.example.com


The correct result is: Existing SPN found
Bad result is: No SPN found/ More than one SPN found


If HTTP / some-name.example.com is bound to several computers or users, authentication of Kerberos will not work

When KeyTab is generated, it appears on the disk - d: \ some-name.keytab:

Step 2. Upload KeyTab file to PBX

  • Go to WMS Settings -> PBX -> Security
  • Enable Active Directory Single SignOn via Kerberos (Negotiate)
  • Upload KeyTab file previously generated in Active Directory 

    Limitation: Only "0-9", "a-z", "A-Z", "_," '- ", "@", "." characters are allowed in KeyTab file name.

  • Enter Kerberos FQDN of the KeyTab. It contains encoded domain name/ IP address of PBX:


Step 3. Import users from AD

In order to use AD SSO, you need to import users from Active Directory.

Consult Documentation for details.

Step 4. Active Directory SSO

  • On Windows PC, connected to Active Directory, log in to the system with a user who was previously imported to PBX
  • Reach PBX via the domain name configured as Kerberos FQDN (the name must be resolved to PBX IP address). For example, glebka-test1.wildix2016.inc  

    Note: Configure your browser to authenticate SSO. Refer to the next chapter Browser configuration.

  • If everything is set up correctly, then you log in automatically to Collaboration with the user that you are logged in to Windows PC

Browser configuration

Mozilla Firefox

To access Firefox settings, enter about:config into the Address bar and press [Enter] to open the list of customizable preferences for the current browser's installation.

You need to add FQDN of your PBX into the list of trusted URIs:

  • network.negotiate-auth.trusted-uris - FQDN of the Server

On "Login Page" can you find the right for FQDN.

Chrome

To access Chrome settings:

  • auth-server-whitelist -Allowed FQDN - Set the FQDN of the IdP Server. Example:  

    chrome --auth-server-whitelist="*aai-logon.domain-a.com"

On "Login Page" can you find the right for FQDN.

Opera

Opera does not currently support Kerberos authentication.

Debugging

See instructions in case the following error messages are present in wms.log: 

  • "No entry HTTP://XXXX found in key table"

Possible solution: Check steps 1, 2 and 3 of the guide. The issue is a wrong keytab.

  • "Error accepting security context"

Possible solution: You might need to check if you are connecting to PBX using the correct URL, and if the browser is well configured. 

  •  "No user found in LDAP" 

Check the connection logs and find out what is the PrincipalName used for connection: USER@DOMAIN or USER? If there are no logs of the user, the issue could be the auth-server-whitelist.