searchBaseDn value default
to an non existent DN into the default ADS
In-Reply-To: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
[
https://issues.apache.org/jira/browse/DIRSERVER-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRSERVER-945:
----------------------------------------
Fix Version/s: 1.5.1
Not sure this is still a problem, I think the doco has been improved.
I gonna double check it
> <!-- The base DN containing users that can be SASL authenticated.
> -->
searchBaseDn value default to an non existent DN into the default ADS
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DIRSERVER-945
> URL: https://issues.apache.org/jira/browse/DIRSERVER-945
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.5.0
> Reporter: Emmanuel Lecharny
> Assignee: Enrique Rodriguez
> Fix For: 1.5.1
>
>
> When launching the server without any configuration, each bind request
> produce an exception because the ConigureChain is looking for a searchBaseDn
> entry, which default to "ou=users,dc=example,dc=com" in server.xml :
> <!-- The base DN containing users that can be SASL authenticated.
> -->
> <property name="searchBaseDn" value="ou=users,dc=example,dc=com" />
> There are two problems with this value
> - this DN does not exists in the DIT, so the lookup will always fail
> - when using SIMPLE authentication, the server should *not* issue a lookup fo
> this DN which is dedicated to SASL, AFAIK.
> Note that the documentation is not clear about what is this searchBaseDN :
> "The single location where entries are stored. The definition of "entries"
> depends on the protocol. For example, for LDAP, Kerberos, and Change
> Password, entries are users for purposes of authentication. For DNS, entries
> are resource records. If this property is not set the store will search the
> system partition configuration for catalog entries. Catalog support is highly
> experimental and is only tested in the OSGi build of ApacheDS using the
> Config Admin service."
> We are using partitions to store data, "ou=system" is one of those partition,
> "dc=example, dc=com" is another one, but as partitions should *not* overlap,
> "ou=users,dc=example,dc=com" can't be a partition. Of course, *if* this is a
> partition, which is not clear for me reading the above explanaition.
> It would be good to improve this part of the doco for better clarity.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
