Bug 766322
Summary: | [RFE] Please support setting defaultNamingContext in the rootdse. | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Dmitri Pal <dpal> |
Component: | 389-ds-base | Assignee: | Rich Megginson <rmeggins> |
Status: | CLOSED ERRATA | QA Contact: | IDM QE LIST <seceng-idm-qe-list> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.0 | CC: | gspurgeon, iheim, jgalipea, mkosek, nhosoi, sgallagh, ssorce |
Target Milestone: | rc | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | 389-ds-base-1.2.10.0-1.el6 | Doc Type: | Enhancement |
Doc Text: |
Cause: LDAP clients not configured with a search base attempting to search against the directory server.
Consequence: There was no easy way to determine what default search base to use.
Change: Added a new attribute to the root DSE (the entry with the empty dn "") called defaultNamingContext. This allows clients to easily discover what search base to use.
Result: Clients can query the root DSE for the defaultNamingContext, then use that to search for users, etc.
|
Story Points: | --- |
Clone Of: | 742317 | Environment: | |
Last Closed: | 2012-06-20 07:11:36 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 742317 | ||
Bug Blocks: | 495079, 690319 |
Comment 1
Rich Megginson
2012-01-06 23:50:32 UTC
Copied from https://fedorahosted.org/389/ticket/26 Steps to verify: 1. install DS (preferably with the admin server and Console) 2. Search nsslapd-defaultnamingcontext in cn=config and defaultnamingcontext in the rootdse. $ ldapsearch -LLLx -h localhost -p <port> -D 'cn=directory manager' -w <pw> -b "cn=config" -s base nsslapd-defaultnamingcontext dn: cn=config nsslapd-defaultnamingcontext: <default suffix (e.g., dc=example,dc=com)> $ ldapsearch -LLLx -h localhost -p <port> -b "" -s base | egrep namingcontext namingContexts: dc=example,dc=com defaultnamingcontext: dc=example,dc=com 3. Add a new suffix "dc=test,dc=com" and verify nsslapd-defaultnamingcontext and defaultnamingcontext are not changed. 4. Remove the new suffix "dc=test,dc=com" and verify nsslapd-defaultnamingcontext and defaultnamingcontext are not changed. 5. Remove the original suffix "dc=example,dc=com" and verify nsslapd-defaultnamingcontext and defaultnamingcontext are both removed. $ ldapsearch -LLLx -h localhost -p <port> -D 'cn=directory manager' -w <pw> -b "cn=config" -s base nsslapd-defaultnamingcontext dn: cn=config nsslapd-defaultnamingcontext: $ ldapsearch -LLLx -h localhost -p <port> -b "" -s base | egrep namingcontext $ 6. Add a new suffix "dc=newtest,dc=com" and verify the new suffix is set to nsslapd-defaultnamingcontext and defaultnamingcontext. $ ldapsearch -LLLx -h localhost -p <port> -D 'cn=directory manager' -w <pw> -b "cn=config" -s base nsslapd-defaultnamingcontext dn: cn=config nsslapd-defaultnamingcontext: dc=newtest,dc=com $ ldapsearch -LLLx -h localhost -p 10389 -b "" -s base | egrep namingcontext namingContexts: dc=newtest,dc=com defaultnamingcontext: dc=newtest,dc=com QE automation complete for this feature Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: LDAP clients not configured with a search base attempting to search against the directory server. Consequence: There was no easy way to determine what default search base to use. Change: Added a new attribute to the root DSE (the entry with the empty dn "") called defaultNamingContext. This allows clients to easily discover what search base to use. Result: Clients can query the root DSE for the defaultNamingContext, then use that to search for users, etc. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2012-0813.html |