What are you using in lieu of AD binding?

[john_sherrod]

Apple's been recommending moving away from AD binding for years now, but for a variety of reasons we've still been using it. So I wanted to ask the Jamf Nation community what you're using instead of AD binding? Or if you are still binding, what's keeping you there? I've been experimenting with Apple's Kerberos Single Sign-On Extension and curious how many people are using that as well. Thanks in advance for the communication and feedback!

[awoodbury]

We are using NoMAD and NoMAD Login.

[bcrockett]

Jamf connet 

[mainelysteve]

We stopped binding back in 2015 using NoMAD as the means to ensure resources controlled by AD user membership were still available. We started using the Kerberos SSO extension with any machine that shipped out with Catalina and have been doing so since then. Can't say anything negative here as none came about with this change. It was just a matter of user education and then everything flowed nicely.

It's worth noting that we don't deploy or use AD client certificates for radius or the like so my experience may be vastly different than someone else with far greater security controls in place that still require binding.

[Tribruin]

Jamf Connect

[sdagley]

We use local accounts with the Kerberos Single Sign-On Extension to synchronize the local account password with AD and generate Kerberos tickets. We also bind to AD for the sole reason of making ADFS share access work better (better being a relative term), and if it weren't for that we'd definitely drop AD binding for Macs.

[john_sherrod]

Can you tell me more about the ADFS issue?

[sdagley]

@john_sherrod I can't find the reference now, and it's been a few years since I found it so I can't quote verbatim, but the gist of it was that if your org makes use of ADFS file shares then having a Mac be AD joined makes those shares easier to deal with. I don't know that's entirely true because we do see issues with ADFS shares even for AD bound Macs - #1 would be _very_ sure to use the server(s) FQDN when setting up an ADFS share. Windows doesn't seem to care but it's been my experience that macOS does.

[john_sherrod]

Gotcha. Thanks!

[sdagley]

@john_sherrod The following Apple support article was mentioned today on the MacAdmins Slack, and has a good explanation of why binding helps with DFS (which I was was incorrectly calling ADFS):

 https://support.apple.com/guide/deployment/integrate-macos-with-active-directory-depd1a7cad1f/1/web/...

It includes the following tip which would indicate binding is not actually required if your DFS shares are configured properly:

You can access and traverse DFS shares without binding to Active Directory if the DFS environment is configured to use fully qualified domain names (FQDNs) in referrals. As long as the Mac can resolve the hostnames of the appropriate servers, connectivity succeeds without needing to be bound to the directory.

[john_sherrod]

Thanks for sharing! That's really helpful. I verified that our network shares are set up to take advantage of this.

[sdagley]

You might want to verify that. Our standard for DFS shares calls for FQDN for all referrals, but we often find "lazy" shares were created that simply used a hostname, and some that mixed the two.

[sdamiano]

I have done everything from binding, jamf connect, apple enterprise connect (rip), and also, nothing. 

Honestly? AD binding is a hard sell. Credential syncing to the machine is also a hard sell. Why? Because when you're handling access to resources via a cloud IDP like Okta, and if you have the ability to instantly and remotely lock a machine using Jamf, why do you _need_ to sync the IDP credentials to the machine? 

[john_sherrod]

I'm appreciating all of these answers and perspectives! Please keep them coming.

[cbrewer]

Unpopular opinion: If local AD is your identity source, keep using AD binding until macOS includes something that actually replaces it. Personally, I'm hoping they allow login via a Managed Apple ID before too long. AD binding is still supported and still works about as well as it ever did in the past. You can also combine it with kerberos extensions for better functionality.

[john_sherrod]

I think that's a perfectly valid opinion! And honestly the "if it ain't broke, don't fix it" mentality has kept us binding for as long as we have been. I think part of what's promoting me to consider other options is that, particularly in the early betas of Big Sur, there were a lot of issues with binding. Couple that with the fact that the language Apple uses now is to refer to it as "legacy, not deprecated." I think given that they're recommending we stop binding I'd like to get ahead of some potential future in which it's just not part of macOS any more.

[sdagley]

@cbrewer Are you actually using AD bound Macs with mobile accounts? Not that I pay a lot of attention to discussions I come across that mention that configuration, but I definitely get the sense from them that even on macOS Monterey "stabie" is not an adjective usually applied.

[cbrewer]

Yes. For shared use machines, it's still the best way go in my opinion. Also, User-level MDM only works for multiple users if you are using mobile accounts. That said, I'll be happy to move away from it when there is a better, supported alternative. I am interested to see what comes of Jamf's upcoming updates to NoMAD login. But I also think Apple just needs to allow orgs to sign in with a Managed Apple ID from the login window.

[john_sherrod]

Could you expand on this? "Also, User-level MDM only works for multiple users if you are using mobile accounts."

[cbrewer]

If you want to apply configuration profiles at the user level, you run into some issues if you have multiple local accounts. For Mobile accounts, it just works.

https://docs.jamf.com/10.35.0/jamf-pro/documentation/MDM-Enabled_Local_User_Accounts.html

• Network and mobile user accounts are MDM-enabled by default in Jamf Pro, no matter the enrollment method that was used.

• For computers with macOS 10.12 or later, only one local user account can be MDM-enabled on a computer at a time. If a second local user account becomes MDM-enabled on the computer, the first local user account will no longer be MDM-enabled.

[john_sherrod]

Thanks! That's really interesting. I don't think we've ever used user-level configuration profiles here, but that's good to know.

[sdagley]

+100 on the MAID request. I can't believe Apple has yet to provide a Configuration Profile setting that would allow limiting Apple ID sign in to a specified list of domains.

[mm2270]

I'm not sure Apple will ever completely remove AD binding from macOS, as long as Microsoft continues to support it in enterprises. But they surely won't put a lot of effort into making it work well on macOS. We've already seen this for at least the last decade as they've pushed clients away from it.

For our part, we're still binding, but it's a legacy thing that will be hard to completely shed, at least where I work. That said, we no longer create cached AD mobile accounts on our Macs. We use the Apple SSO plug-in with local accounts to sync the passwords. Using cached AD mobile accounts these days is an exercise in frustration, so I would certainly not use those. Too many password issues that cause headaches.

[john_sherrod]

What specifically is keeping you binding as a practice if you're using the SSO plugin? Just curious.

[mm2270]

Not much honestly. It's just a legacy thing. We're mostly a Windows environment with < 100 Macs, and I think back when the Mac environment was first started, it was assumed to use as many of the features from their Windows counterparts as possible.

One of these days I will push to stop AD binding, since there isn't much real use for it now with the SSO plug-in. But change is hard in this organization, so it will take time, and support for macOS is just a little over a year old now, so we're not quite at the point of making this change yet.

[john_sherrod]

Gotcha. Thanks!