Delegated Admin and non-flat user/group structures

Question

Hello, I am trying to build a directory structure with several containers under an organization used to store different portions of userdata and group data (i.e. not only ou=people and ou=group, but also a few ou's like them). Server software is from OUCS 7u2 release. Users in "other" containers are populated into LDAP (ODSEE 11) by replication, filling in all the same attributes as a freshly DA-created account has.
The Delegated Admin interface and other parts of the software accept this and work okay with this setup, displaying user information, allowing logins and so on - except for attempts to edit user accounts in the alternate containers in the DA (i.e. add/remove service packages, change quotas, etc.). First I've verified that this is not an LDAP problem - I can use both command-line ldapmodify and an LDAPBrowser GUI to edit the entries with no hiccups.
I tracked that when trying to save account information for accounts in non-standard containers, the DA still tries to use a hard-coded path (i.e. uid=USERNAME,ou=people,o=DOMAINNAME,dc=DOMAIN,dc=NAME) despite the fact that the user account is (and DA displayed it from) uid=USERNAME,ou=morePeople,o=DOMAINNAME,dc=DOMAIN,dc=NAME.
Possibly, this "hardcoding" stems from DA configuration in WEB-INF/classes/sun/comm/cli/server/servlet/serverconfig.properties which does list components of the LDAP structure:
# Ldap configuration.
# List of ldap hosts. Form is <ldaphost>:<portnumber>. (Default port = 389)
# add additional hosts with ldaphost-<consecutive number>
# Schema type is either "1" or "2".
# Reconnect interval is in seconds
# Group and people container is dn from organization dn (e.g ou=people)
ldaphost-1=oucsldap01:389
ldaphost-2=oucsldap02:389
ldaphost-suffix=dc=DOMAIN,dc=NAME
ldaphost-dcsuffix=dc=DOMAIN,dc=NAME
ldaphost-maxcount=50
ldaphost-schematype=2
ldaphost-reconnectinterval=60
ldaphost-peoplecontainer=ou=People
ldaphost-groupcontainer=ou=Groups
ldaphost-orgadminrole=cn=Organization Admin Role
While the organization root dn is not explicit here (and shouldn't be), the default people container is... I might guess a coding error logic like this: indeed, the "ou=People" container should be used by default when creating a user via DA; as a likely error, it might also be used when editing existing users - instead of their existing full DN/parent DN.
Questions:
1) Does anyone have a working configuration with several user/group containers within an organization like this? Would you care to share details and workarounds, if were needed?
2) I think that possibly the "shared domain/organization hosting" mode might help here - at least it is expected to have several LDAP trees with their delegated administrators performing as a single e-mail domain. Before I go and reconfigure everything, I'd love to hear if there are any success stories with this route? Is it a proper solution (or THE solution) for such config?
Thanks,
//Jim Klimov

Answer 1

I wanted to follow up that reconfiguring the directory structure according to shared domain hosting, with branches for ISW-synchronized accounts as one of the sub-organizations which share the domain, and manually created OUCS-only accounts being in another sub-organization. This works for both messaging components and the DA, as long as UIDs are in ou=People in their organization. Somewhat unfortunately, ISW config seems to allow only one DSEE target branch and puts groups (CN) there as well. Well, for our needs to edit user attributes and service packages via DA, this suffices. Sometimes there are hiccups (Can not save changes), but they are intermittent and harder to trace debug; usually go away with restart of the DA web container. The DSEE LDAP instances are configured with plugins to enforce uid uniqueness across the organization and uniqueness of values of messaging email address attributes (mail, mailAlternateAddress, mailEqiuvalentAddress) to avoid mixups between user accounts in different branches.
Also, we had a problem with Calendar server after migrating the LDAP entries: since our deployment used the nsUniqueID for calendar user identification, relocation of entries (the way we did it) generated new values for new entries and users got new empty caledar databases. On this POC this was not a major problem, and newer OUCS releases with a davUniqueID attribute should specifically be immune to this problem. However, for others trodding this path I can suggest that they export the LDAP database into LDIF including the unique IDs, recreate the suffixes as needed (the ISW target organization in DSEE should be a separate LDAP database suffix), change the LDIF entry pathnames, and import the LDIF anew. This would wipe old LDAP data and should add old nsUniqueIDs to relocated entries (unlike recreation via ldapadd or relocation via ldapmodrdn).
We have also hit a problem with DA refusing to render the list of accounts (returning 0 or 25 empty entries in a table). The LDAP logs showed that on the LDAP side all is ok, and expected amount of replies was located. Pattern searches often produced the proper table with a subset of users in DA. Ultimately, we linked the problem to ISW binary base64-encoded attributes (dspswuserlink et al; some of those values also garbaged output of commadmin queries in a terminal) and created an LDAP ACI which forbade our DA-admin user to read,search,compare these attributes. This solved the problem for us. I wonder if a more generic solution is possible, so as to apply this ACI not to an explicitly named admin user but to any users with DA admin privileges (by group or role? which string, to cover them all in advance)? Or, perhaps, nobody except the ISW user account should see these ISW attributes?
Hope this report helps others who would try to pioneer this path of messaging integration
//Jim Klimov