[OPENDJ-6893] Document ACI for regular user to access changelog attributes in root DSE Created: 06/Jan/20  Updated: 25/Feb/20  Resolved: 03/Feb/20

Status: Done
Project: OpenDJ
Component/s: documentation
Affects Version/s: 6.5.2, 7.0.0
Fix Version/s: 6.5.3, 7.0.0

Type: Bug Priority: Minor
Reporter: Wei-Yee Lum Assignee: Michal Severin [X] (Inactive)
Resolution: Fixed Votes: 0
Labels: Verified

Epic Link: Bugs 7.0
Story Points: 0.5
Dev Assignee: Mark Craig
QA Assignee: Michal Severin [X] (Inactive)
Support Ticket IDs:


DS 6.5 admin guide has:



To Allow a User to Read the Change Log
For a user to read the changelog, the user must have access to read, search, and compare changelog attributes, might have access to use the control to read the external changelog, and must have the changelog-read privilege.



Additionally, the user may also need access to read changelog-related attributes in the root DSE (e.g. IDM 6.5 requires this for liveSync to work, if not using "cn=directory manager"):

ds-cfg-global-aci: (target="ldap:///")(targetscope="base")(targetattr="changeLog||firstChangeNumber||lastchangenumber")(version 3.0; acl "Root DSE changelog attrs for livesyncuser"; allow (read) userdn="ldap:///uid=livesyncuser,dc=example,dc=com";)


Comment by Mark Craig [ 06/Jan/20 ]

The docs at https://backstage.forgerock.com/docs/ds/6.5/admin-guide/#read-ecl-as-regular-user do show an ACI for this. That ACI doesn't limit the list of attributes that the user can read.

A patch could be to show this in the section on example ACIs, including the restriction on the list of attributes to read.

Comment by Wei-Yee Lum [ 06/Jan/20 ]

The ACI at https://backstage.forgerock.com/docs/ds/6.5/admin-guide/#read-ecl-as-regular-user is for target="ldap:///cn=changelog" ... whereas what is missing is for the root DSE

Comment by Mark Craig [ 06/Jan/20 ]

Hmm, I thought that since LDAP servers advertise their capabilities through the operational attributes on the root DSE that directory administrators would generally leave the root DSE publicly readable. Up to 6.5 the root DSE is readable by default, as described in https://backstage.forgerock.com/docs/ds/6.5/admin-guide/#about-acis. Unless I got this wrong in the docs, the root DSE is readable by default in production mode as well, https://backstage.forgerock.com/docs/ds/6.5/install-guide/index.html#ds-setup-options.

It's true that if access to the root DSE is restricted, then the additional ACI is necessary. What are the circumstances for restricting read access to the root DSE entry?

Comment by Wei-Yee Lum [ 06/Jan/20 ]

I tested on DS 6.5 with default ACIs (not production mode).

The default ACI for root DSE allows access to only some attributes, not the changelog-related ones:


User-Visible Root DSE Operational Attributes Anonymous and authenticated users can read attributes that describe what the server supports. Modification or removal may affect applications. (target="ldap:///")(targetscope="base")(targetattr="objectClass||namingContexts||supportedAuthPasswordSchemes||supportedControl||supportedExtension||supportedFeatures||supportedLDAPVersion||supportedSASLMechanisms||supportedTLSCiphers||supportedTLSProtocols||vendorName||vendorVersion")(version 3.0; acl "User-Visible Root DSE Operational Attributes"; allow (read,search,compare) userdn="ldap:///anyone"
Comment by Ludovic Poitou [ 06/Jan/20 ]

This is normal. The ACI above is granting anonymous access to these attributes. They are not specific for a user.

This said, I don't think there is any information leakage by allowing anyone to read the first and last change numbers.

Comment by Chris Ridd [ 06/Jan/20 ]

Mark Craig the main driver for restricting access to the root DSE that is seen in support tickets is that admins get a security scan identifying non-authenticated services, or are otherwise required to implement a security policy that wasn't written with a practical understanding of how LDAP clients work, viz reading the root anonymously. So the admins ask how to restrict access, and then usually follow up saying all their apps are broken.

Reading first/last changenumbers is a small information leak because it shows how many writes the server is taking. Commercial CAs that issued certs with a simple incrementing serial number had a similar issue - competitors could just buy a cert and see what their sales were.

Having said that I can't see that this small information leak buys anyone much.

Comment by Mark Craig [ 07/Jan/20 ]

Although IDM doesn't use changelog cookies, lastExternalChangeLogCookie is perhaps worth including in the list of attributes.

Comment by Mark Craig [ 07/Jan/20 ]

Fixed on the master and 6.5.x branches. The fix will be visible in the DS 6.5 docs the next time they are published externally.

Comment by Michal Severin [X] (Inactive) [ 03/Feb/20 ]


Generated at Sun Jan 17 00:24:02 UTC 2021 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.