Two Tiered DIT Hierarchy with Shared Organizations
I'm trying to migrate a legacy schema 1 DIT to schema 2. In the old DA we had it set up with separate admin accounts for billing and support.
ou=people,o=billing,o=corp.palooza.com,dc=palooza,dc=com
ou=people,o=support,o=corp.palooza.com,dc=palooza,dc=com
Both organizations, billing and support, share the corp.palooza.com mail domain. Each would have a separate orgaizational admin.
In the DA Guide, it appears the way to share the same mail domain is to create shared organizations via sunOrgType: shared. But it seems to also imply that to do that we would need to implement SPAs. The DIT structure for doing that seems more complicated than we would like if we were to use the da.provider.skeleton.ldif to create the SPAs.
What we would like to do is use a two tiered hierarchy as shown in the example in the 2005q4 DA Guide, but instead of full orgs as in the example (pg 28), use shared orgs via "sunOrgType: shared" attribute.
Is this allowed?
Is there a good example with the needed objecclasses and attrs?
Thanks for any guidance offered!
[1106 byte] By [
thekeipher] at [2007-11-26 9:36:58]
# 1
In general, anything you can do in Schema 1 can be done in Schema 2. Schema 1 is a subset of Schema 2.
The basic difference is that with Schema 1, you have a separate DC tree for domains. Schema 2 typically places that same data in the main tree.
What you describe should work the same for Schema 2 as it did for Schema 1.
# 2
Yes but we want to be able to utilize delegate administration using the DA. I tried to make two test orgs in this fashion. They work as far as ldap was concerned but the DA couldn't add/mod/delete users.
Here's the ldif used to create them:
dn: o=Billing,o=corp.palooza.com,dc=palooza,dc=com
o: Billing
objectClass: top
objectClass: inetdomainauthinfo
objectClass: sunismanagedorganization
objectClass: sunnamespace
objectClass: sunmanagedorganization
objectClass: sundelegatedorganization
objectClass: maildomain
objectClass: organization
sunRegisteredServiceName: DomainMailService
sunRegisteredServiceName: GroupMailService
sunRegisteredServiceName: iPlanetAMAuthLDAPService
sunRegisteredServiceName: UserMailService
sunRegisteredServiceName: iPlanetAMAuthService
sunOrgType: shared
sunNumUsers: 0
sunNameSpaceUniqueAttrs: uid
sunPreferredDomain: corp.palooza.com
inetDomainStatus: active
mailDomainStatus: active
preferredMailHost: bigun-10.palooza.com
sunAvailableServices: defaultmail:0:0
sunAvailableServices: gold:100:1
sunMaxUsers: 20000
sunEnableGAB: true
sunAllowMultipleServices: true
dn: o=Support,o=corp.palooza.com,dc=palooza,dc=com
o: Support
objectClass: top
objectClass: inetdomainauthinfo
objectClass: sunismanagedorganization
objectClass: sunnamespace
objectClass: sunmanagedorganization
objectClass: sundelegatedorganization
objectClass: maildomain
objectClass: organization
sunRegisteredServiceName: DomainMailService
sunRegisteredServiceName: GroupMailService
sunRegisteredServiceName: iPlanetAMAuthLDAPService
sunRegisteredServiceName: UserMailService
sunRegisteredServiceName: iPlanetAMAuthService
sunOrgType: shared
sunNumUsers: 0
sunNameSpaceUniqueAttrs: uid
sunPreferredDomain: corp.palooza.com
inetDomainStatus: active
mailDomainStatus: active
preferredMailHost: bigun-10.palooza.com
sunAvailableServices: defaultmail:0:0
sunAvailableServices: gold:100:1
sunMaxUsers: 20000
sunEnableGAB: true
sunAllowMultipleServices: true
Each had a people ou:
dn: ou=People,o=Billing,o=corp.palooza.com,dc=palooza,dc=com
objectClass: top
objectClass: organizationalUnit
objectClass: iplanet-am-managed-people-container
ou: People
dn: ou=People,o=Support,o=corp.palooza.com,dc=palooza,dc=com
objectClass: top
objectClass: organizationalUnit
objectClass: iplanet-am-managed-people-container
ou: People
# 3
Unfortunately, DA is pretty limited.There are many places where something works when done in ldap, and the messaging server is happy to use it, but DA can't deal with it.
# 4
I makes me want to ask what DA really stands for. :)
We are slated to use the DA as that is what people here are trained on. Thus I need to find some solution to configuring the DA to work with these two org. I'm free to rearrange the DIT, but we do want to keep it simple. If you can point me to and extra documentation that may help it would be great.
If I hammer out a solution I'll let you know!
Keith
# 5
I suggest you engage Tech Support, or perhaps Professional Services.I know of no way to support the DIT you have chosen with DA.perhaps you could manage it with subdomains, or something like that.
# 6
I realized early on that DA didn't come close to doing what I need. I create users and do other admin functions using PHP scripts that modify LDAP directly. PHP has really good LDAP support, so its pretty easy to do this. If DA does mostly what you want, I'd create a set of PHP pages to do the rest.
I can see a couple of ways to do this. I would make your user provisioning add mailalternateaddress=user@corp.palooza.com to all users. At least with our setup that would let members of both organizations get mail at the same domain.
However if you can't do that, there's a weirder approach. In imta.cnf, do an LDAP lookup to figure out which domain the user is in and rewrite the address to go to it. You need to use $] to look up the user in each domain and if it succeeds rewrite to the appropriate domain. This would become unreasonable if you had lots of domains or a very high mail volume, but in your case it probably will work.
# 7
because the LDAP operation is not well documented, let me give you a sample rule from my imta.cnf. It's not at all what you want, but at least will show you how to use an LDAP lookup:
$* $A$E$F$U%$]ldap:///o=rulink-top?sunPreferredDomain?sub?(&(|(associatedDomai n=$H)(sunPreferredDomain=$H))(!(mailDomainStatus=inactive)))[$V$H$Tlocal|
We have lots of domains ending in .rutgers.edu. How do I know which ones to accept mail from? I can't just say .rutgers.edu, because that would accept mail from domains hosted by servers elsewhere on campus. But there are too many domains on my own system to list them in imta.cnf, not to mention the fact that domains are created by people who I don't want modifying imta.cnf. So the rule above looks up the hostname and if it's defined as a domain in my LDAP, it treats the mail as local. If I hosted everything ending in .rutgers.edu I could asy
.rutgers.edu $U%$H@rullnk.rutgers.edu
or perhaps $H.rutgers.edu; I forget. That's roughly what that rule does, but it does an LDAP lookup to make sure that I'm hosting the domain. Rather than rewriting the destination to @rulink.rutgers.edu (our local system), it sticks a tag local| on it, because of complexities in processing later that are irrelevant here.
# 8
I ended up creating a three tiered service provider structure utilizing the da.provider.skeleton.ldif file and using awk to replace the needed values. This is described in the 2005q4 DA guide. It basically works. One annoying feature is that when selecting the parent organization in the DA, a concatenated list the users of the two subordinate orgs are listed as well as the users in the parent org. With about 10k users total it's a long list. I could probably muck about and fix that, but my client is satisfied so I didn't spend any time on it.
On the upside, the two org trees can share a email domain, have independent delegated administration, and users can be managed via the DA interface. Also, the resulting org structure wasn't as ugly as the o=business example privided with the DA in which the user orgs are buried way down in the DIT:
uid=test_user2,ou=People,o=DEF,o=VIS,o=siroe.com,o=SharedDomainsRoot,o=Business ,dc=company,dc=net
Too much clutter for me, but some may enjot it :).
