Force Kerberos Authentication on company Intranet Site

hkabik
Valued Contributor

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!

25 REPLIES 25

bentoms
Honored Contributor III
Honored Contributor III

@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
Honored Contributor II
Honored Contributor II

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
Valued Contributor

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
Honored Contributor III
Honored Contributor III

@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
Contributor

@bentoms

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

hkabik
Valued Contributor

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
Contributor II

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
Valued Contributor

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
Contributor II

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
Valued Contributor

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
Valued Contributor

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

jarednichols
Honored Contributor

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

psmac
New Contributor III
New Contributor III

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
Honored Contributor II
Honored Contributor II

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
New Contributor II

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
New Contributor

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
New Contributor II

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
Honored Contributor III
Honored Contributor III

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

cddwyer
Contributor

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
Contributor

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
Valued Contributor II

@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
Contributor

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.

Hey bcbackes,

Did you ever get this to work? 

jianwei
New Contributor

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

MS2020
New Contributor II

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