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.
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.
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
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
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
Secure LDAP (using SSL) can and does use self-signed certificates for our servers.
Obsolete Section
End obsolete section
Then:
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
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.
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
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.
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:
The User Groups are currently used to manage:
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:
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:
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