Sounds like you have a very interesting problem ;-)

I'm just going to shoot off some ideas. I'm making a lot of assumptions about what your schemas look like, and I've never had to do this kind of transformation, so maybe I'm way off base here, but here goes anyway...

I'm thinking about splitting the problem into two parts: one to handle the various schemas and another to figure out the permissions. The schema part determines the structure of LDAP entry and the permissions part is called upon to compute whether or not a person has authorization to do various things.

First the permissions part. For this I would look at using a role-base access control (RBAC) mechanism. RBAC is very useful for describing access controls where the permissions are associated with roles that can be assigned to people. A person can have more than one role, and (generally) a person only needs one of their assigned roles to grant access in order for them to have access. Note that RBAC is not a specific implementation but, rather, a general architecture of how to describe access controls.

Generally RBAC systems are implemented as a rule base where each rule is of the form "role X can do Y to objects of type Z", and wildcards can be used to factor the rule base. When asked "Can person P do Y to z?", the roles of P are looked up, the type of z is determined, and the rule base is consulted to yield a yes or no answer. In an ideal world, authentication clients (i.e. programs that need to know if "P can do Y to z") would query this RBAC system directly. However, since LDAP is designed to answer queries like "what's the value of this field?" what usually happens is that we put this access control logic into the client.

For the structure part, the goal would be a factory which given a person would create an object that describes the schema of the person's LDAP entry. Or. equivalently, the returned object could be something that can create the person's LDAP entry. Since schemas are hierarchical in nature (i.e. Students and Faculty are UniversitySubjects which are Persons, etc.), you might be able to use class inheritance here to factor out common behavior. Another possibility is that this object could be a composition of smaller objects which know how to create sub-parts of the schema. Calling create_ldap_entry on the top level object invokes the same call on its constituent objects (with different contexts, i.e. a different root), and this process builds the entire record.

The way the two parts would work together is as follows: given a person the factory is consulted to produce the correct schema object. The schema object can interact with the RBAC system to compute the values of certain fields which are related to access control and need to take into account all the roles that a person has. For instance, if there is a field 'can_use_dialup' which should be true only for faculty, an RBAC system will compute this correctly if a person happens to be a student and a faculty member.

Again, this is just throwing some ideas out there. Does any of them seem applicable to your situation?