Mac Kerberos SSO and VPN: compare the two sign-in paths

Two mechanisms produce the same friendly result on a Mac and behave nothing alike underneath. One obtains Kerberos tickets through an SSO extension and hands them to participating applications. The other keeps a browser session with an identity provider and lets web applications honour it. They differ in what they need on the network, how long their credentials last, and what happens the moment the tunnel drops.

Two mechanisms, one login screen

The ticket-based path depends on a Kerberos domain, a key distribution centre and a clock that agrees with it. The browser path depends on a reachable identity provider, a cookie or token, and an application that trusts that issuer. Both can be configured to start at login, which is why they get mistaken for the same feature. Applications decide which of the two they accept, and a Mac can legitimately run both at once.

Compare them by asking what the application checks when a user opens it. A file service joined to the Kerberos domain wants a service ticket, and no amount of browser session will satisfy it. A web application behind a modern identity provider wants that provider's token and ignores the Kerberos ticket entirely. Once you know which check happens, the deployment questions become specific instead of general.

What the Kerberos extension needs on the wire

Apple's Kerberos SSO extension guide describes native Active Directory authentication with proactive ticket acquisition, paired with local accounts rather than a domain binding. What it cannot do is invent a path to the domain controllers. The Mac needs a resolver that answers the Kerberos service records and a route that reaches them through the approved tunnel. A profile that installs cleanly proves nothing until the domain can actually be discovered from the client.

Check discovery before you check credentials: the SRV records for the Kerberos domain must resolve, and the addresses they return must be reachable once the VPN is up. Time matters as much as reachability, because Kerberos rejects requests from a clock that has drifted beyond its tolerance, and the error it produces looks like an authentication failure. A Mac that cannot reach a time source while the tunnel is down will fail again the moment it returns. Fix the clock source as part of the deployment rather than as an incident response.

klist
sudo sntp -sS time.apple.com

Per-app VPN decides whether the extension can work

A full tunnel routes everything and hides this problem. A per-app configuration routes only the applications named in the VPN profile, and the SSO extension is itself a process that needs the network to fetch tickets. If it is not in the mapping, local login succeeds, the tunnel comes up for the browser, and ticket acquisition still fails.

Read the VPN configuration and list every application it is meant to cover, then add the SSO component through the documented mapping mechanism rather than by guessing a bundle identifier. Mapping the visible client and not the component behind it is the classic version of this mistake. Keep the mapping in the same managed profile as the extension, so a change to one cannot silently invalidate the other. Test with a user who has never signed in on that Mac, because a cached ticket can make a broken path look healthy, then test again after a password change.

A browser identity session is a different contract

A browser session has no Kerberos domain, no service ticket and no clock tolerance in the Kerberos sense. It has an issuer, a token lifetime and a refresh path, and its failure modes are redirects that never complete and cookies that a private window discards. Treating it as a replacement for the ticket path is safe only where the application itself accepts that issuer. Copying an authentication response from the VPN portal into an unrelated service is not integration, however convenient the shortcut looks.

When both mechanisms are deployed, document which applications use which, because the support conversation depends on it. A user who reports being signed in but unable to open a file share is describing two systems, and the answer is that the ticket path never ran. A user who can open the share but not the intranet portal is describing the reverse, and naming the mechanism in the ticket saves a round of questions.

Walk the sequence, not the parts

Walk the whole chain with an ordinary enrolled account: local login, tunnel, ticket acquisition, then one real operation against a service. Repeat it after the tunnel reconnects and after a deliberate password change, because each of those cases exercises a different part of the lifetime logic. Each stage passing on its own is not the same as the chain working. The chain is what the user experiences, and it is what the acceptance case has to cover.

Record the profile owner, the VPN authentication method, the domain discovery path and the extension's application mapping in one place. That record is what makes the flow reproducible by somebody who did not build it. Then check the failure you are most likely to meet, an expired ticket while the tunnel is down, and confirm the client recovers without a reboot, because a deployment that only works from a cold start is not finished.

Note the owner of each stage as well, since a Kerberos domain nobody maintains becomes a stale one. A chain nobody can describe is a chain nobody can debug.