The Transparent Kerberos Authentication Single-Sign On (SSO) solution transparently authenticates users already logged into AD. This means that a user authenticates to the domain one time and has access to all authorized network resources without having to enter credentials again. If Transparent Kerberos Authentication fails, the user is redirected to the Captive Portal for manual authentication.
Note -The Identity Agent download link and the Automatic Logout option are ignored when Transparent Kerberos Authentication SSO is successful. The user does not see the Captive Portal.
SSO in Windows domains works with the Kerberos authentication protocol.
The Kerberos protocol is based on the concept of tickets, encrypted data packets issued by a trusted authority, Active Directory (AD). When a user logs in, the user authenticates to a domain controller that gives an initial ticket granting ticket (TGT). This ticket vouches for the user's identity.
In this solution, when an unidentified user is about to be redirected to the Captive Portal for identification:
Transparent Kerberos Authentication uses the GSS-API Negotiation Mechanism (SPNEGO) internet standard to negotiate Kerberos. This mechanism works like the mechanism that Identity Agents use to present the Kerberos ticket.
You can configure SSO Transparent Kerberos Authentication to work with HTTP and/or HTTPS connections. HTTP connections work transparently with SSO Transparent Kerberos Authentication at all times. HTTPS connections work transparently only if the Security Gateway has a signed .p12
certificate. If the Security Gateway does not have a certificate, the user sees, and must respond to, the certificate warning message before a connection is made.
For more about Kerberos SSO, we recommend the MIT Kerberos web site and the Microsoft TechNet Library.
Transparent Kerberos Authentication SSO configuration includes these steps. They are described in details in this section.
HTTP/<captive portal full dns name>@DOMAIN
)HTTPS/<captive portal full dns name>@DOMAIN
)Where applicable, the procedures give instructions for both HTTP and HTTPS configuration.
You can choose any username and password. For example: a user account named ckpsso
with the password qwe123!@#
to the domain corp.acme.com
.
Run the setspn
utility to create a Kerberos principal name, used by the Security Gateway and the AD. A Kerberos principal name contains a service name (for the Security Gateway that browsers connect to) and the domain name (to which the service belongs).
setspn
is a command line utility that is available for Windows Server 2000 and higher.
Install the correct setspn.exe
version on the AD server. The setspn.exe
utility is not installed by default in Windows 2003.
To get the correct executable:
On Windows 2003:
support.cab
and suptools.msi
files to a new folder on your AD server.suptools.msi
.If you use Active Directory with Windows Server 2008 and above, the setspn
utility is installed on your server in the Windows\System32
folder. Run the command prompt as an Administrator.
Important - If you used the setspn
utility before, with the same principal name, but with a different account, you must delete the different account or remove the association to the principal name.
To remove the association, run:setspn -D HTTP/
<captive_portal_full_dns_name> <old_account name>
If you do not do this, authentication will fail.
To use setspn:
setspn
with this syntax:For HTTP connections:
> setspn -A HTTP/<captive_portal_full_dns_name> <username>
For HTTPS connections:
> setspn -A HTTPS/<captive_portal_full_dns_name> <username>
Important - Make sure that you enter the command exactly as shown. All parameters are case sensitive.
Example:
> setspn -A HTTP/mycaptive.corp.acme.com ckpsso
The AD is ready to support Kerberos authentication for the Security Gateway.
To see users associated with the principle name, run: setspn -Q HTTP*/*
If you already have an Account Unit from the Identity Awareness First Time Configuration Wizard, use that unit. Do not do the first steps. Start with: "Click Active Directory SSO configuration and configure the values".
To configure an Account Unit:
In the Object Explorer, click New > Server > LDAP Account Unit.
Best Practice - Enter the domain for existing Account Units to use for Identity Awareness. If you enter a domain, it does not affect existing LDAP Account Units.
Note - LDAP over SSL is not supported by default. If you did not configure your domain controller to support LDAP over SSL, configure it, or make sure Use Encryption (SSL) is not selected.
The Portal Settings window opens.
The Main URL field contains the URL (with IP address or Hostname) that is used to begin the SSO process. If transparent authentication fails, users are redirected to the configured Captive Portal.
To work with Transparent Kerberos Authentication, it is necessary to configure your browser to trust Captive Portal URL. If the portal is working with HTTPS, you must also enter the URL in the Local Internet field using HTTPS.
It is not necessary to add the Captive Portal URL to Trusted Sites.
To configure Internet Explorer for Transparent Kerberos Authentication:
If you have already configured Internet Explorer for Transparent Kerberos Authentication, that configuration also works with Chrome. Use this procedure only if you did not configure Internet Explorer for Transparent Kerberos Authentication.
To configure Google Chrome for Transparent Kerberos Authentication:
For Firefox, the Negotiate authentication option is disabled by default. To use Transparent Kerberos Authentication, you must enable this option.
To configure Firefox for Transparent Kerberos Authentication:
about:config
network.negotiate-auth.trusted-uris
parameter.