Bug 742317

Summary:	Please support setting defaultNamingContext in the rootdse.
Product:	[Retired] 389	Reporter:	Simo Sorce <ssorce>
Component:	Directory Server	Assignee:	Rich Megginson <rmeggins>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Ben Levenson <benl>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	1.2.9	CC:	mkosek, nhosoi, sgallagh
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	766322 (view as bug list)		Environment:
Last Closed:	2015-12-10 18:42:33 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:
Bug Blocks:	495079, 690319, 766322

Description Simo Sorce 2011-09-29 16:51:10 UTC

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 13:20:45 UTC

Upstream ticket:
https://fedorahosted.org/389/ticket/26

Comment 5 Noriko Hosoi 2012-01-09 23:30:05 UTC

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-10 01:36:16 UTC

(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-10 01:53:45 UTC

(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 12:31:14 UTC

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 16:59:41 UTC

(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 18:52:00 UTC

Fixed.

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