Getting a Macintosh to join a corporate wifi network that uses a certificate from a Microsoft certificate authority for authentication is pretty easy after Mountain Lion (OS X 10.8) added support for DCE/RPC certificate requests. There are four primary tasks to accomplish this:
- Bind the Mac to Active Directory
- Add the Microsoft CA to the keychain
- Request a Machine certificate from the CA
- Configure the wifi network using the certificate for authentication
These tasks can all be done using configuration profiles. Configuration profiles are XML files that can be created/edited by hand or through various tools like OS X Server Profile Mananager. You can do this in a single configuration profile if desired, but I recommend splitting these into multiple profiles. By using multiple configuration profiles you are able to more easily make changes and troubleshoot problems that may be profile-related. For example, if all the items are in a single profile and you want to remove the wifi settings, you will also undbind the machine from Active Directory.
Active Directory Binding
Apple has a whitepaper that describes binding a Mac to AD. There is also a KB article describing all the parameters in detail. I recommend using a dedicated profile with a single payload just for the AD binding.
In the description field of the general section of all my profiles I include a version number to keep track of profile revisions. You can also require a password to prevent users from removing the profile without authorization.
How you configure the profile will depend on your environment. At a minimum you will need to provide:
- Server Hostname - Just entering the domain name should let the client find a domain controller on its own. It is not recommended to enter a specific domain controller name as this may change.
- Username/Password - This is the name and password of an account with rights to join machines to AD. Using default groups this would be at least Account Operator but I’d recommend creating an account just for domain joining machines to the domain that has less rights.
- Client ID - This is the hostname of the Macintosh. In the example below, I use the naming convention “MAC” followed by the machine’s serial number. %SerialNumber% is a payload variable that will resolve to the serial number of the client the computer it is installed on. Apple has a list of payload variables that are supported.
- Organizational Unit - The default location for machine accounts in Active Directory is the computers container which is specified by entering “cn=computers,dc=domain,dc=com” however if your organization puts machines into an alternate OU then the format is “ou=foo,ou=bar,dc=domain,dc=com”. Note the syntax difference between the default computers container (cn=computers) and the custom organizational unit (ou=foo,ou=bar).
- Create mobile account at login - This is not strictly required but it is recommended. If you neglect to create a mobile account at login then the user will not be able to log in when not on your corporate network.
Other settings worth noting in your AD binding profile are under the Administrative tab. Here you can add additional usernames and/or groups that are automatically granted administrative rights on your Macintosh machines. By default the default Active Directory groups enterprise admins and domain admins are included. It is also worth noting that the namespace defaults to domain which may create some naming issues with your mobile accounts. With the namespace set to domain, local user profiles are created in /Users/DOMAIN\userid/ , which has a backslash in the folder name. In general, this is a valid character but some apps (Powerpoint, I’m looking at you!) may not work well with files in the user’s home directory when named this way. It’s also just generally unpleasant and awkward to work with. Changing the namespace to forest will result in mobile profiles in the format /Users/userid/ which is counterintuitive, but nevertheless the desired naming convention.
Part 2 covers the rest of the process.