Convience your InfoSec - Local Accounts vs Mobile Accounts

I actually work in the infosec group, but am also primarily responsible for our Jamf deployment. We have made the switch to NoMAD with no bind. I didn't have much of an issue convincing others as the AD bind on a mac doesn't really do anything beyond the password sync/kerberos tickets. Group Policy does not apply to a Mac(this is why we have Jamf). NoMAD facilitates the sync of the local password and the kerberos tickets, beyond that Jamf enables us to do everything else. Also, all of our Macs are a 1 to 1 user ratio, the drives are encrypted so only one user needs and can login to them, we have no need for additional account creation on the fly that a domain bind would provide via a mobile account.

Your hard part will be getting past the single pane of glass argument. They may collect their security metrics based off of AD. Without the bind they have no way of tabulating how many computers are eligible to use AD services (of any sort), let alone measure compliance.

Be ready to give good responses to that even if it seems pedantic. @milesleacy had a good session at jnuc about that. It’s important to be nice and get to know them, what they say they want vs. need and be able to attempt to persuade them if there is something different.

What I expect to do as a next step is perform the AD bind for network authentication purposes (required to get an AD cert and for authentication), but move to creating local accounts for users alongside Enterprise Connect.

We still have some AD requirements, but if I can stop Apple's AD problems from impacting our users it will be a win.

I would love to ditch AD but we use the bind for WiFi/VPN certificates. I have some mandate from my InfoSec department to ditch AD but there are things like WiFi that require it. If I could get them off that, it would be great. I can do everything that they want with passwords and such with noMAD, InTune, and what not.

@dshepp33 NoMAD can currently issue certificates from an Active Directory enterprise CA, which is I assume is what you are using for VPN and WiFi. This is how we are doing it today, sign into NoMAD with your AD creds and as long as the set of managed preferences are there you are issued a cert.

@powderspecial600 The problem is when you want to have your Mac connect to 802.1x authenticated WiFi in machine mode using the machine's AD identity so that it's on the network when nobody is logged in. NoMAD can't handle that use case (I'd love to find out I was wrong about that though).

@StoneMagnet We are just using it for VPN use at this point. We are going to go down the wireless road, but haven't gotten that far yet. I bet NoMAD would be open to developing such a use case as they seem to be rapidly developing new features to the product.

But you have to have OKTA for this to work. Sadly not an option for us here in FINTECH

In our environment there were a few "points" we used.

1. Better user experience. We had a issues with the bind staying bound and with password syncing to the FileVault log in partition.
2. Better support option for users not in a Corp office... image/enroll anywhere.
3. Cost saving. we expect significant less helpdesk tickets because if #1 and #2
4. Allowing us to move to DEP, when we moved to DEP and AD didn't really work together.
5. Follow Industry standard, Apple, IBM and others
6. We also point out in our case we were just getting password rules and moving to config profiles we would be "equal to or better" than AD in follow our "password" guidelines that the InfoSec set.

Hope this helps

C

Sorry to rehash this post, but we were wondering... now that most have moved to a more remote work model, is anyone still joining their mac fleet to AD, and then creating a mobile account while folks work at home? Like are there any benefits of AD on the Macs now if we're no longer sitting in the office hardwired to the domain? Your thoughts?

The only time a bind, in my view, is useful is when the device context is 1:many, meaning labs, shared resources, etc. You can solve certificate issues with SCEP, ADCS, NoMAD etc. The one thing about binding any device that is rarely talked about is that it is not secure and never will be. It's a technology from the 1970s when everything was hardwired. Within this -- and what most people miss -- is that by using a terminal command "id", whether you are a standard or admin user, you can parse the entire company directory and this has led to problems in the field especially when it comes to social hacks. Ideally, a true zero-trust environment should have no persistent communication with a directory provider outside of multi-factor. If you have a working MDM, and you are escrowing FV keys, not only should there be no bind, but there should never be any kind of shared password or any other ability to login with a network account on a 1:1 laptop. That means no LAPS, no shared admin, no mobile accounts, nothing. Just the MDM management account and the primary "owner" of the device. If the device is provisioned correctly, there are enough tools in the MDM toolbox to mitigate any password issues. Bottom line - it is my view that traditional LDAP binding is a poison to modern secure device management and I would avoid it like the plague wherever possible. There never was, nor will there ever be a single pane of glass when it comes to multi-platform device support. If someone could pull it off, they would have done that by now, the closest anyone has ever come is WorkspaceOne and it is still terrible. It's terrible because it tries to be all things to all people. Specialization creates better focus and better long term support, and that is what reduces downtime, salary and other hidden costs - not an artificial single pane of glass concept that only ever seems to please the exact people who don't actually use these tools. Besides, Webhooks and APIs are still things. If you want a single pane of glass, make one yourself.

My final hurdle to move away from AD is that the bind is necessary to get on wireless in the office. The end-user receives a machine certificate from the network policy server - which correlates an entry in AD. 802.1x and all the good stuff.

Without the bind - there's no AD entry that's up-to-date. Any thoughts on how to get a machine certificate if you don't exist in AD?

Is this a situation where something like intune can obtain enough information from Jamf - then back to AD?

@k3vmo Have a look at the Jamf AD-CS Connector.

This is something we are planning to adopt later this year to facilitate a move away from AD binding.