How to override AD identity template for resource contained in role?

Question

This is yet another variation on the "I need to compute the container for my AD user, so how do I override the identity template?"
I have a relatively elegant hack (detailed below)...but it is a hack and I am worried about unintended consequences.
Details:
I am running an active sync on a database table representing our HR info. Based on info in the table, I am assigning business roles, such as faculty, staff. Those particular business roles contain an IT role which has an AD resource assigned to it. There are different depths in the tree for students (from the student information system, not HR) vs. employees, so I can't hack it by using AD Department and Division attributes in the identity template.
Unlike many of the other posts, I am not assigning the AD resource directly. That may not matter, but it feels like that gives it even more opportunity to lose track of the information I might compute on my active sync form.
I have tried a several things. These were the most promising so far:
1. Setting accounts[AD].identity in the active sync form. Looking with the IDE debugger, it's there and correct when I leave the active sync form. But by the time the Create User process is invoked, accounts[AD] is nowhere to be found in the user. I see it after I step over the provision task, so I'm looking for it in the right place. (Other attributes, like Description, get set in the active sync form, and are also ignored by the time the user is created.)
2. Something I thought for sure was going to work: I've mapped distinguishedName in the schema, and set it via a rule in the "Set attribute values" under the resources tab of the role. Then I set the identity template to $distinguishedName$. But that failed because it complained that distinguishedName didn't exist.
Here's the hack: If I use Description instead of distinguishedName in #2 above, it works: the user is created in the correct AD ou. But Description is abused, and that feels like it's going to be trouble someday. Also, setting the identity template to $Description$ is freaky.
What's the real way to do this? Do I use the hack except with a custom AD attribute so that Description isn't abused? Do I customize a Create User for my active sync form that sets accounts[AD].identity just prior to the provision task?
Thanks in advance. -Les

Answer 1

Steve and Paul: good ideas, and good insight. Thanks!
For the moment, I am going to pursue the path Steve suggested once I verify that I will be able to assign folks to groups outside of the root container assigned to the different adapter instances. (Employees can enroll in classes, and access to course-related objects is by group, therefore there will a group to assign that's outside of someone's root container...) I don't think this is a problem, though.
Also, I sort of expected that folks wanted something human-friendly in Division and Department attributes ("Business Office" vs. "buso"). I need to use the department code (not name) in the OU because the name is more likely to change over time, and I don't know how to tell the gateway to move a user between AD containers. I've seen references in the forum of doing that by turning an update into a rename operation, but I don't yet know enough about the product to do anything actionable with that piece of knowledge.
Thanks again! -Les