Active Directory and MacOS...how does it work?

cjohnpmllc_com
New Contributor II

Hi All,

I'm just confused on how this all works. I'm primarily a Windows Admin so please forgive me. So I have a few macs now on my environment. I've tried to bind the machine to my AD by the Login Options. If I go to Terminal and type dsconfigad -show, it shows my AD forest/domain/computer account. And there is a computer object in my AD for this computer. In that sense, I believe the computer object is good.

However, when I look at the user accounts, initially the passwords were all the same (in AD and local to the machine). We have a policy that the AD user account passwords need to be changed every 90 days. This is where the issues come up. For some reason, user accounts don't appear to synchronize the passwords after that change. They now would have two passwords (local password and the network AD password). Any ideas on how to fix this? Let me know if you need anymore info, thanks!

10 REPLIES 10

jason_bracy
Contributor III

If there were users accounts prior to joining AD, then those accounts remain local and do not follow the policy for Domain accounts. My process to convert from Local to domain account is:

  1. Login as a local admin (not the account that you want to convert)
  2. Go to “System Preferences / Users and Groups”
  3. Delete the local account, but select the option to leave the home folder
  4. In the Finder go to /Users/ and change the name of the deleted user folder from “userid (Deleted)” to “userid”
  5. In the terminal enter the following command: sudo chown -R userid:"Domain Users" /Users/userid/
  6. Log out and log in as “userid” with your domain password
  7. You will need to sync your keychain password

mm2270
Legendary Contributor II

@jason.bracy is right on this. Existing "local" accounts have items in their records that indicate they are local accounts, not tied to a directory service. It doesn't matter if the name of the account matches the AD account. It won't pair up unless the user account is modified or recreated. The way the Mac works when logging in is that it will look first to the local domain, and if it can't find the account there, will go next to any domains it's joined to. IOW, it will always use the local account first if it's there.

What Jason listed above are steps to have the local directory services record be recreated from AD, but be aware the log out and log back in method may only work if your Macs have a wired network connection or have a Wi-Fi loginwindow profile that allows them to stay connected to the network when someone is logged out. If either of those aren't the case, then when logging out, your users may not be able to log back in, since it won't be able to see the domain. Either that, or since it can't see the DCs, it will recreate a local account, defeating the purpose.

Another approach is to remove the local dir services record as shown above, and then use the createmobileaccount binary to create it again and pair the original local home directory to it.

sudo /System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount -n "shortname" -h "/Users/shortname"

As long as the Mac is connected to the network and is joined to the domain, it should be able to (re)create a cached account that matches up with the AD username. The -h flag directs it to use the existing local account as it's home folder.

mm2270
Legendary Contributor II

Forgot to also add that many environments are starting to move away from AD binding, even though it's still used a fair bit. Instead, you could look at something like NoMAD or Enterprise Connect to sync AD and local account passwords without needing to join the machines to AD at all. Worth exploring, but I understand there are many environments that are extremely hesitant, or even downright hostile against moving away from direct AD binding.

cjohnpmllc_com
New Contributor II

Ohh interesting...NoMAD does seem neat. Don't really care about direct binding as it seems to be a pain in the ass.

mm2270
Legendary Contributor II

Not only is it a pain, but Apple doesn't really give binding the time of day, so with each new version of macOS, they tend to conveniently "forget" to test it (Oops!) and it breaks, usually not to be fixed until the 10.x.2 update or thereabouts, or what I like to call the "we'll get around to it eventually" timeframe.
It also has a tendency to cause slowness at logins among other issues. So yeah, if you're cool with not binding, I would look at NoMAD. I wish I could use it where I am and not bind anymore. It would likely solve a host of issues for us.

kerouak
Valued Contributor

by using NOMAD I mean.. And, it was crap when I tried it...

pavanraju
New Contributor II

@mm2270 Apart from password change every 90 days and MS exchange services, is there any other purpose of AD in enterprise?

john_bio
New Contributor III

NomAD is amazing. Such a great tool

In saying that though, I've been pretty lucky in my environments that i've managed in terms of the AD binding has always worked flawlessly

jason_bracy
Contributor III

@pavanraju When joined to AD and using an AD account for login AD will manage the password policy which includes complexity as well as duration.

AD can also provide machine certificates for network authentication with 802.1x networks. Without a domain join your organization would need to use a different method for certificate issuance. Most Windows centric networks prefer the all in one Microsoft approach to manage Windows with a system like JAMF-Pro in the middle to manage Macs and iOS.

NoMAD is great, and can help with user certificates for Kerberos, but if your environment uses machine certificates for anything, then the only way to get those is to join the machine to AD.

cjohnpmllc_com
New Contributor II

ok so this is a weird one...I installed NoMAD on a user's machine. Added my local AD info. It found the user account, but in NoMAD it says that the user's password is set to never expire. I double checked in AD and that is not the case. Where could that be pulling that from?