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

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

@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.

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

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.

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

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

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

@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.

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?