Or may be just use the DS views.
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/using-views.html

Any plans about adding support for custom OU structures to IPA ? Multitenancy is one of the usecases.. there's a lot of software that needs specific OU structure, which unfortunately isn't possible with IPA as of today.

It seems that it would be easier to accomplish the same via IPA to IPA trusts. At least that capability would be available much earlier than adding back OUs.

Here's an example of LDAP / OU structure that is needed by many (multitenant) applications out there..

OU=tenants,DC=example,DC=org
   |
   OU=tenant1,OU=tenants,DC=example,DC=org
   |  |-OU=groups_of_tenant1,OU=tenant1,OU=tenants,DC=example,DC=org
   |  |-OU=users_of_tenant1,OU=tenant1,OU=tenants,DC=example,DC=org
   |
   OU=tenant2,OU=tenants,DC=example,DC=org
   |  |-OU=groups_of_tenant2,OU=tenant2,OU=tenants,DC=example,DC=org
   |  |-OU=users_of_tenant2,OU=tenant2,OU=tenants,DC=example,DC=org
   |
   OU=tenantX,OU=tenants,DC=example,DC=org
   |  |-OU=groups_of_tenantX,OU=tenantX,OU=tenants,DC=example,DC=org
   |  |-OU=users_of_tenantX,OU=tenantX,OU=tenants,DC=example,DC=org
   |

Replying to [comment:7 pasik]:

Here's an example of LDAP / OU structure that is needed by many (multitenant) applications out there..
{{{
OU=tenants,DC=example,DC=org
|
OU=tenant1,OU=tenants,DC=example,DC=org
| |-OU=groups_of_tenant1,OU=tenant1,OU=tenants,DC=example,DC=org
| |-OU=users_of_tenant1,OU=tenant1,OU=tenants,DC=example,DC=org
|
OU=tenant2,OU=tenants,DC=example,DC=org
| |-OU=groups_of_tenant2,OU=tenant2,OU=tenants,DC=example,DC=org
| |-OU=users_of_tenant2,OU=tenant2,OU=tenants,DC=example,DC=org
|
OU=tenantX,OU=tenants,DC=example,DC=org
| |-OU=groups_of_tenantX,OU=tenantX,OU=tenants,DC=example,DC=org
| |-OU=users_of_tenantX,OU=tenantX,OU=tenants,DC=example,DC=org
|
}}}

Would a set of containerized IPA servers one per tenant in trust relations with each other solve the problem?
I would also be much easier to delegate some of the administration to tenant's power users. Would that work for you or you see some architectural issues with such approach?

Well, it probably will help some cases, but there's service provider software out there which needs the LDAP structure as I described above..

Meaning all the tenants need to exist in a single directory, each tenant as separate OU.. so then containerized IPA servers in trust relationship wouldn't help with those cases unfortunately.

Replying to [comment:9 pasik]:

Meaning all the tenants need to exist in a single directory, each tenant as separate OU.. so then containerized IPA servers in trust relationship wouldn't help with those cases unfortunately.

I do not think this would happen any time soon. It might be easier to update service provider software to not assume OUs.

It seems I forgot to reply earlier, so here goes.

I think it's a mistake to not support OUs in IPA.

Let's say you have 1000 (just a random number) different tenants/organizations/customers.. that'd mean running 1000 separate freeipa instances/containers (or more, if in HA configuration), each configured for trust relationship with the 'master organization'. That's a lot of containers.. when the alternative is to run one instance of LDAP (well, in HA configuration), and leverage OU structure to accomplish the multi-tenancy.. (which is a very common usage model of LDAP).

For example with Active Directory OU structures are widely used to implement multi-tenancy and/or to delegate management permissions of certain Organization Units to different users.. and to 'model' the corporate structure to AD using OUs.

389 Directory Server also supports similar features on the LDAP level, it's only IPA which doesn't have the support for OUs / hierarchies currently.

Thank you taking time to submit this request for FreeIPA. Unfortunately this bug was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfil this request I am closing the issue as wontfix. To request re-consideration of this decision please reopen this issue and provide additional technical details about its importance to you.