To bind or not to bind, that is the question

@Siv sniff JN and you can maybe find a solution.

Here's a thread for you:

https://www.jamf.com/jamf-nation/discussions/6581/os-x-and-ad-integration-slow-login-times

We are going through this right now. And we have come down to two things the bind is giving us that can't easily be replaced by NoMAD or EC.

1. Domain authentication allowing our workstation admins to ARD/SSH into users machines for support.
2. AD Machine Identity Certificates.

Outside of those two needs, AD isn't really giving us anything we can't get from NoMAD or EC. We're going to work around 1 by creating on the fly support accounts via jamf PRO. Number 2, we're not using currently but the decision is if they are needed we will just work the bind into the process to create them at the time they are needed. Just because we're not binding out of the box doesn't mean it's never an option moving forward.

@hkabik would you be willing to share how you are getting around 1 in more detail? I'm in the same boat, needing to provide machine level access to domain security groups. Only we will need some logging as well to know who has gotten onto a machine with those creds. And, the users need to be able to login on the machines using AD creds, so not just ARD/VNC but logging in from the machine login prompt.

Not binding is the way of the future. Especially with a tool like EC (I haven't used NoMAD, but I've heard it is very good as well). Device management is being peeled out of AD, which it, and all directories like it, are really an Identity Access Management systems. Even in the Microsoft world, they are pushing Azure AD for identity and SCCM for device management as the future.

The downsides right now may be the rest of your environment. The model works best when all of your software is cloud based, virtualized in something like Citrix, or has a cross-platform thick client. It would also mean that VPN is largely not required anymore for all but a few things. In that model, you don't really have internal file servers, internally hosted applications, or any other walled-garden setups. Data is protected at the data level, put into systems like SalesForce, etc. Combined with multi-factor authentication to a SSO portal to access everything, and you have the model of the future.

Now, you don't NEED to have all of these things in place to take advantage of EC or NoMAD and not binding, but that should be the way you are headed.

As for the advantages, it really boils down to convenience, for one. AD doesn't really do anything for your Mac. You honestly don't lose much of anything, outside of a little sanity when your AD Admin has a kiniption over something NOT being connected to AD. ;-) The second piece is to enable better support for things like Kerberos tickets, password updates (not only to the server, but to Keychain). The third is to allow for local admin access without wonky modifications in AD. And the fourth, by extension is to empower BYOD.

Those are my thoughts at least.

"And, the users need to be able to login on the machines using AD creds, so not just ARD/VNC but logging in from the machine login prompt."

You will have to be bound for this. no ifs ands or buts.

We're currently planning an AD migration and at the moment I'm thinking of taking the "middle way",
i.e. binding to AD, but using local accounts with NoMAD.
That should offer the best of both worlds,
NoMAD taking care of password changes/FileVault/Keychain and all its other goodies,
while still being able to deploy machine certs and granting admin rights based on AD-groups.

If you're in a multiuser-environment you have to keep this in mind though!

In a shared machine environment like ours binding would seem almost essential unless I am missing something pretty obvious?
Especially if we want to use the same credentials on macOS and Windows.