Bug in AD Group and User syncing with Profile Manager

OK, folks, I’ve been fighting with a bug in Profile Manager for weeks now, and think I’ve finally tracked down the source. So, time to let others know, so we don’t all bash our heads against the same wall. (This might get a bit verbose, but bear with me.)

Profile Manager, with the latest 3.1 update, seems to have introduced a major parsing issue with the way it syncs Active Directory Groups and Users into itself. The problem I saw was random groups just plain did not show in the PM web interface at all, and most users would only show themselves as members of Domain Users and Everyone. Digging through the Service Helper Log for PM showed that, indeed, it logged errors for the groups that it didn’t sync at all (but nothing about the groups that show up, but won’t sync members). And, the kicker, if I add any of these users to an Open Directory group, they show up in PM just fine. I looked under ever rock, redid a whole new server, tore out my hair, but couldn’t see any reason for it …

Until I noticed (in the giant mess of users in one of the error reports) what seemed like a typo. What it turned out to be was that if any Group has users whose CN contains escaped characters (such as a comma), this causes a truncation bug and fails the entire Group during sync. Change the CN to nothing but alphanumerics and spaces, and the group syncs (after some reboots and prodding). As for the second problem, empty groups, it seems that if any user account has different CN and DisplayName, the user never has its membership updated in any group beyond Everyone and Domain Users. No error that I can find is logged for this.

Now, all of this seems pretty dumb. Due to the way the the AD connector presents accounts, it maps the SAMAccountName in AD to the recordName in OD, and the DisplayName in AD to the RealName in OD. This means that OD groups see memberships fine. However, for some odd reason, the codepath that syncs AD groups and members uses some odd mishmash: the sync errors shows the members as ‘SHORTDOMAINNAME\\CN'. I’ve never, ever seen that used anywhere else. Also, as an added stinger, neither the DisplayName, nor the CN are guaranteed to be unique in AD; the SAMAccountName and UserPrinciple ARE. Thus the AD sync should be using it instead of the CN; or it should just use the same lookup method OD uses.

So, for anyone who is seeing the same problems I was, check out your logs and check your AD accounts, and try to line these things up. But, if owrk in a place like where I do, and CN and DisplayName are different for Reasons, you’re SOL for now; hopefully Apple will fix this bug. (I did file one.)