Skip to content →

Kerberos SSO Extensions in an Enterprise environment

Last updated on 8. November 2021

Kerberos Single Sign-on Extension only for SSO tickets?

The Kerberos single sign-on (SSO) extension start with macOS Catalina 10.15. In the last years Apple was always great in finding cool names for products but in this case the product name is a very bad marketing. This article only covers the macOS side of the Kerberos SSO extension.

With Kerberos SSO we are able to:

  • Sync local macOS user account passwords with a active directory
  • SSO log in users into native apps
  • Provide Kerberos tickets for local non AD bound machines

Scope

  • macOS Catalina
  • macOS Big Sur

Features

Kerberos SupportmacOS > 10.15
ldapsearchmacOS > 10.15
Password changesmacOS > 10.15
Password syncmacOS > 10.15
Terminal supportmacOS > 10.15app-sso
Script TriggermacOS > 10.15additional launch agent
Share MountingmacOS > 10.15additional launch agent

Requirements

The Kerberos SSO Extension requires a mobile device management system (MDM) to deploy the configuration on a macOS system. In my case I use JAMF Pro to deploy this configuration profile.

  • Microsoft Windows Active Directory Environment with version 2008 R2 or later (Azure is not supported)
  • MDM Server
  • macOS Clients with version 10.15 or greater

My scenario

  1. Jamf Pro MDM Server (Cloud or reachable outside from my enterprise network)
  2. Active Directory Server (only reachable in the enterprise network)
  3. DEP enabled client machines and activated in my JAMF Pro Prestage Enrollment profile.

What I want to achieve with this scenario

  1. DEP client enrollment (independent of the company network)
  2. Local user accounts ( with credentials from the Active Directory)
  3. Keep local password in sync with AD.
  4. Deny local password change.
  5. Force users to use the Kerberos SSO Extension
  6. DNS Hostname update if the client is enterprise network or VPN connected.
  7. Deploy 802.1X Computer certificates with JAMF Pro ADCS Connector

How can you create a local user account based on the Active Directory data if it is only accessible from the corporate network?

The solution for this also comes in this case from our client management solution. With DEP enrolment we have the possibility to request authentication during the DEP enrolment (PreStage Enrollments). The requested data is sent to the client management server via https and checked there. If the login data is correct, the setup assistant creates a local user account with the Active Directory short name and password.

It is important that the Jamf Pro server can communicate with the Active Directory. In a cluster environment, only the master must be able to connect to the AD.

JAMF Pro -> PreStage Enrollments -> myProfile -> General

In addition the checkbox “Pre-fill primary account information” and “Lock primary account information” must be selected in the account settings.

JAMF Pro -> PreStage Enrollments -> myProfile -> Account Settings

With these settings we already get our local account based on the login data used.
From the user’s point of view, this process looks like this:

It is good to know that different behaviour between ARM and Intel can already be seen here. If you use an Intel device, the Secure Token is immediately created for the account. With ARM (M1) devices, the Secure Token is only activated in the login window when you log in for the first time. 

Now our actual Kerberos SSO profile comes into play. In the current state, the user can log in with his AD password, but as soon as it is changed, he has to work with two passwords. In addition, we cannot check whether the user complies with the password policy.

JAMF Pro -> Configuration Profiles -> new Profile -> General

JAMF Pro -> Configuration Profiles -> new Profile -> Single Sign On Extension

Don’t forget the scope on the corresponding devices. The easiest way is to activate the profile in the Prestage Enrollment Profile.


After the successful profile installation on the client, you should see a new icon in the menubar.

As soon as the client is connected to the company network (whether VPN, WiFi or wired), the Kerberos SSO extension opens on the client.

Now the Kerberos SSO Extensions wants you to log in to the Active Directory. If you select cancel here, the pop-up will appear again at the next connect or network change event.

After the successful authentication, the Kerberos SSO Extension will ask us if we want to allow automatically sign in from now. This does not mean that the user account is automatically logged in. This message is slightly misleading and can also be misunderstood. It only means that the Kerberos SSO extension logs on to the AD as soon as the company network is accessible.

In the last step, the local password is synchronised with the Active Directory password. In our case, the passwords are the same because we created a new account using the Active Directory data.

If you click on cancel here, you will be informed that your passwords may no longer be synchronised. In addition, the message appears again when you reconnect to the company network.

KerberosMenuExtra now shows in the menu that we are logged in and may also show the password expire date.


With this configuration we have already achieved that the client has a local account and that the password is keep in sync with the Active Directory. When changing the password, a Kerberos SSO popup appears and requires a new login. The settings for the password synchronisation can be found in our Kerberos SSO Profile -> Sign Sign On Extension -> Replication time

Published in KerberosSSO macOS Storyboard

2 Comments

  1. Chris Waldrip Chris Waldrip

    Is there any way to prevent Kerberos SSO from popping up for some accounts on a machine?

    We use a generic (non-admin) account as a ‘guest’ account when needed. The best I can do is run a launchdaemon that checks for and kills the kerberos SSO process if the current logged in user is the generic account.

  2. Hey Chris, I am not aware that there is an exception option. It also collides a bit with the actual idea of keeping the accounts in sync with the AD. The idea with the launchdaemon is not very nice but probably the only one..

Leave a Reply to Chris Waldrip Cancel reply

Your email address will not be published. Required fields are marked *