MacBook’s user authentication

el_bets
New Contributor II

Hello everyone,

We use JAMF school to manage our iOS devices. We are primarily a Windows environment when it comes to laptops and desktops. We currently have new and older MacBook’s(iMacs too) that are not in the domain. They are stand-alone. For security reasons we need to start authenticating users when it comes to macOS devices. I have read some documentation regarding authentication via Azure or LDAP. What would be the pro and cons of going with either one? Also, would it join the domain after the Device enrollment? If so, would those configurations be done in the organization settings or within the profiles? I also read about directory binding. Would this need to also be configured, or is it something not related?

I have several questions to have a better understanding before moving forward.

Any help would be greatly appreciated.

1 ACCEPTED SOLUTION

AJPinto
Honored Contributor III

In short. Don't attempt to join macOS to a domain. It is a very bad idea that wont end where your security team thinks it will end. Apple tells you to not domain bind, and stopped designing macOS with domain binding in mind some 10 years ago. All kinds of things either flat out wont work, or don't work right when you use mobile (domain level) accounts.

 

Have your security team review an appropriate solution for the macOS environment and not try to shoe horn Macs in to behaving like Windows Devices. If you try to manage a Mac like a Windows Computer you will have a very bad time. Windows and MacOS have different NIST recommendations, it sounds like they are trying to force the Windows NIST recommendations on you.

 

My suggestions to look in to JAMF Connect for the most "PC like" authentication method for macOS. Managed AppleID's may also be useful, but I have always found them very underwhelming. I very strongly recommend getting with your Apple rep on this. 

 

TL;DR:

To directly answer your domain joining work flow question. MacOS is best joined to a domain AFTER the 1st login. You can join to a domain during a prestage enrollment, but the Mac does not have a unique hostname yet. So you need to rename the Mac before joining it to the domain. Once a Mac is joined to the domain and user account creation is setup correctly (just a few check boxes in directory utility) any domain user can simply log in so long as the mac can see the domain.

Cons:

  • Things like FileVault provisioning gets complicated with mobile accounts. The account needs to be on the device BEFORE FileVault enables or you must manually grant access to FileVault which requires the users password.
  • Mobile accounts are well known for desyncing their passwords. For example if a student changes their password on Mac 1, it could screw up their account on Mac 27. IT usually works fine, but not always and will generate tickets. 
  • If a user forgets the password on a specific device (ie they changed their password on a nother computer and the current computer has not synced), FileVault will need manual intervention. If the user clicks forgot my password on FileVault it will break their mobile account and desync it with the domain object
  • Locked accounts do not behave how you think they would. If a mobile account is cached on a device, and is later locked macOS will continue to let that account log in.
  • MacOS views itself as the top password authority, and does not give two shakes about what ADFS or Azure have to say about it.
  • Keep a very close eye on KB5008380—Authentication updates (CVE-2021-42287) (microsoft.com) . This KB update breaks domain binding. Apple views this as Microsofts problem, mainly because apple does not want you domain binding. So know random windows updates will break domain binding for your environment.
  • MacOS does not generally care about AD groups. If a group has admin access, you can provision that in to macOS but it will not work as you expect without extra work. (ie giving an AD group admin access only grants admin access to the GUI, you need to also modify the sudoers file to give that group CLI access)
  • MacOS features like the SSO extension and platform extensions will not work with domain accounts.
  • Microsoft features like Intune integration will offer password syncing with mobile accounts.

 

Pros:

  • user can use the same user name and password between multiple devices (until they cant, see above).
  • Kerberos tickets are generated automatically (there are tools do to this for nondomain accounts like Apples SSO extension)
  • Security and the people who dont know how things work are happy

 

My environment is currently domain bound and has been for the past 5 years. We are working at moving to local accounts and getting away from Active Directory. I work in the financial sector, if we can find a way to do this and keep security happy I am sure your environment can also. Just be ready to convince people they are wrong and keep your Apple rep close. Apple loves to argue people trying to manage Macs like PCs.

View solution in original post

2 REPLIES 2

AJPinto
Honored Contributor III

In short. Don't attempt to join macOS to a domain. It is a very bad idea that wont end where your security team thinks it will end. Apple tells you to not domain bind, and stopped designing macOS with domain binding in mind some 10 years ago. All kinds of things either flat out wont work, or don't work right when you use mobile (domain level) accounts.

 

Have your security team review an appropriate solution for the macOS environment and not try to shoe horn Macs in to behaving like Windows Devices. If you try to manage a Mac like a Windows Computer you will have a very bad time. Windows and MacOS have different NIST recommendations, it sounds like they are trying to force the Windows NIST recommendations on you.

 

My suggestions to look in to JAMF Connect for the most "PC like" authentication method for macOS. Managed AppleID's may also be useful, but I have always found them very underwhelming. I very strongly recommend getting with your Apple rep on this. 

 

TL;DR:

To directly answer your domain joining work flow question. MacOS is best joined to a domain AFTER the 1st login. You can join to a domain during a prestage enrollment, but the Mac does not have a unique hostname yet. So you need to rename the Mac before joining it to the domain. Once a Mac is joined to the domain and user account creation is setup correctly (just a few check boxes in directory utility) any domain user can simply log in so long as the mac can see the domain.

Cons:

  • Things like FileVault provisioning gets complicated with mobile accounts. The account needs to be on the device BEFORE FileVault enables or you must manually grant access to FileVault which requires the users password.
  • Mobile accounts are well known for desyncing their passwords. For example if a student changes their password on Mac 1, it could screw up their account on Mac 27. IT usually works fine, but not always and will generate tickets. 
  • If a user forgets the password on a specific device (ie they changed their password on a nother computer and the current computer has not synced), FileVault will need manual intervention. If the user clicks forgot my password on FileVault it will break their mobile account and desync it with the domain object
  • Locked accounts do not behave how you think they would. If a mobile account is cached on a device, and is later locked macOS will continue to let that account log in.
  • MacOS views itself as the top password authority, and does not give two shakes about what ADFS or Azure have to say about it.
  • Keep a very close eye on KB5008380—Authentication updates (CVE-2021-42287) (microsoft.com) . This KB update breaks domain binding. Apple views this as Microsofts problem, mainly because apple does not want you domain binding. So know random windows updates will break domain binding for your environment.
  • MacOS does not generally care about AD groups. If a group has admin access, you can provision that in to macOS but it will not work as you expect without extra work. (ie giving an AD group admin access only grants admin access to the GUI, you need to also modify the sudoers file to give that group CLI access)
  • MacOS features like the SSO extension and platform extensions will not work with domain accounts.
  • Microsoft features like Intune integration will offer password syncing with mobile accounts.

 

Pros:

  • user can use the same user name and password between multiple devices (until they cant, see above).
  • Kerberos tickets are generated automatically (there are tools do to this for nondomain accounts like Apples SSO extension)
  • Security and the people who dont know how things work are happy

 

My environment is currently domain bound and has been for the past 5 years. We are working at moving to local accounts and getting away from Active Directory. I work in the financial sector, if we can find a way to do this and keep security happy I am sure your environment can also. Just be ready to convince people they are wrong and keep your Apple rep close. Apple loves to argue people trying to manage Macs like PCs.

el_bets
New Contributor II

Thanks for the great input. This definitely gives me a better idea of what route to take. I also agree with the appleID statement. I will talk to our JAMF Rep regarding JAMF Connect.