Evolving and Elevating your SSO Strategy to Include MacOS

Hello everyone!

For those who have read some of my articles over the last year or two, you know that I have been a bit of a mad scientist with VMWare Identity Manager. Some people strongly believe I have my VMWare Pom-Poms out on a daily basis… Give me a V! Give me a M! blah blah… you know 🙂

The truth is that I am platform agnostic. I like shit that actually works. Most of the gaps that the artist formerly known as AirWatch has is on the support side, but I don’t need to tell any of their customers that. One area that they have not done a great job on is MacOS. I hate to say that, but it’s absolutely true.  You have a number of issues starting with a few knowledge gaps, MDM profiles that don’t actually work (which is fine because I’m really good at shell), some failures to be ready for new OS like KEXTs/TCC profiles. The truth is that I can work around all of those issues at the end of the day, but the one that I have been unable to work through is their substandard identity strategy for MacOS.

MacOS Kerberos Basics

So let’s start with the basics of Kerberos on Mac as that is always the best place to start because I don’t (contrary to popular belief) just yell and complain because something is hard. MacOS’ tickets/kerberos are traditionally very complicated and confusing.

You typically, want to configure three files to make things work solidly all in our friend /etc with the first two being found in PAM.D (Pluggable Authentication Modules) and krb5.conf aka the Kerberos Config File found in /etc.

  1. authorizationScreen Shot 2018-11-24 at 6.27.21 PM.png
  2. screensaverScreen Shot 2018-11-24 at 6.28.44 PM.png
  3. krb5.conf (Follow the link!)

Now that you have your framework, I suggest checking out some really great shell scripts and daemons that make this even cleaner on my GitHub. For example one of these will automatically kill all kerberos tickets on reboot.

You can check out the Ticket Viewer from the Keychain Access Menu to see the status of your tickets. Typically after you connect to VPN or whatever, Outlook will connect to LDAP and generate a Kerberos ticket. You can see a heavily redacted example below.

Screen Shot 2018-11-24 at 6.17.08 PM.png

The problem that you typically have is that their GUI is a bunch of smoke and mirrors. You “think” you have a kerberos ticket sometimes and it will just bomb out. Its a two-fold issue typically: (1) VMWare Identity Manager doesn’t really care about Macs and doesn’t work like most client-server exchanges would like Outlook (and actually generate a Kerberos ticket) and (2) sometimes you don’t actually have a valid ticket despite thinking that you would.

The reality is that MacOS is REALLY bad at Kerberos because DUH its a Mac! and VIDM SHOULD be generating its own Kerberos ticket and not trying to be a Kerberos Pirate. So, you can either have your Execs yelling at you or do things the right way. Yeah I love Kerberos as much as anyone being a legitimate expert in it, but its just not the right solution. The RIGHT solution is Certificate-Based Authentication!

Implementing Certificate-Based Authentication in a VIDM Environment

You would think this is the worst thing ever to try to achieve, but it’s actually not that bad. The browser-implementation is the worst part of it. The good news is that Mobile Jon has figured it out and made it super clean. You need to handle three parts (1) augment the standard machine-based certificate you are likely using for EAP-TLS and VPN, (2) configure the CBA handler in VIDM, and (3) implement some creative scripting to make a modern browser like Chrome have a seamless experience when accessing sites over SSO.

Augmenting the Machine-Based Certificate

Most times, your standard certificate for WiFi will have the following:

  • Subject Name: Hostname of the PC e.g. JonPC-1.test.com
  • Subject Alternative Name: UPN that matches the Subject Name with a $ injected in there like JonPC-1$@test.com

You will just add another Subject Alternative Name for email with the user’s email address, which is easily done in AirWatch or via your own CA depending on how you do it. For example in AirWatch it looks like this:

Screen Shot 2018-11-24 at 6.54.19 PM.png

Configuring the CBA Handler in VMWare Identity Manager

You will start by logging into VIDM and going to IAM > Auth Methods and edit the Certificate method.

The settings below are required:

  • Click Required
  • Upload the Root and Intermediate Certs for the Corporate Certificate you will be using
  • Set it to use email as the UID and ask it to validate the UPN format.

Screen Shot 2018-11-24 at 8.35.44 PMScreen Shot 2018-11-24 at 8.36.08 PM

Outside of these settings, the rest will depend on your environment. Once you have completed your setup, I would recommend a hybrid policy like this:

Screen Shot 2018-11-24 at 8.49.00 PM.png

Once completed, you now have a robust SSO strategy built for your environment, but you are NOT quite there yet. Browsers do suck after all!

Setting up Chrome to Perform Seamless SSO using Client Certificates

This was one of the least enjoyable things I’ve done in awhile, but eventually I was able to figure it out. The way that I write Google Chrome preference configuration is shell script/LaunchAgent. I’ll provide you with the example of each of these, which if you implement exactly like this it works like a charm.

The beauty of the LaunchAgent is that when the user logs in, it will run the script which basically creates a Chrome config file that will setup Chrome for Kerberos and tell it to use the client certificate automatically for the VMWare Identity Manager CBA Endpoint.

Shell Script

Screen Shot 2018-11-24 at 9.19.49 PM.png

Chrome Daemon

Screen Shot 2018-11-24 at 9.20.54 PM.png

In Closing

So this article was mostly just a bunch of technical findings so let me sum it up for you. I’m not known for being delicate so no reason to change that up now. Basically, most people in the consulting/managed services side tend to stay in their lane. They will help you setup Kerberos for VIDM or whatever your SSO provider is, but they don’t understand the intricacies of their operating systems. The reality is that Kerberos is NOT the answer for SSO on MacOS. Anyone who tells you differently is completely wrong. I don’t care if you have Enterprise Connect, Nomad, JAMF, Hello Kitty SSO, or if you blackmailed Kerberos himself.

Leveraging Certificate-Based Authentication is exponentially more powerful on MacOS and does not create much more overhead for you. If you own a IDP that is even half way decent, it should be able to support workflows where it uses certificates for MacOS and still does Kerberos for Windows. If it doesn’t, you should re-evaluate your SSO strategy. I can definitely help you with that as an expert in Identity and Access Management as shown in my VMWorld 2018 Session. As I always say, we are all in this together and if people aren’t helping you to think outside of the box then they are doing you a major disservice. Everything is perception and in today’s IT landscape you need to differentiate yourself from others by being a leader and not a follower.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s