Mac considerations for new Active Directory Forest and domain controllers

[mthoma]

More of a general "macOS playing nicely in a Microsoft environment" question:

If you were setting up a brand new AD Forest with new domain controllers in a mixed Windows and macOS environment, what Mac-specific AD requirements, features and nice-to-haves should be considered?

Macs would be bound to AD (not using Nomad or Jamf Connect) and AD accounts would be used to authenticate to almost everything: wireless, VPN, Windows shares, Sharepoint, Exchange and Skype for Business on-prem, PaperCut accounts, Jamf (through LDAP), CAS, etc.

[edickson]

If the Macs must be AD bound (and assuming you're not using any kind of SSO solution) the main issue you're going to run into is Macs losing their bind to AD. This would really only be discovered by users not able to change their AD password (again, assuming you have a password change policy in place) or when they attempt to VPN into the network and are unable to. This would prompt them to contact IT support and have their Mac re-bound to AD.

I'd actually advise going with Nomad or Jamf Connect and an SSO solution so Macs don't need to be bound to AD. This is going to make your users' lives (and any IT support personnel you may have) a lot easier. You can still require authentication to all the systems you mentioned as well.

[mm2270]

I'd actually advise going with Nomad or Jamf Connect and an SSO solution so Macs don't need to be bound to AD. This is going to make your users' lives (and any IT support personnel you may have) a lot easier. You can still require authentication to all the systems you mentioned as well.

I second this approach strongly. If you have any say in this process, or can convince those that do, I would advise not joining your Macs to AD and going with one of the account/password synchronization models mentioned above. You'll be in good company as many orgs are now moving or have moved to this approach, which really makes things a lot easier to manage. There was a time when joining to AD was the only viable option, but that isn't the case anymore.
Keeping Macs properly joined to AD is a pain in the neck, and you will find yourself spending time coming up with and maintaining detection and remediation mechanisms to get around the issues, rather than spending the time on more productive things.

[cbrewer]

You'll hear a lot of reasons to not bind a Mac to AD. It may be an unpopular view but it still works reasonably well and is fully supported. If you want multiple users from your AD domain to be able to login then binding to AD accomplishes that goal. As well, if you want to use 802.1x with computer level authentication, binding makes that easily doable.

Trust relationships between client and domain can certainly get broken but that's true for Windows clients as well. With Jamf, it's not too hard to setup some kind of extension attribute that checks the AD binding and reports back the status.

[RobertHammen]

I'm going to third the "don't bind to AD unless you absolutely need to". Particularly if you have laptops that 1) will leave the corporate network frequently, and 2) must be encrypted. Very easy to get into situations where the password to unlock the disk gets out of sync with the AD password. This is partially mitigated in 10.14.4, but not for everyone (i.e. in my environment, I'm required to disable the automatic login after preboot).

Taking a 30,000 foot view, what is it that you think you get by binding to AD? Macs don't respect GPO, the native AD plugin doesn't support fine-grained password policy, etc. I actually believe that the SSO extension for 10.15 is the beginning of the end of the native AD plugin. It might not disappear in 10.16 but I suspect its days are numbered. Frankly, AD binding/auth issues are quite common with new OS releases, and have been since forever.

If you've got a device enrolled in an MDM that is Internet-facing, you are probably in a better situation with respect to controlling/managing the device than you are in an on-premise, AD-bound environment.

Just my 2 cents.

[Taylor_Armstron]

Just another contrarian perspective... we've been binding to AD for well over 10 years, and so far I have never had a machine lose binding without some external cause. (hope I didn't just jinx myself!).

It works. Plain and simple. I see plenty of other issues, usually permissions or otherwise, but the bind itself is solid. FWIW, we've used native Mac OS and Centrify for binding over the years, authentication with CAC/PIV cards, and binding is one of the things I basically never worry about.

[cbrewer]

@RobertHammen

Who knows what Apple's actual plan is, but I think they'd lose a significant market share if they eliminated the ability for education environments to have shared use Macs where any AD user could sign in. Saying AD Binding's days are numbered without any proof isn't helping these kinds of discussions. If that unsubstantiated information gets spread around too much, it has the potential to negatively impact purchasing decisions in education.

I'm not saying they won't remove or change the AD plugin, but I don't like seeing the idea spread that we'll soon have a version of macOS that is similar to what we have now but with no built-in multi-user AD support.

[ammonsc]

I have to agree with @cbrewer here. There are plenty of places that not binding to AD is a show stopper and it would mean "No Mac For You" As much as there are issues if you are in a position to help setup the environment from the get go then go forth and do good.

[easyedc]

Historically we've been a binding .org. I've been working with our infosec to approve moving off AD binding and local accounts supported by Enterprise Connect and am about 1/2 through that transition. I will freely admit that almost all of my account-related headaches with end users have gone away with this move.

[jared_f]

I would move away from binding Macs that an individual user gets to AD. Use NOMAD (which is still free). We have run into issues with password resets and FV2 encryption on 1:1 Macs where we create mobile accounts.

In regards to labs, it is pretty much necessary to bind to AD.

I have a smart group setup to let me know if any of our Macs lose their AD bind and it emails me. It rarely happens, but has. We still bind via a configuration profile, so it is a relatively easy fix. I believe we prefer one domain controller in our domain, not sure if that really makes a difference.

A big issue I did run into was logins failing when to DCs fell out of sync. That was resolved rather fast though.

[larry_barrett]

Anyone want to share their EA to check for devices that lost their AD bind?

[anickless]

I will chime in here and say that we just recently rebuilt our forest and domain from scratch, AD binding is broken now and I don't know why. I will digress and state that schools rely on AD binding for at least students since you have so many logging in over a school year.

I still haven't figured out why my AD environment isn't working for logins, except on the same LAN as the FSMO, but I am sure I am just missing something simple.

[jared_f]

@anickless Binding is working fine on your LAN, but user's cannot login when they are off your LAN? Make sure you are creating mobile accounts. How many DCs in your environment?

[nkuhl30]

We bind all of our Macs to AD and I was experimenting with NOMAD Login during the Summer. I was planning on rolling it out to lab machines this year but the software isn't quite ready yet. For example, there's no connection status when the user tries to login amongst other things that will cause confusion on the student side.

Also, it hasn't been updated in several months, if not longer. So I have to wonder if there's a commitment to the product.

I don't have issues with Macs unbinding from AD. The only real issue I have is how long it takes the computer to establish a connection to AD. Sometimes it takes 20-30 seconds from when the user opens the lid and wakes up the machine.

[seann]

@larry_barrett Generally all you would need to do is try and look up a user. e.g. 'id someusername' ...put that inside of an if condition that verifies the machine is on the internal network first

There is an 'active directory status' criteria built in, i think, but this isn't foolproof.

We use a different approach than EAs for 'autofixing' bindings using policies, dummy packages, and scripts.