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:
Running on the following operating systems:
As an illustration, review the following example environment for configuring each browser:
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.
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: 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.
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.
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 joe@ADEXAMPLE.PINGIDENTITY.COMjoe@ADEXAMPLE.PINGIDENTITY.COM'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"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.