Force Kerberos Authentication on company Intranet Site

[hkabik]

Hey all,

So I'm trying to wrap my head around an issue we have in this environment. All of our PC's are able to get onto our company intranet site without re-authenticating.

But the AD bound Macs all require us to enter our AD credentials to get on to the sites, all browsers effected.

I contacted the site admin and he swears up an down the Kerberos authentication is setup on the site, but the Macs don't appear to be taking advantage of it. If I check via klist, a valid kerberos ticket does exist. But no matter what, I am prompted to authenticate to the site.

Is there a setting or a way for me to force the Mac to offer it's Kerberos ticket as an authentication method? Is there some other feature the site admin needs to enable for us to authenticate via Kerberos?

It's really driving me batty.

Thanks in advance!

[bentoms]

@hkabik it not only needs to be enabled, but set as the 1st authentication attempt on the server.

So kerberos/claims based auth, then NTLM

[davidacland]

I've spent some time on this issue and it can differ a lot depending on the browser versions and the server backend. Are you using IIS or something else?

[hkabik]

It's a Sharepoint site so I assume IIS. I'll follow up on Monday though.

Mainly 10.9 machines, mainly Safari and Firefox.

[bentoms]

@hkabik yep. Claims based auth needs to be top of the list.

Safari should work automagically, Firefox is a PITA.. But also not supported by MS for sharepoint on a Mac IIRC.. So might be better off just with Safari.

[Poseiden951]

@bentoms

I'll have to ask our Sharepoint person if kerberos auth comes first. All browsers ask me to authenticate.

[hkabik]

So I'll resurrect this since it's still driving me crazy.

We have verified that Kerberos is first but now when users try to connect, nothing happens. No prompt for credentials, no nothing. It just tries for a while then gives up.

Logs show:

com.apple.WebKit.Networking[282]: Stream 0x0... is sending an event before being opened

Over and over and over...

I have verified we have a valid Kerberos Key, and we are set to authenticate to kerberos first on their end.

This behavior is only in safari by the way, if I try with firefox or chrome, I get asked for authentication and then can login normally.

Anyone ever seen this?

[maxbehr]

Couple of things. First in my experience Chrome and Firefox are not configured by default to do kerberos authentication. First for Chrome three settings have to be set (I do this via a configuration profile More info here
)

<key>AuthNegotiateDelegateWhitelist</key>
    <string>*ndu.edu</string>
    <key>AuthSchemes</key>
    <string>basic,digest,ntlm,negotiate</string>
    <key>AuthServerWhitelist</key>
    <string>*ndu.edu</string>

Substitute your appropriate domain

In firefox the setting

"network.negotiate-auth.trusted-uris", "ndu.edu"

Again substitute your domain.

Once you've made those changes give it a try in one of those browsers. I find that sharepoint, at least in my environment, works extremely poorly with Safari. Chrome is a better choice. If kerberos auth is still not working, then the problem would seem to be on the Sharepoint side. IIS needs to be configured to allow negotiate (kerberos) authentication. This is not a default settings so many IIS admins never bother to change it since windows will do SSO with NTLM (windows authentication).

[hkabik]

So I have kerberos authenticating in Firefox using the instructions above. still no go in Safari, endlessly errors with:

com.apple.WebKit.Networking[282]: Stream 0x0... is sending an event before being opened

in the logs and gives up.

[maxbehr]

What version of Safari and what OS are you using?

Another question…when you connect with Safari are you getting a service principal for the sharepoint server? Test by first destroying any kerberos tickets kdestroy, then a kinit to get your Ticket Granting Ticket, then connect with Safari followed by a klist at the command line. You should see a service principal that looks like HTTP/fqdn@DOMAIN_NAME I'm curious if Safari is able to get the service principal and then failing to connect or just a flat connection failure all around.

[hkabik]

principal is:

krbtgt/domain name@domain name

No http principal.

I also noticed I have no krb5.conf in /etc/... shouldn't that be there?

[hkabik]

So it seems our BlueCoat Cloud Service Web Proxy may have something to do with this.

[jarednichols]

Wouldn't be the first time BlueCoat broke something...

[psmac]

Sorry to dig this back up, but i'm hitting the same issue with Safari 9 not playing ball behind a BlueCoat proxy. Chrome/Firefox are fine. Is this just a dead duck or is there anything that can be done to get it working?

[davidacland]

Each time I get involved in troubleshooting Intranet / proxy issues it changes. It seems that each version of Safari and/or the Mac OS, the behaviour is different. We've also seen different versions of web servers, IIS and Apache influencing the behaviour.

The key thing is what user and service principle is being sent to the authentication server, are they in the right format etc. Although there is a naming convention that should be followed, I wouldn't be surprised if each browser did something different.

I would start of looking at the logs on the auth server as a starting point.

[jnice22]

Same behavior and same errors with OS 10.11.6, Safari, Chrome, Firefox. - Sharepoint site. The interesting thing is after configuring the trusts in Chrome I am able to get the HTTP/websso. fqdn but only after I log in to the site.
I am also able to get SSO to work with our proxy. I get the same errors as hkabik in my logs. com.apple.WebKit.Networking[8987]: Stream 0x7f8786233660 is sending an event before being opened.... Safari will always

We use a different proxy setup but with the same result. Has anyone come up with a solution?
I am going to take davidacland's advice and start with the authserver logs.

jamfNation... Makes me feel like I'm not alone.

[softwareregwsc]

Hi guys,

I am experiencing the exact same issue in our company intranet, even down to the same errors that hkabik is having.
Did either jnice22 or hkabik ever get this to work?

Thanks for your help.

[NobleK]

Hm. We're just getting started with Jamf as our MDM and in test we're seeing the same issues from our environment. Anyone had any luck with a fix from Safari?

It would seem that asking Safari to save the password works between launches of the software. Just curious to know if there is a fix so the user is never prompted by this when accessing intranet (SharePoint based) sites.

Thanks. :-)

[bentoms]

@NobleK Kerberise Sharepoint.. or.. in SharePoint speak.. "enable claims based authentication"

[cddwyer]

Have you tried using something like NoMAD for Kerberos authentication?

See: https://gitlab.com/Mactroll/NoMAD

I have used it for single sing on services with AD bound Macs before and it's worked pretty well. However, it supports Macs on 10.10 and above, another reason for you to upgrade beyond 10.9.

[bcbackes]

Did anyone get this to work? I've been trying to figure this out. Every time I open Chrome, Safari, or, Firefox I get prompted for my credentials for our Intranet site. Not sure what I'm missing or doing wrong. I've tried to setup a configuration profile for Chrome and add my domain in there for Auth​Negotiate​Delegate​Whitelist and Auth​Server​Whitelist. Still nothing works.

[cbrewer]

@bcbackes Are you using ADFS? ADFS has a rule set for which browsers it uses windows authentication for and which browsers it uses forms authentication for. The setting is WIASupportUserAgents.

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-browser-wi...

Here is what I'm currently using:
Set-ADFSProperties -WIASupportedUserAgents @("MSAuthHost/1.0/In-Domain", "MSIE 6.0", "MSIE 7.0", "MSIE 8.0", "MSIE 9.0", "MSIE 10.0", "Trident/7.0", "MSIPC", "Windows Rights Management Client", "MS_WorkFoldersClient", "Mozilla/5.0 (Macintosh", "Mozilla/5.0 (Windows NT")

[bcbackes]

Thanks @cbrewer . We have it working on our Windows devices correctly, just not in my Mac environment. I'm not sure what is preventing it on the Mac side. We are bound to AD and are using mobile accounts on Macs via our AD credentials.

[Gilenium]

Hey bcbackes,

Did you ever get this to work? 

[jianwei]

Hi How was the problem solved later? Now there is SSO extension, has the problem been solved? Thank you

[MS2020]

Is anyone having this same issue still with blue coat and kerberos