Integration of Macintosh Authentication and Management into Active Directory (OBSOLETE)

This document relates to MAC OS X 10.6.8 and needs to be updated to reflect current conditions on both servers and clients under MAC OS X 10.9
This integration procedure follows the details laid out in the following AFP548 document.
http://www.afp548.com/filemgmt_data/files/AD-OD-2.1.pdf (there is no such file and the web page needs to be updated)
Matters regarding Directory Host were not pursued since we will likely rely upon automatic SMB mounts to provide users with access to roaming personal disk space. I have also endeavoured to include additional details concerning pitfalls which the document does not cover.

No Active Directory schema changes are required.

The diagram below depicts the golden triangle for how Macintosh client terminals are bound to (member of) both an Active Directory domain (for authentication) and Macintosh Open Directory realm (for terminal and user management). At least one Macintosh OSX server must be part of this triangle and must also be a member of the same Active Directory domain. The Macintosh server is configured to be an Open Directory Master server. It manages client terminal configurations (MCX records) such as access rights. Although the Macintosh Server does not require user authentication through Active Directory, it does require access to the Active Directory for user information and group memberships to manage terminal access rights.

Client Macintoshes are managed by the Open Directory and authenticated by the Active Directory. A Macintosh client is bound not only to an Open Directory for management but also the Active Directory for authentication.

There are three Macintosh utilities involved in the integration process, each is found in the Applications folder on a client terminal or server's the local hard drive.

• Directory Utility (under the Utilities subfolder)
• Server Admin (must be placed on client terminals under the Server subfolder)
• Workgroup Manager (must be placed on client terminals under the Server subfolder) - used only until Mac OS X 10.8. From Mac OS X 10.8, Workgroup Manager has been deprecated and has been replaced with Profile Manager.

Configuration of Macintosh Server

• Drive configurations and possible recovery scenarios:
  • Empire contains 2 factory 1TB drives in a mirror, and a third drive, partitioned into 2 500G's = backup1 and backup2.
  • periodically, about the time of significant change; the Open Directory is Archived, using Server Admin, into a date specified file in Desktop/OD Archives
  • periodically, ditto, Carbon Copy Cloner is used to clone Raid1 to either backup1 or backup2, alternately, so there are 2 generations
  • Networker is also providing nightly backups
  • Recovery options:
    • if an OD change makes it inoperable, use Server Admin to do an OD recover from archive
    • if one of the mirrored / Raid drives fails, it can be replaced, and the mirror rebuilt
    • if both fail, or a change goes bad, an emergency reboot from the latest of backup1 or backup2 is available; operation is restored, and a further recovery can be performed back to Raid1

• • Mutsu contains 2 factory high speed 73 GB drives, mirrored, for the system, and a third 1TB drive Server HD for storage, eg images for netbooting
  • It is a replica server for the Open Directory; so recovery would consist of disconnecting / reconnecting the replica relationship, using Server Admin
  • Networker is providing nightly backups

• Bind the Macintosh server to the Active Directory using the Active Directory plugin found in the Macintosh server's Directory Access utility.
  • See ADAddMac for details
  • * Important: When configuring an Open Directory Server, UNTICK the box "Use UNC path from Active Directory to derive network home location" * this will cause server panic dumps if enabled! **
  • Leave the Directory Access applet open as you will need to return to it after the next step.
• Activate the server's Server Admin utility to create an Open Directory Master server. Effectively creating a new Open Directory (or Kerberos) realm.
  This is a process which is rather akin to promoting a Windows server into the first domain controller of a new Windows domain. You are also asked to name and create a separate administration account (diradmin by default) with which to interact with the Open Directory. Note that the server's local administrator account (usually called admin) does not automatically have diradmin authority to access the realm.
  • Expand the localhost list in the left hand panel.
  • Select Open Directory in the left panel.
  • Click on the Settings button in the right panel.
  • Role the Standalone Server indicator to Open Directory Master.
  • Create Directory Administrator account (diradmin) with its password.
  • Normally, you would not change the Kerberos realm name from its default value. In our case, the Kerberos realm name is the Active Directory domain name prefixed with od. So, the Kerberos realm name in the CS Teaching environment is od.student.cs.uwaterloo.ca.
  • Click on the SAVE button.
  • After about 60 seconds the server will become a Open Directory Master server.
• Change Order of Authentication in Directory Access.
  • Click on the Authentication button at the top of the Directory Access applet
  • Change the authentication order such that Active Directory comes before LDAPv3/127.0.0.1. The LDAP entry has been added due to the creation of the Open Directory Master.
• Activate the server's Workgroup Manager.
  • Specify the Open Directory server name (even if it is local) when asked to connect.
  • Use the newly created diradmin account to connect to the Open Directory master server.
  • Workgroup Manager must point to LDAP 127.0.0.1 and not Active Directory. Workgroup Manager cannot create groups or lists within the Active Directory. Information for the managment of macintoshes is strictly maintained in the Macintosh Open Directory.
    • Control for this is small blue dot on left side of Workgroup Manager window.
    • This may have to be adjusted each time you connect to the Open Directory master using Workgroup Manager since the Active Directory tends to be the default.
    • Below the directory control there should be four symbolic buttons. Left to right:
      • Users
      • Groups
      • Computers
      • Computer Groups
    • Click on the Computer Groups button.
    • Clicking on New ComputerGroup will let you define a new grouping of computers that you can manage.

You are almost ready to manage any Macintosh client terminals that are bound to the Open Directory realm. However, unlike the case for Active Directory users and groups, Open Directory cannot use the computer information derived from Active Directory to populate a new or existing computer list. This is due to Macintosh Open Directory utilizing client terminal ethernet addresses to uniquely identify a terminal. Active Directory retains no such information about clients and relies on a Microsoft specific SID number instead. Neither form of identification is convertible to the other.

Therefore computer list entries must be handled manually (or using a script) where the terminal name and ethernet card address are entered into the Open Directory, or using the "..." search tool under the "+" (=add) button. To avoid confusion, a terminal's name in the Open Directory should NOT be the same as the same terminal's name in the Active Directory.

Configuration of Macintosh Replica Server

Install server software (either dvd or cd's) as per any server

Configure appropriately (ip address, machine name, etc.)

Since this is to be a replica server the following steps are needed

• 1. Make sure the server is an Open Directory replica.

To determine whether a server is an OD master, OD replica, standalone server, or connected to a directory server, select Open Directory for the server in the Computers and Services list, then click Overview. The first line of status information states the server's Open Directory role.

• 2. In Server Admin's Computers and Services list, select Open Directory

• 3. Click Settings (near bottom of window), then click General (near the top)

• 4. Choose Open Directory Replica from the Role pop-up menu

• 5. Enter IP address of Master, root password, LDAP directory administer account (this is different from the primary administrators account), LDAP administrator password

• 6. Click Save

• 7. enable SSL on the replica, to match the master, eg:

slapconfig -setldapconfig -ssl on -sslkey /etc/certificates/russet.student.cs.uwaterloo.ca.key -sslcert /etc/certificates/russet.student.cs.uwaterloo.ca.crt -ssldomain russet.student.cs.uwaterloo.ca

• 8. The OD master server will automatically update the replica

• 9. On the OD master check under Open Directory heading (using Server Admin) that the new replica is present and that the update replica schedule is appropriate (currently set to update replica every time there is a change on the Master OD)

Populating Computer Groups in the Open Directory

This is now done in Work Group Manager, using the browser tool within the Computer Group Members Tab.

There is a default, created by having a "guest" in the Computers tab (used to be a guest List). If adding a machine is forgotten, the login window will display the guest text.

Obsolete Section - based on how we did things with Tiger (OSX 10.4)

A script has now been written which first extracts the list of Computer Groups from the Open Directory. They are assumed to be all in upper case, and to identically match a room number as stored in our Equipment database; eg DC2555E. It must currently be run on russet, using the cscfadm credentials.

For each room, it then extracts a list of computer names and mac-addresses from the Equipment Database, where the computer name follows our new standard imacxxx or emacxxx.

It then compares the list against the previous extract to determine a list of removals, and a list of additions. Removals are processed first, and the computer is removed from the computer list, then from the computers category, to try to prevent orphans.

Additions are then processed, with the computer record added first, then the entry in the group list. All removals and additions are via LDAP functions against the local Open Directory.

This script (mngCmptrsOD.pl) is now run as a cron job, so that any lab maintenance may be accomplished by just updating the Equipment/Inventory Database. It is scheduled at 8:01, every 2 hours, until 18:01, and the output is mailed to cs-poc-maclabs@cs.

Warning: because of the method used, any computers manually added via WorkGroup Manager to the computer groups will not be maintained correctly by this process, which could lead to data inconsistency. They should be OK if added and deleted manually, as long as they are never assigned to a managed room in inventory, while also manually in a different room-group.

End Obsolete Section

Configuration of Secure LDAP on the Open Directory Mac Server

Secure LDAP (using SSL) can and does use self-signed certificates for our servers.

Obsolete Section

• Obtained IST certificates for Domain Master.
• Stored them in /etc/certificates as ISTPrivateKey and RussetPublicCert and downloaded and saved IST certificate as cacert.cer
• Fixed ownership and permissions.
• Edited /etc/openldap/ldap.conf to comment out TLS_REQCERT never

End obsolete section

Then:

• Ran Server Admin on Domain Master and selected Open Directory service:
• selected Policy
• unchecked under Directory binding, enable directory binding
• Under Security made sure to check disable cleartext passwords, and checked Encrypt all packets
• Under Protocols, ticked enable SSL, got a subdialogue to specify the private key, server certificate, and CA cert, then an option button to Import them - that created new entries in /etc/certificates/ of the form russet....
• the Save option then modified /etc/openldap/slapd_macosxserver.conf to add lines like:
• TLSCertificateFile /etc/certificates/russet.student.cs.uwaterloo.ca.crt
• TLSCertificateKeyFile ..... .key

It also restarted slapd with the new configuration. The server now supports ldap, ldaps and TLS services.

Obsolete section

The certificate expires after one year. The process to replace requires that you delete the old certificate in Server Manager, Settings, Certificates. Then add the new one. The IST certificate has now also been added as a trusted root certificate, since this time, there was an error when trying to add the new certificate - it could not be traced back to a trusted source.

End obsolete section

Configuration of Macintosh Client

Below is a description of how to manually bind a Macintosh client to both an Active Directory domain and an Open Directory realm. In practice, we will only use that procedure for occasional system maintenance. We intend that Macintosh clients bind themselves through the use of a locally run command script. This script could be transmitted to the client lab terminals and forced to run locally. For more details concerning this method of client binding please consult ADMacIntegScript.

You must have local admin privileges on the Macintosh client computer.

• Bind terminal to Active Directory - ADAddMac
• Bind terminal to Open Directory
  • In the Directory Utility applet select and configure the LDAPv3 plugin.
  • Deselect the Add DHCP-supplied LDAP servers to the automatic search policies
  • Select the New... button.
  • Select the Connection button at the top of the applet.
    • Supply a Configuration Name. This can be the anything, even name of the Open Directory server.
    • Supply the full name (or IP) of the Open Directory server to which you are binding the client.
    • DO NOT bind the client terminal to the Open Directory if you are prompted to do so.
      Enter the terminal's intended OD name, tick the SSL box, and click on Continue. Do not supply directory admin credentials.
  • Select the Search and Mappings button at the top of the applet.
    • Ensure that Access this LDAPv3 Server using: option is set to From Server.
  • Select the Security button at the top of the applet.
    • Ensure Disable Clear Text Passwords is selected.
  • Click the OK button.
  • Select the Authentication button at the top of the Directory Access applet.
    • Ensure that Active Directory comes before LDAPv3 in the authentication list.
    • Click on Apply.
  • In Leopard, edit /etc/openldap/ldap.conf so TLS_REQCERT = never (or make sure every client has all the OD server certificates loaded)

Managing User, Group and Terminal Access Rights and Characteristics

The Workgroup Manager is the primary tool for management of the Macintosh client terminals. It is a network tool used to connect and give commands to the Open Directory Master server. By default, this tool is not installed on a client, only on servers. However, it can be added to a client terminal and is just as effective when used from a client.

On any Macintosh system that is part of the golden triangle, open the Workgroup Manager

• Specify the name of the Open Directory server which manages the Macintosh terminals.
  Even if it is the local server to which you are logged on.
  • You will require the diradmin account and password for the Open Directory.
• After a successful connection, Workgroup Manager must point to /LDAPv3/127.0.0.1 and not Active Directory.
  • Control for this is the small blue dot on left side of the utility's window, just below the applet control buttons.
  • If the option for /LDAPv3/127.0.0.1 is not there by default...
    • Select Other...
    • Select LDAPv3 in the directory list which appears.
    • Select 127.0.0.1 in the directory sublist which will appear.
    • Click OK.
• It is here that the interface becomes less intuitive.
  Below the directory selector there are three graphical buttons, associated with each of these selections is a set of characteristics which the directory administrator may control. Unfortunately, not all characteristics are accessed in the same area of the applet. Some are accessed through buttons located in the right panel of the applet. Others, such as Preferences, are a button just below the applet's menu bar.
  From left to right:
  • Users: A list of users native to Open Directory.
    • By default this should only contain the diradmin account.
  • Groups: Open Directory groups.
    • Members:
      A list of users and groups from either the Active Directory or the Open Directory.
    • Preferences:
      A series of desktop characteristics that can be initialized or enforced for this Open Directory group.
    • New Group:
      This control allows the diradmin to create a new Open Directory group.
      It cannot be used to create a new Active Directory group.
  • Computers:
    A list of computers managed by the Open Directory. The are automatically included here when added to a Group. Preferences can be managed at the Computer level, but are much more effective if managed at the Group level (see below).
  • Computer Groups: formerly Open Directory Computer Lists.
    • Members:
      A list of member computers which are linked to the Open Directory for management. Computer objects from the Active Directory may not be entered into a computer list. See below.
    • Access:
      A list of Open Directory users and groups with rights to logon to terminals in this computer list. Active Directory groups and users cannot be listed here, they must be members of Open Directory groups, which would then be listed here.
    • Obsolete Cache:
      This option allows diradmin to establish the amount of time between updates from the Open Directory to list members. Information such as group memberships for access rights are updated in intervals defined by this setting. END Obsolete
    • Preferences:
      A series of desktop characteristics that can be initialized or enforced for computers that are members of this Open Directory computer list.
    • New Computer Group:
      This control allows the diradmin to create a new computer group in the Open Directory.

Active Directory objects may not be used directly within the Open Directory. In order to use Active Directory objects in the Open Directory, the objects must be associated with objects (usually groups) within the Open Directory. For example, a class group in Active Directory called cs140 must be made a member of an Open Directory group (call it cs140_od) for the membership of cs140 to be usable against any system managed by the Open Directory.

The the case of Active directory computer objects, Open Directory cannot use them at all for populating a computer list. This is because Macintosh Open Directory utilizes the client ethernet card address to uniquely identify a terminal. Active Directory retains no such information about a computer and relies on a Microsoft specific SID number instead. Neither form of identification is convertible to the other. Therefore computer list entries must be handled manually (or using a script) where the terminal name and ethernet card address are entered into the Open Directory. To avoid confusion, a terminal's name in the Open Directory should NOT be the same as the same terminal's name in the Active Directory.

In testing, it seems that AD Domain Admins are NOT implicitly granted login rights when access is controlled via the Open Directory, even though the client AD plugin looks like it is configured to allow them to administer. It appears to be necessary to explicitly include the AD Domain admins group within the groups that have login permission on each group of machines.

Design of Groups for Managing Macs

The objective is to provide a management infrastructure, using WorkGroup Manager on the Open Directory Master server; note that for some application related management, it is more effective to have WorkGroup Manager installed and running on a machine which runs the standard image - this allows the correct references to be created.

Management is along 2 axes: groups of computers, and groups of people. Groups of people can be aggregated within the Open Directory, but for our authentication/identification purposes, the root must point back to an account, or group in the CS-TEACHING domain. The potential difficulty is that groups of people can be used both to control access, and to manage settings.

Some management capabilities can be specified either by user group, or by computer group, eg printing. Logic points to managing only where necessary, and at the highest possible level of aggregation. However, experience can improve logic! Testing experience shows that too many layers of groups within groups may cause problems. Managed properties may not actually apply to desired people, because inheritance did not happen through groups as was expected/hoped in OSX 10.4 (Tiger). That situation has improved in OSX 10.5 (Leopard) as of September 2009, and we are now using nested groups, effectively.

The Computers/Room based groups are currently used to manage:

• printer lists, and default printer setting
• Login Window text
• System Preference management
• Software Update override (may actually be controlled by the image)
• Media Access

The User Groups are currently used to manage:

• Login items:
  • startup: start X11, map shares
• Internet defaults, eg Firefox set as default browser
• Dock - customized for each course, with a base of Firefox, Thunderbird, TextEdit, X11, and System Preferences
  • CS100 adds the Microsoft Office Applications, PageSpinner, FileMaker Pro
  • CS200 adds Microsoft Word and Excel, Adobe Illustrator and Photoshop, PageSpinner
  • CS135-36 adds DrJava, DrScheme, and XCode
  • other CS1xx courses also currently add DrJava, DrScheme, WingIDE, and XCode
• Application preferences (through specific plists applied under the "Detail" Tab:
  • Terminal settings
  • Text Edit settings
  • X11 - menu

Obsolete - we are no longer managing access, nor doing any room specific configuration - as of September 2009

Computer groups are geographic based each room of interest has a computer group, named (in upper case only) to exactly match the room name as assigned in the Equipment/Inventory Database. A script is run by cron on russet to populate the computer groups based on the location of any imacxxx and emacxxx computer record. Computers could be added manually to groups using WorkGroup Manager, but there is a danger of data inconsistency if they are in the equipment database.

We tried having the top aggregated people unit correspond one to one with a room, to simplify access permissions to that room; eg, MC3003Users would be given access to MC3003. However, this meant management of the desktop, toolbar and program parameters was ineffective. It appears that properties management must be done on the group that is granted access, so aggregating groups MAY dis-allow lower group level managed settings. We may script time based changes, for example to restrict a lab to a class during their lab time, but currently the allocations for class-group use are meant to be set up at the beginning of term, and possibly manually adjusted for lab exams. The variable time based changes are currently planned to be handled by creating an "OffHours" group of all eligible students, and via cron jobs, adding it to the appropriate computer-list access on weekday evenings, and removing it on weekday mornings.

Certain groups should be granted access to all rooms:

• adAdministrators
  • which contains: CS-TEACHING\administrators and CS-TEACHING\domain admins
• CSCF
  • which contains: CS-TEACHING\xxxxxx for support staff
• ISGStaff
  • which contains: CS-TEACHING\isg_cs, and specific additional CS-TEACHING\iiiiii for teaching staff
• Tutors
  • which contains: CS-TEACHING\cs1xx_tutor, 2xx

Then groups would be added for Active Directory based class users/Instructors, such as: CS-TEACHING\cs100_instructor and CS-TEACHING\cs100_student.

Pre-sets are also available to assist in managing similar groups or either type. I have created DC Room, and DC User as sample templates. DC Room contains the sample login screen text, and has to be customized for each room (we include the room number explicitly in the text as a verification that the computer has been added to the correct group). DC Users includes the default printers.

END Obsolete Section

Attempts to solve a problem requiring creation of an application configuration file within the user's home directory have stumbled over some limitations in our setup. DrJava looks for a .drjava file, and creates it if not found. However, we wanted to default the working.directory parameter to the user's home directory to simplify their initial use. Several methods were unsuccessfully tried:

• place a little script on the machine, and add it to the managed items to be opened at login - failed because it just opens in a text editor;
• place it in the login scripts section - failed because the client computer must bind to the Open Directory Server using trusted binding, and we intentionally turned off that option when configuring the server; and we would also need to add to our setup script:
  • defaults write com.apple.loginwindow EnableMCXLoginScripts -bool TRUE
  • defaults write com.apple.loginwindow MCXScriptTrust -string Encryption

and force all communications to use SSL. Pending review is an addition to the default .cshrc file that all new accounts receive to create the file when a Unix shell is first run (which works for us, because the X11 terminal is triggered at login).

The .cshrc fix did work, but subsequently, we discovered the Network Home Redirector package from

http://www.afp548.com/article.php?story=20060915140425369

We received permission from the author to modify it to suit our needs and it is now in production. It installs scripts on the Mac and calls them via login and logout hooks. The local modifications include creating .drjava if it does not exist. The original purpose was for redirecting ~/Library/Caches and ~/Library/Fonts to reduce storage in network based profiles. As of September 2009, the redirection is now available, and used, within WorkGroupManager, and removed from the login/logout scripts.

-- Main.ctucker - 23 Jan 2006 -- Main.iturner - 14-24 Aug 2006

-- Main.iturner - 04 May 2006 - 06 Jun 2006 - 27 Sep 2006 - 12 Dec 2006