My current work environment consists of mostly Macs authenticating against a MS Active Directory server (see my earlier post all about Joining Mac systems to Active Directory). One of the disadvantages of this setup – one that has prevented me from rolling out an agency-wide password expiration policy – is the fact that, when a user updates their AD-based password, Mac OS X, by default, doesn’t know how to automatically update the passwords that protect the users keychain.
My current job has me working in an (almost) all-Mac desktop environment. However, we’re in the curious position of running a predominantly Windows-based backend (precipitated by our use of MS Exchange Server).
Here’s my recommended procedure – (note that this procedure is for new system builds; I’ll cover migrating existing users in a future post):
- Name each client consistently
Set the name of your client Mac by going to System Preferences -> Sharing -> Computer Name. I strongly recommend a standardized naming convention that works best for you. In my case, I name the systems after the primary user (scottc, for example) – I prefer this over, say, the serial number or the asset number as it saves you a step of figuring out “OK, I know I need to locate this system, now whose is it and where can I find it?”
- Join each client to Active Directory
You need to use the Directory Utility app to do this – just launch it by using Spotlight, as the app itself is buried in /System/Library/CoreServices/Applications. Double-click “Active Directory.” Note that the Computer ID is, by default, set to the name you specified in step #1 – this is the name that will appear in Active Directory.Enter your domain name – I don’t know about all cases, but I find I have to include “.local” in order for the Mac to find my Active Directory machine.Do NOT hit “Bind” yet!!!
- Decide if you want systems set up with mobile accounts
You want to do this. Trust me. Don’t trust me? Fine, I’ll explain…If you want your users to be able to sign on to their systems whenever they’re outside of the office (i.e. unable to access your Active Directory server) then you need to specify the creation of “mobile accounts.” This will create a permanent account on the Mac whenever someone initially, successfully authenticates against Active Directory. That way, the next time the user signs on to the Mac when it is not within the office network they can still get on to their system.Enable mobile accounts by clicking the small triangle underneath the text fields – this exposes a number of advanced options. Under the “User Experience” tab, check both “Create mobile account at login” and “Require confirmation before creating a mobile account.”
- Bind the system to Active Directory
Hit the “Bind” button. When prompted for a username/password, enter your Active Directory’s administrative account credentials (for example, my user name is ‘administrator’ – specifying the domain isn’t necessary).
Smart I.T. Guy Tip
Before quitting Directory Utility, do yourself a favor and visit Edit -> Enable Root User and specify a complex password that only I.T. admins know. This gives you a way to access the system no matter what and also benefits things like system scanning in systems like Spiceworks.
Now, whenever a user signs on to the Mac successfully, they’ll be asked if they want to create a mobile account – the primary user should select ‘yes’ and, presumably, most others should select ‘no.’
Note that these instructions are current as of Mac OS X v10.10.5.
If your office is using a Windows Server system as your primary AD/DHCP/DNS box then you need to be a bit careful about how you configure that computers network interface card. Here are a few tips to keep in mind:
- If you have multiple NICs on the machine, don’t try bonding them together – Microsoft doesn’t recommend it and, as tempting as it may be, it won’t result in any performance improvement so don’t add the unnecessary complication.
- Don’t rely on a DHCP-based IP reservation for your AD machine – simply hard-code the IP address.
- Be sure to specify the loopback IP address (127.0.0.1) as one of the system’s DNS servers, though NOT as the primary one. See here for details on this one.