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!
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:
sudo chown -R userid:"Domain Users" /Users/userid/
@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.
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.
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.
@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.