How to configure supported browsers for Kerberos and NTLM

how.to.configure.supported.browsers.for.Kerberos.and.NTLM

# from https://ping.force.com/Support/PingFederate/Integrations/How-to-configure-supported-browsers-for-Kerberos-NTLM#chrome
How to configure supported browsers for Kerberos and NTLM
Published: 01/25/2018

The PingFederate Integrated Windows Authentication (IWA) Adapter supports the Kerberos and NTLM authentication protocols, but some browsers need to be configured to utilize them.  The following guide will define which settings are necessary in each browser.

For Kerberos and NTLM authentication, the PingFederate IWA Adapter utilizes the SPNEGO (Simple and Protected GSS-API Negotiation) mechanism to negotiate either Kerberos or NTLM as the underlying authentication protocol.  Each browser below supports SPNEGO, but differences exist that may affect which protocol is negotiated in each instance, due to the combination of browser and OS.

The PingFederate IWA Adapter supports the following browsers:

    Internet Explorer
    Mozilla Firefox
    Google Chrome
    Apple Safari

Running on the following operating systems:

    Windows 7/8
    Mac OS X 10.8
    iOS6.1 (Safari and Chrome)

As an illustration, review the following example environment for configuring each browser:
 
Active Directory domain name:	adexample.pingidentity.com
Active Directory NetBIOS name: 	ADEXAMPLE
PingFederate host name: 	pingsso.adexample.pingidentity.com
PingFederate service principal name (SPN):  	HTTP/pingsso.adexample.pingidentity.com
User principal:  	[email protected]

 

 
Internet Explorer  

Internet Explorer supports IWA out-of-the-box, but may need additional configuration due to the network or domain environment. 

In Active Directory (AD) environments, the default authentication protocol for IWA is Kerberos, with a fall back to NTLM.  If the IWA Adapter is configured for Kerberos within an AD environment, domain-joined clients will request a Kerberos ticket to be used within the Authenticate header response during an IWA transaction.  If Kerberos cannot be negotiated for whatever reason, the IWA adapter will fall back to NTLM challenge/response authentication.  In that case, a user will be prompted for their AD domain credentials.

Additionally, Internet Explorer uses security zones for distinguishing which hosts are Internet, Local intranet, Trusted sites, or Restricted sites.
 
Security zones in IE (Tools → Internet Options → Security):

        Security zones in Internet Explorer
 

By default, any IWA authentication request originating from an Internet host will not be allowed.  The default setting is to only allow clients to automatically provide credentials to hosts within the Intranet zone.  Sites are considered to be in the Intranet zone: if the connection was established using a UNC path (i.e. \\pingsso); the site bypasses the proxy server; or host names that don't contain periods (i.e. http://pingsso).

Intranet Zone security settings:

        Intranet Zone

Most PingFederate SSO connections will use the fully-qualified domain name (FQDN) in SSO URLs, so it will not be categorized as being in the Intranet zone.  As such, the browser must be configured trust the host by adding the PingFederate hostname to the Trusted sites zone.  Here, the default setting is Automatic logon with current user name and password, which implies Kerberos will be used if available, then NTLM.  The setting Prompt for user name and password will bypass Kerberos and go straight to NTLM authentication.  Even if the IWA Adapter supports Kerberos, the client will not attempt to send a Kerberos token within the Authenticate header.

On computers (i.e: servers) with Internet Explorer Enhanced Security Configuration enabled the automatic login behavior will be overridden with a logon prompt. The logon prompt will allow Kerberos and NTLM logon functionality however it will not use the cached credentials from the user login.
To configure Internet Explorer to fully support the IWA adapter, within Internet Explorer, choose Tools → Internet Options → click the Security tab → click on Trusted sites →and click Custom level... Scroll all the way to bottom under User Authentication and under Logon, select Automatic logon with current user name and password.

Trusted Sites Zone security settings:

Trusted Sites Zone Settings

Once this is configured click OK, then click on the Sites button under Trusted sites, and insert the PingFederate server's hostname.  Optionally, wildcards can be included to trust any host name within the AD domain (i.e. *.adexample.pingidentity.com).

Trusted Sites:

Trusted Sites

The above settings work for domain-joined computers (i.e. computers with an Active Directory account principal and trust relationship), as well as non-domain-joined computers.  For domain-joined computers, an AD user account would need to be logged in, and the Kerberos authentication protocol would be negotiated during SSO.  In the case of a non-domain-joined computer, the Kerberos protocol (Negotiate in the WWW-Authenticate header) would not be negotiated, thus a fall back to NTLM.  In this case, the user would be prompted for credentials, which they would enter ADEXAMPLE\joe and the password to be authenticated.**

**Note:  The NetBIOS domain name (ADEXAMPLE in the example above) MUST be used to qualify the user name if: (1) the computer is not joined to an AD domain; or (2) there are multiple AD domains or forests and the user is authenticating over a cross-domain trust (i.e. the user is in DomainA, but the PingFederate NTLM computer account is joined to DomainB).  The NTLM protocol assumes the user is logging in to the domain where the PingFederate computer account exists.  This is why the user name must be qualified by the domain to function correctly.

Also note it is possible to add the PingFederate URL to the Local Intranet zone as an alternative to adding it to the Trusted sites zone. Reasons for this may vary based on the network design of the environment, but setting automatic logon for the Trusted sites zone implies that Negotiate/Authorization credentials may be sent in requests to sites outside of the Intranet Zone.

 
Firefox

Mozilla Firefox supports the SPNEGO authentication protocol, but must be configured to work correctly for Kerberos authentication.  Firefox does not use the concept of security zones like Internet Explorer, but will not automatically present Kerberos credentials to any host unless explicitly configured.  By default, Firefox rejects all SPNEGO challenges from any Web server, including the IWA Adapter.  Firefox must be configured for a whitelist of sites permitted to exchange SPNEGO protocol messages with the browser.

The two settings are:

network.negotiate-auth.trusted-uris
network.automatic-ntlm-auth.trusted-uris

These settings can be defined by:

1. Navigate to the URL about:config in Firefox.  Click the I'll be careful, I promise! button:

About Config

2. In the Search dialog box, search for the above preferences:

Firefox Negotiate Settings

3. In each of the preferences, specify any host or domain names, delimited with commas.  Please note that domains can wildcarded by specifying a domain suffix with a dot in front (i.e. .adexample.pingidentity.com):

Delegation URIs


Just like in Internet Explorer, the computer making the SSO request to the IWA adapter must also be joined to Active Directory (AD) and be logged on with a domain user account.  The same goes for Kerberos vs. NTLM negotiation -- if the computer is not domain-joined, it will fall back to NTLM.

For Firefox running on Mac OS, SPNEGO will negotiate both Kerberos and NTLM if the computer is joined to AD. On non-domain-joined Mac OS, only NTLM will be selected as a mechanism for SPNEGO.

For more information on enabling SPNEGO in Firefox, refer here.

 
Chrome  

Google Chrome in Windows will use the Internet Explorer settings, so configure within Internet Explorer's Tools, Internet Options dialog, or by going to Control Panel and selecting Internet Options within sub-category Network and Internet.

For Chrome under Mac OS X, SPNEGO will work without any additional confguration, but will only negotiate to NTLM.  It is possible to configure a setting named AuthServerWhitelist to authorize host or domain names for SPNEGO protocol message exchanges.  There are a couple ways this can be done:  (1) from the command line; or (2) joining Mac OS to AD.

1. Within a Mac OS Terminal shell use the following command:

You will need to get an initial ticket granting ticket (TGT) from your Kerberos KDC (domain controller) in order to request service tickets for the IWA Adapter:
>kinit [email protected]
[email protected]'s Password: (password here)

Now, cd into the Chrome directory and start Chrome with the AuthServerWhitelist parameter:
>cd /Applications/Google Chrome.app/Contents/MacOS
>./"Google Chrome" --auth-server-whitelist="*.adexample.pingidentity.com"

/etc/krb5.conf
[libdefaults]
 default_realm = UYDC.COM
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 rdns = false
# default_ccache_name = KEYRING:persistent:%{uid}
# default_ccache_name = FILE:/tmp/krb5cc_%{uid}

 udp_preference_limit = 1000000
 default_tkt_enctypes = arcfour-hmac-md5 des-cbc-md5 des-cbc-crc des3-cbc-sha1
 default_tgs_enctypes = arcfour-hmac-md5 des-cbc-md5 des-cbc-crc des3-cbc-sha1
 permitted_enctypes = arcfour-hmac-md5 des-cbc-md5 des-cbc-crc des3-cbc-sha1

[realms]
 UYDC.COM = {
  kdc = 10.200.70.162
  admin_server = 10.200.70.162
 }

[domain_realm]
 .uydc.com = UYDC.COM
 uydc.com = UYDC.COM
 
Note: There's a second policy that one may want to set, AuthNegotiateDelegateWhitelist, to point Chrome to a particular server to delegate credentials to.
Add this parameter to the above command by specifying --auth-negotiate-delegate-whitelist="*.adexample.pingidentity.com"
If this parameter is not set, Chrome will not delegate user credentials even if a server is detected as being on the Intranet.

Once configured, this setting will persist every time Chrome is launched.  You will still need to run kinit every 10 hours in order to allow Chrome to request service tickets for the IWA adapter.


2.  Joining Mac OS to Windows Active Directory:

For information on joining Mac OS to AD, please refer to the following: http://training.apple.com/pdf/Best_Practices_for_Integrating_OS_X_with_Active_Directory.pdf

For iOS (iPad and iPhone), only NTLM via SPNEGO has been tested.  Kerberos has not been tested or verified.

 
Safari

Safari on Windows supports SPNEGO with no further configuration.  It supports both Kerberos and NTLM as sub-mechanisms of SPNEGO.  The same rules apply to Safari as Firefox or Chrome, where the computer doing SSO must be domain-joined and logged in by a domain users.  Otherwise, it will fall back to NTLM authentication.

Safari on Max OS supports SPNEGO with Kerberos as an authentication mechanism if Mac OS is joined to AD (see here: http://training.apple.com/pdf/Best_Practices_for_Integrating_OS_X_with_Active_Directory.pdf). If Mac OS is not joined to AD, then SPNEGO will always negotiate NTLM as the authentication mechanism.

 
Category: Integrations