Are Chrome, Firefox or Safari on the SiteMinder roadmap to be supported when using IWA?

[Anon Anon]

With the increase in mobile developers the number of MAC operating systems in the environment are growing.  Is there any talk of a solution for IWA on MAC operating systems?

[Anon Anon]

Since IWA is a native Microsoft Windows/Internet Explorer authentication function, wouldn't this depend more on the browsers themselves, more so than SiteMinder (SSO)?

 

Firefox is capable of IWA authentication today on Windows OS, but error handling isn't as good as it is with IE, at least from my experience.

 

[Chris Bertagnolli]

IWA certainly can work on Mac if they're properly joined to the domain, but as Mike mentioned it depends on the browser.

 

Chrome/Firefox work with no problems if configured properly. Safari can be problematic due to lack of Kerberos delegation support, which is an Apple issue more than SiteMinder; so far as I'm aware it still doesn't support that and has been in their court now for years with no movement.

[Anon Anon]

Perfect, that makes sense.  Is there a KB article on this from CA?

[Anon Anon]

Any idea of the settings within Chrome for example?

[Chris Bertagnolli]

SM 12.52 - Kerberos in Chrome and Safari

 

Can take a look there.

 

-------------------------

  Ok, so the issue with Chrome was that Delegation (--auth-negotiate-delegate-whitelist) was not set, but the normal server-whitelist only (--auth-server-whitelist). This allowed IIS/OpenSSO to function but not SiteMinder.

 

  For Windows the following worked:

  "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --auth-server-whitelist="*.mykerb.com" --auth-negotiate-delegate-whitelist="*.mykerb.com"

 

  For Mac:

  open -n -a 'Google Chrome.app' --args --auth-server-whitelist="*.mykerb.com" --auth-negotiate-delegate-whitelist="*.mykerb.com"

-------------------------

 

I'm not certain off the top of my head how the desktop group got that pushed / updated for all the systems, but basically getting it to launch with both delegation + whitelist is what worked for us.

 

For Firefox, a plugin was created that could be pushed or users could manually go download/install that set the necessary configurations. For example:

 

network.automatic-ntlm-auth.trusted-uris = https://mykerb.com

network.negotiate-auth.trusted-uris = https://mykerb.com

 

Note: the "https://" had to be used due to a bug we had with Mac Kerberos, introduced with 10.8 if I recall, where the base or wildcard was causing it to fail (so something like *.mykerb.com would fail but https://mykerb.com worked). It only seemed to be with Firefox + Mac only, didn't seem to be an issue with Windows.

One fine note: This is all validated with Kerberos only. No version of NTLM was confirmed/verified.

[Anon Anon]

From what you have described it seems as though Firefox is more friendly to IWA on a MAC than Chrome.  I just tried the Chrome command above to MAC and it was not successful.

[Anon Anon]

One more question, in our currently deployment of IWA it is using NTML to authenticate with AD.  Based on what is said in this post, this needs to be changed to Kerberos in order to work with Firefox/Chrome on a MAC.  Can you confirm.

[Chris Bertagnolli]

From a Microsoft and security stand-point Kerberos is the protocol to use. While NTLM works in cases, and has some limited uses, it is just not as robust and secure. So personally, my opinion is to always utilize Kerberos if possible. But I can't speak for CA or other folks experience, but we only utilize Kerberos for IWA here.

 

Others may have used NTLM with Mac though and gotten it working, let's see if they will chime in. Unfortunately I just don't have much experience with NTLM on Mac OS + SiteMinder. Although not sure why it wouldn't work....

 

What Mac OS and browser version is being used for testing? And I'm assuming the same setup you have works on the Windows machines? Any specific details on the issues / errors in SiteMinder that you can provide which might help someone better understand the specific problem?

 

Wish I had more for ya. Hopefully one of the community guru's will speak up with some words of wisdom .

[Anon Anon]

Thanks for your reply.  I am testing on a MAC OS 10.9.5 machine with one of the newer versions of Chrome.  I don't get an error, but I am prompted for a ID/PW when accessing a IWA protected link.

[Chris Bertagnolli]

Something that has helped us with general troubleshooting is having two reference systems. One application on Windows / IIS using Windows Authentication (no SiteMinder) and another that is protected with SiteMinder. This way, if you go to the standard non-SM one and it also doesn't work then can narrow in on client or browser configs / domain; once that is working then retry SM with the same setup.

 

Hopefully not muddying the waters too much, but just doing a bit of looking on my break, are all things set properly? One that was mentioned that I'm not too familiar with is this one:

 

--auth-schemes="digest,ntlm,negotiate"

Looking at Firefox, with v30 NTLMv2 is not supported for non-Windows platforms and NTLMv1 requires an extra setting - https://developer.mozilla.org/en-US/Firefox/Releases/30/Site_Compatibility#Security"

--------------------------

If you encounter any problems on Firefox 30 or later, you can manually enable NTLMv1 using a preference. Note that NTLMv2 is not supported on non-Windows platforms, so OS X and Linux users have to toggle the preference to continue using NTLMv1 as below, though the NTLM auth support on non-Windows platforms is considered deprecated.

 

How to enable NTLMv1: type about:config in the location bar, click the "I'll be careful" button, findnetwork.negotiate-auth.allow-insecure-ntlm-v1, double-click on it to change the value to true.

 

Another workaroud here is using Firefox 24 ESR that still enables the NTLMv1 auth."

--------------------------

 

Haven't looked through Chrome's notes to see if they have any gotchas for NTLM support on non-Windows, but probably worth a look. A lot of this stuff ends up being client/browser support more so than SM specific.

 

Really though if you want to maintain current with security updates and supported capabilities, going Kerberos is probably worth a look. Doesn't necessarily answer your NTLM problem, but for authentication it's much better.

[Anon Anon]

Thanks for your help.

[Anon Anon]

Is the ability to leverage IWA on a MAC OS something that can be proposed as a use case that can be supported in the future?  I realize that IWA is Integrated Windows Authentication, but with more and more MAC devices entering the environment, I would like to provide the functionality to them.

[Chris Bertagnolli]

Given the current info, I don't think there's anything CA can inherently do for it? It's really a browser/OS support thing more so than a CA support issue - since it does work with NTLM and Kerberos when the components using it support it.

 

If the OS and web browsers are configured to support the required mechanism then SiteMinder shouldn't have an issue. Problems crop up when either of those pieces don't support it.

 

Kerberos definitely works with Firefox/Chrome on Mac and really is what should be used from a security and future supportability standpoint. Just my two cents, but moving to a non-outdated and secure authentication mechanism is a better investment than trying to support old less-secure methods. With proper SPNs and constrained delegation it's a much better system. The only time NTLM should even be considered is in very specific use cases that Kerberos can't handle. But within the context of SSO using any AM product (SiteMinder, OAM,...so on), Kerberos with fall-through to a log in form on failure, if necessary, is the way to go in my mind.

 

-----------------------------

 

Were you able to try the setting in Firefox to enable NTLM v1 to see if that worked for that browser?

[Anon Anon]

Thanks for the reply, I did try the setting on Firefox but was not able to get it to work.  I do agree that the first step is to make the switch to Kerberos.