Binding Macs to AD - NOMAD?

Off the top of my head... Keychain issues and AD Connection Drops -- having to constantly re-bind machines.

Binding works pretty well for us. here's some key configs to keeping it working.

1. Set the "Password Trust Interval" to 0 - this keeps them from "dropping" and needing to be rebound.
2. Use machine based auth for wireless - this insures the wireless is connected before the user attempts to auth.
3. Get rid of password changes - they are kinda pointless and really just make the your environment less secure. advocate for multi-factor auth and conditional access to resources.

Does NoMAD require just one person to login? Can a workmate borrow the laptop and log in?

Our biggest issue right now is the Secure Token with machines being upgraded to 10.13.x. Seems to be a major issue with AD accounts.

We use NoMAD Pro configured with both Okta and AD (but devices are not domain joined). If you holistically look at JAMF; everything that AD does with Windows (GPOs, device configs, and etc.) can be done through JAMF. However, what is your use case for AD bind with MacOS. Previously, our use case was Kerberos tickets generated through AD and firewall rules configured based on AD membership (we used Centrify instead of native MAcOS bind). Since NoMAD can generate these tickets without binding devices; we decided that there is no need for us to bind MacOS to AD. Also, one more thing to remember, NoMAD [Jamf Connect] will not work with mobile accounts (at least this was the case 6 months ago). I am happy to share more details if needed.

@cdenesha Sure, but NoMAD Login would need to be utilized for that scenario to work. That effectively turns it's into a multiuser machine. Just using NoMAD alone with a local user created during DEP/Setup Assistant wouldn't work. In that case the machine is tied to a single user.

AD and secure tokens are a bad time. I still have alot of legacy machines with mobile users and Password syncing between the AD user and the crypto account has been an endless nightmare on those.

I'm hesitant to convert them all to local accounts via script because it seems about 30% of the time when I do that they account loses the secure token after conversion leaving them unable to login to filevault.

@cdenesha we dont use NoMAD login. Users login to their local accounts which is synced to Okta for password replication. NoMAD pnly generates Kerberos tickets.

The secure token problem is the main issue with NoMAD Login, and I assume Jamf Connect as well. Unless you create that user account during setup as the first user on the system created by the OS, you won't have a secure token and cannot use FV. You need DEP to do that as far as I know, but DEP is not available for every Mac and has other issues.

Apple is really mangling this secure token stuff. Since not having one prevents encryption entirely, it's making some systems far less secure than they were prior to secure tokens. They implemented it poorly without thinking any of this through.

@cdenesha probably NoMAD login is what you need. This use case was not applicable for our environment.