Has anyone come up with a workaround to work with duplicate user names? In our situation it is going to be VERY difficult to avoid duplicate users because of our tree structure.

We are a K-12 school district with 25+ physical school locations and 24,000 students The tree has to be partitioned by school site due to WAN links. It is often the case that a student may be taking classes at 2 to 4 schools and require user accounts at all of them. This has never been an issue before because all Novell or LDAP connected systems we encountered accounted for login context in some way.

They get the right mapped drives and are connected to the right server but Zen finds the first instance of their account seemingly alphabetically and gives policies and bundles from whatever the first school it finds the account in.

I thought of a work around using aliases but Zen doesnt support aliases either?? Come on!

With careful, time consuming care I could create special rules of each of thousands but bundles and policies to get them to apply at only the right locations, and with a very complicated account creation script I could have account duplicates found and have them added to groups cross-site but this will get rediculous very quickly and it will become impossible to track down problems in the future.

What about telling everyone to use different passwords, which is impossible to enforce. Doesnt that cause login failures and intruder lockouts or does Zen account for that... I'd think its doubtful considering they dont account for login context.

Does anyone know why the context is not accounted for? I've written a few ldap connected applications and had no problem matching the current user's nds context with the ldap tree. It could at the very least be an optional feature.