This entry is going to be one I come back to, or at least post multiple parts for, because AD/OD integration, while easy, can’t be considered trivial. This first part will just cover what the scope is, and how we can get to where we want.
At this point, all I have tried is basic integration and testing with PHDs (Portable Home Directories).
Basically, campus just brought up a new AD forest that is well designed, and centrally managed from the top, and rights given to each organization to manage their OU’s. Students exist at the top of the directory, and are not assigned to any lower level OU (because they can (and do) take classes from different units). Employees all exist within specific OUs (who employs them).
Initial testing was done when the AD was being designed on whether or not to extend the schema to include the Apple attributes. Turned out, it wasn’t going to work, because rights cannot be given to OU admins to assign schema attributes for accounts not in their OU (e.g. students).
So, currently, every term, we take a dump of the campus student “database” and find all the students that are taking classes within our unit. We then limit it down to just the uniques, run that through a program called Passenger and then take that output, and import it into WGM.
Soooo… this means that we can either do Portable Home Directories and no real account customization (all customization through computer management), we use augment records, or both.
My initial testing focused on just testing PHDs with no augments. I found that the following, after binding the OD Master, and the client to the AD, worked beautifully.
This is in WGM, setting up PHDs, and on 10.5.8 client. I have not tested with 10.6.x client. OD Master was 10.6.2.
Create Mobile Account: true
Create Mobile Home with Local User Template: true
Create Portable Home Directory: false
Mobile Account Lifetime: 86400
Mobile Home Location: path
Mobile Home Parent Path: /Users
Require Sync to Delete Mobile Account: true
Show Mobile Account Dialog: false
Synchronization URL: afp://server.example.com/Users/%@
Time Server: time.apple.com
Now, this is great, and will work great for our students since we’re already planning on moving to PHDs over the summer anyway.
With this change, what we would do, would be set these settings on the “student” group we have in OD. Then at the start of the term, we do the same student database dump, but instead of making user accounts, we’d just add them to the student group after nuking everything in the group first. The nice thing is, we shouldn’t have any problems with stale users this way (users that remain in our system, even though they’re not enrolled in classes).
The issue is with faculty/staff that have access to services we host that are defined within the Directory, but obviously not in AD. For example, users that have accounts on our mail server. For them, the only thing we can think of would be Augment Records, or maybe just normal accounts in the OD. We’re not quite sure yet how this will work if the user account in the OD has the same uid as that in AD. So, I’m going to be testing this in the coming several weeks. And I will report back with this.
As a note, take a look at AFP548 for more info on this. I’ll try to post again about it within the next month, since I have to get this all figured out, either successfully or not, in the next couple months.