When multiple naming contexts are available it is hard to find out what a client should use by default (usually the identity mgmt related tree where to find users/groups). It would be really helpful to allow cn=Directory Manager to be able to write the 'defaultNamingcontext' attribute to the rootdse so that clients do not need to do strange probings. AD and also openldap apparently have it so many clients already know how to handle this attribute.
Upstream ticket: https://fedorahosted.org/389/ticket/26
It looks Active Directory supports defaultNamingContext: defaultNamingContext: This is the default NC for a particular server. By default, the DN for the domain of which this directory server is a member. But I could not find it in the openldap code. (Only namingContexts was found.) Could this usage work for you? . If no namingContexts are found, none is assigned to defaultNamingContext. . When the first namingContext is added, it will be assigned to defaultNamingContext. . Once one namingContext (e.g., dc=test,dc=com) is assigned to defaultNamingContext, the following config attribute is added to cn=config: defaultNamingContext: dc=test,dc=com . It could be switched to other namingContext by replacing the value. The modify fails if the new value is not found in the namingContexts. . If the namingContext is removed (i.e., the backend as well as the suffix are deleted), the defaultNamingContext is removed, as well.
(In reply to comment #5) > It looks Active Directory supports defaultNamingContext: > defaultNamingContext: This is the default NC for a particular server. By > default, the DN for the domain of which this directory server is a member. > > But I could not find it in the openldap code. (Only namingContexts was found.) > > Could this usage work for you? > . If no namingContexts are found, none is assigned to defaultNamingContext. > . When the first namingContext is added, it will be assigned to > defaultNamingContext. > . Once one namingContext (e.g., dc=test,dc=com) is assigned to > defaultNamingContext, the following config attribute is added to cn=config: > defaultNamingContext: dc=test,dc=com > . It could be switched to other namingContext by replacing the value. The > modify fails if the new value is not found in the namingContexts. > . If the namingContext is removed (i.e., the backend as well as the suffix are > deleted), the defaultNamingContext is removed, as well. What about demotion? For example, you add the first domain. It becomes the default. Next, you add a second domain. Later, you decide to remove the first domain. I think there should be some logic in place to promote one of the remaining namingContexts entries to be the defaultNamingContext. I'm not sure what algorithm to use to determine which one to promote (if there are multiple options), but I think it needs to be planned out.
(In reply to comment #6) > What about demotion? For example, you add the first domain. It becomes the > default. Next, you add a second domain. Later, you decide to remove the first > domain. I think there should be some logic in place to promote one of the > remaining namingContexts entries to be the defaultNamingContext. I was thinking just to remove defaultNamingContext: <first_domain> It leaves empty defaultNamingContext. If a new suffix is added after that, it'll be set to defaultNamingContext. Otherwise, it remains empty... > I'm not sure what algorithm to use to determine which one to promote (if there > are multiple options), but I think it needs to be planned out. If this is necessary, we are open to your suggestion. ;)
I think if we remove the naming context equivalent to the defaultNamingContext, we should remove the defaultNamingContext entirely, rather than leaving it empty. We can then re-add it on the next suffix addition (or manually set it appropriately). This will behave better with SSSD, as an empty defaultNamingContext will cause issues with auto-detection.
(In reply to comment #8) > I think if we remove the naming context equivalent to the defaultNamingContext, > we should remove the defaultNamingContext entirely, rather than leaving it > empty. We can then re-add it on the next suffix addition (or manually set it > appropriately). > > This will behave better with SSSD, as an empty defaultNamingContext will cause > issues with auto-detection. Thanks, Stephen! I'll change the behavior as you suggested. Please let me know when you come up any new idea.
Fixed. See https://fedorahosted.org/389/ticket/26#comment:16 for steps to verify.