Troubleshooting
Authentication – SAML - Browser Settings
Ø This section describes the common issues faced due to incorrect browser settings.A user’s browser displays the error "Can't display the webpage."
This error can be due to any of the following reasons:
The connection is redirected to Zscaler.
The user's workstation cannot connect to the URL.
To avoid this issue, do the following:
Check whether an exception is present in your PAC file to make the connection to the server direct (bypassing Zscaler). You can use the default PAC file with the following exception:
if shExpMatch(host, "*.company.tld") return "DIRECT";
Check whether the workstation can connect to the remote server with the following command line in a DOS shell: > telnet <hostname> 443. If you get a black screen, it means that the connection has been established.
Ø A user’s browser is stuck on the redirection page.
If you are seeing the redirection for more than 10 seconds, it means that SAML redirection is looping. This is often due to your explicit proxy configuration. (Note that the connection to the server must be direct and not redirected to Zscaler.)
To avoid this issue, add an exception to your PAC file. You can use the default PAC file with the following exception:
if shExpMatch(host, "*.company.tld") return "DIRECT";
Ø I am getting a basic Login pop-up; authentication is not transparent.
This issue arises because of two reasons:
User is not authenticated on the organization’s Federation Identity. Check the following:
a. If the user's computer is registered in Active Directory.
b. If the user is logged in to the Windows Domain.
The browser is not configured to forward the user token to this SAML server: By default, Firefox and Chrome browsers do not relay NTLM tokens to the SAML server. To enable this, do the following:
Verify ADSI connected to AD.
Start – Administrative Tools – click ASDI edit –
Check if the If the default naming context tree is available on the left panel.
If not right click the ASDI tree and click connect to
On the DC was missing the configuration for the ADSI which is mandatory to have IWA working properly. Once connected ADSI to the ADFS and added the SPN the IWA process started to work properly.
SPN: http/adfsserver.itzecurity.in
Select managed service accounts – right click the CN properties – Add the SPN URI (http/adfsserver.itzecurity.in) - click ok
Prompting for username and password on IE, chrome and mozila Firefox.
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 Ping Federate 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.
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.
· 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.COM
joe@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.
· 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.
The Firefox and Chrome browsers may not relay NTLM tokens to the SAML server.
· Additional configuration is required on the browsers as follows:
Google Chrome: Specify this parameter on the command line : google-chrome --auth-server-whitelist="*.clientdomain.tld"
· Extended protection mode is set as required on your IIS configuration.
In such case, IIS will not accept Chrome browser. Extended protection mode has to be disabled with following steps:
Turn off Extended Protection. To do that, login to the AD FS server,
· Launch IIS Manager
· On the left side tree view, go to access Sites -> Default Web Site -> adfs -> ls.
· Once you’ve selected the "/adfs/ls" folder, double-click the Authentication icon,
· Right-click Windows Authentication and select Advanced Settings.
· On the Advanced Settings dialog, choose Off for Extended Protection.
Under IIS 7.0, the protected mode configuration is hidden. You need to run the following command in order to disable it:
C:\Windows\System32\inetsrv>appcmd.exe set config "Default Web Site/adfs/ls" -section:system.webServer/security/authentication/windowsAuthentication
/extendedProtection.tokenChecking:"None" /extendedProtection.flags:"None" /commit:apphost
Under Windows 2012:
1. Open PoweShell Command Window
2. Load ADFS Poweshell SnapIn
3. Add-PsSnapIn Microsoft.Adfs.Powershell
4. Set ADFS to diable EAP at the farm level
5. Set-ADFSProperties -ExtendedProtectionTokenCheck:None
6. Restart ADFS and IIS (IISReset, Net Stop ADFS, Net Start ADFS)
Mozilla User-Agent are not authorized to authenticate under ADFS 3.0
Update supported browser list with the following command to enable authentication with Chrome / Firefox / Safari browsers: Open Powershell CLI and execute the following command
Set-ADFSProperties -WIASupportedUserAgents @(“MSIE 6.0″, “MSIE 7.0″, “MSIE 8.0″, “MSIE 9.0″, “MSIE 10.0″, “Trident/7.0″, “MSIPC”, “Windows Rights Management Client”, “Mozilla/5.0″, “Safari/6.0″, “Safari/7.0″)
NTLM and Kerberos work out of the box in some browsers. Others may require some configuration. See the details below for each browser.
Internet Explorer - Ensure that Internet Explorer can save session cookies.
Navigate to your Windows control panel and select Internet Options > Advanced.
Within Security, select Enable Integrated Windows Authentication, and then select OK.
Chrome - Chrome will only supply the NTLM token to the site if that site is on the approved list, provided as a parameter at browser startup. Without this parameter, the permission list will include Local Machine servers or Local Intranet security zone servers. To configure this parameter:
· Create a shortcut for your Chrome browser.
· Right-click on your Chrome browser shortcut and select Properties.
· On the Shortcut tab, edit the Target field, adding the following parameter to the end of the existing value:
--auth-server-whitelist="hostname.company.com"
where hostname.company.com is the hostname and domain of the server hosting the OneLogin IWA. The URL must match exactly.
Select OK to confirm your settings.
Firefox - Make sure that the configuration has been configured in HTTPS mode to avoid a user transition warning.
In the address bar, enter "about:config".
If you see "This might void your warranty!" click "I'll be careful, I promise!"
On the configuration page, go to the network.negotiate-auth.trusted.uris and network.automatic-ntlm-auth.trusted-uris preference fields, double-click them, and enter the hostname of the OneLogin IWA server(s). You can enter multiple values separated by a comma, if two or more server instances are deployed.
If you are not entering the fully qualified domain name (FQDN) of your host servers, you will need to toggle the values network.automatic-ntlm-auth.allow-non-fqdn and network.negotiate-auth.allow-non-fqdn to true, by selecting and right-clicking the Value column for each and changing the value to True.
