[Frank_T]

Same issues only in a test VM of our production AD domain. I’ve logged a bug report to apple but don’t have my hopes high they will address it. 🙁

[Frank_T]

Correct computer lists are not regular security groups. One of our admins has come up with a powershell script that will run on the domain controller and filter what we need in our OU’s and add only those objects into the computer-list string as needed which fixes the issue of automating the adding and removing of computer objects to the computer list since the script will run hourly.

My next issue is now getting groups within groups working and MCX applying the correct settings based on those groups. Such as a user object that has higher access level’s on a computer object that doesn’t so the user MCX settings applying over the computer settings at login, such as in a lab for example.

Reading the white paper there isn’t a explanation why we shouldn’t use a further attribute inside the apple-group class.

Currently the white paper on how to map the Mac Schema to AD lists only the following options should be selected in AD Schema Analyser.

apple-group
subclassOf: top
rdnAttId: cn
mayContain: apple-group-homeowner
mayContain: apple-group-homeurl
mayContain: apple-keyword
mayContain: apple-mcxflags
mayContain: apple-mcxsettings
mayContain: apple-user-picture mayContain: ttl

But for some reason they don’t include this attribute

mayContain: apple-group-nestedgroup

Which may allow workgroup manager see AD objects created with ADSI or normal security groups as computer groups since computer lists attribute was really only required for 10.4 and below as there was no groups for OD back then. Since 10.5 work group manager supports computer groups and even has a button to allow admins to upgrade computer lists into computer groups and I believe this is the attribute.

Keep in mind I need to test this in a VM as it’s a one way street with AD and making changes to it’s schema. Which is why it’s a risk to play outside of the whitepaper apple has put out back in 2009 about this. So i’m currently looking at how one disables or renames class’s and attributes in AD in the event their not needed anymore since deleting them is not a option.

And FYI for anyone interested 10.7 server has even more classes and attributes than 10.6 but it doesn’t change anything on the 10.6 OD schema but only adds to it.

So there are two outcomes to why apple hasn’t recommend using apple-group-nestedgroup

1. It doesn’t work and if applied will do some weird stuff to AD LDAP
2. They want to limit the functionality to as to not make Mac OS Server completely redundant (Magic Triangle anyone?) in the process since having the full support feature set of OS X Server’s LDAP in Active Directory would limit the appeal in setting up another directory when one can apply the same settings to end users with AD.

And who knows maybe the way apple is going with OS X server and killing the Xserve recently the whitepaper on what to import into AD for the schema may be updated to allow more options that are currently lacking and limiting it’s application on a large scale like what i’m trying to do.

If anyone has followed the whitepaper on applying the Mac Schema to AD and has done so and would like to share their story please do. Happy to read what you found once you applied it. How well it’s working and if there any any issues you would like to point out that people should know about.

Oh and as for reporting a bug I talked to an apple rep that we have as a contact who will forward that internally but I don’t have my hopes up high that they will notice that request since Apple’s focus these days is in a iOS direction 🙂

[Author]

Posts