Bug 742317 - Please support setting defaultNamingContext in the rootdse.
Please support setting defaultNamingContext in the rootdse.
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Directory Server (Show other bugs)
1.2.9
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Rich Megginson
Ben Levenson
:
Depends On:
Blocks: 389_1.3.0 690319 766322
  Show dependency treegraph
 
Reported: 2011-09-29 12:51 EDT by Simo Sorce
Modified: 2015-12-10 13:42 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 766322 (view as bug list)
Environment:
Last Closed: 2015-12-10 13:42:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Simo Sorce 2011-09-29 12:51:10 EDT
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.
Comment 4 Martin Kosek 2012-01-04 08:20:45 EST
Upstream ticket:
https://fedorahosted.org/389/ticket/26
Comment 5 Noriko Hosoi 2012-01-09 18:30:05 EST
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.
Comment 6 Stephen Gallagher 2012-01-09 20:36:16 EST
(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.
Comment 7 Noriko Hosoi 2012-01-09 20:53:45 EST
(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. ;)
Comment 8 Stephen Gallagher 2012-01-10 07:31:14 EST
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.
Comment 9 Noriko Hosoi 2012-01-10 11:59:41 EST
(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.
Comment 10 Noriko Hosoi 2012-01-18 13:52:00 EST
Fixed.

See https://fedorahosted.org/389/ticket/26#comment:16 for steps to verify.

Note You need to log in before you can comment on or make changes to this bug.