freeipa

FreeIPA is an integrated Identity and Authentication solution for Linux/UNIX networked environments.  |  http://www.freeipa.org/

#1919 FreeIPA needs sensible namingContexts and defaultNamingContext values

Created 6 years ago by sgallagh
Modified 2 years ago

Right now, FreeIPA is set up with a single namingContexts, which is the 'dc=example,dc=com' root of the LDAP tree. The problem is that this search domain encompasses both the standard cn=accounts and the cn=compat trees. This means that SSSD, if set up as an RFC2307bis client instead of a full ipa-client-install (which explicitly sets the search base to cn=accounts) cannot safely auto-detect the search base to use.

I think that FreeIPA should ship with the following settings in the RootDSE:

defaultNamingContext: cn=accounts,dc=example,dc=com
namingContexts: dc=example,dc=com
namingContexts: cn=accounts,dc=example,dc=com

and if compat mode is also enabled:

defaultNamingContext: cn=accounts,dc=example,dc=com
namingContexts: dc=example,dc=com
namingContexts: cn=accounts,dc=example,dc=com
namingContexts: cn=compat,dc=example,dc=com

This will allow us to auto-detect search bases in a sane way, as well as allowing us to easily communicate to clients that compat mode is or is not enabled.

Such support is also dependent upon the 389 DS bug https://bugzilla.redhat.com/show_bug.cgi?id=742317

I have to disagree here.
This is how we should have it (configurable for backwards compatibility).

defaultNamingContext: dc=example,dc=com
namingContext: dc=example,dc=com
namingContext: cn=compat

What you proposed is not doable for a number of reasons, one of them being that namingContext is automatically generated by DS base on the database backends beeing configured.

If the compat tree isn't placed inside of an existing naming context, then access controls won't be applied properly.

Is this something that providing configuration information a la RFC4876 would help solve?

Replying to [comment:2 nalin]:

If the compat tree isn't placed inside of an existing naming context, then access controls won't be applied properly.

The plan is to create a new naming context for you.
So we would turn cn=compat into an actual additional database where we can store ACIs
I guess this means you need to create only the subtrees below cn=compat itself, but that change shouldn't be a big deal, is it ?

Replying to [comment:3 nalin]:

Is this something that providing configuration information a la RFC4876 would help solve?

Nope, because we already use it to redirect legacy clients that support it to the compat tree, so it would cause SSSD to attach to the wrong tree altogether.

Moving to January, not fixed upstream yet.

Upstream ticket is closed https://fedorahosted.org/389/ticket/26 available in 389-ds-base-1.2.10-0.9.a8

A defaultNamingContext is not set in upgraded instances.

Moving to next month iteration.

master: e889b82[[BR]]
ipa-2-2: c9e0473

2 years ago

Metadata Update from @sgallagh:
- Issue assigned to rcritten
- Issue set to the milestone: FreeIPA 2.2 Core Effort - 2012/02

Login to comment on this ticket.

defect

IPA

1

https://bugzilla.redhat.com/show_bug.cgi?id=742317

cancel