cn=Directory Manager

cn=Directory Manager
All about Directory Server

All | Personal | Sun

« Frequently-Asked... | Main | Tuning the Number of... »

Friday January 27, 2006

Frequently-Asked Questions #4: Default Access Controls

Q: I ran [security product X] against the Directory Server and it raised concerns about anonymous access to entries like cn=schema, cn=monitor and the root DSE (aka null DN). Is this something I should be worried about? Can I disable this anonymous access?

A: I'll refrain from naming the security product at fault in this case, and I have no direct experience with some of the worst offenders, but it's pretty clueless in the area of Directory Server security. I also frequently hear Sun's security experts grumbling about stupid behaviors in other areas like looking at file permissions, so I would strongly suggest that you take anything that any of these tools report with a grain of salt.

First, let me say that yes, it is possible to configure access controls to prevent anonymous access to these entries if that is something that you decide really is necessary. In fact, they all already have a default set of ACIs that provide access to these entries out-of-the-box. For each of these entries, simply replacing "ldap:///anyone" with "ldap:///all" will accomplish this, since "all" refers to all authenticated users whereas "anyone" is all plus anonymous. However, before you do this, you should consider the possible implications that it may have.

There are definitely valid reasons that a client might need to have anonymous access to the root DSE. The whole point of the root DSE is to provide clients with information about the capabilities of the Directory Server so that they can understand how to interact with it. This includes information about the types of supported controls and extended operations that are available, as well as the supported SASL mechanisms that might impact the manner that the client should use to authenticate. Therefore, any client that expects to have access to this information anonymously could break if the default permissions are altered.

Just as some clients expect to have anonymous access to the root DSE so that they can understand what capabilities the server might have, some client might expect to have anonymous access to the schema so that they can understand how to interpret the information that they retrieve from the server. It is true that if a client is sophisticated enough to be able to interpret different syntaxes and matching rules that it will probably also have the ability to use an authenticated connection to retrieve it in most cases, but that may not be possible for cases in which the client is retrieving the root DSE to determine the mechanisms that it can use to authenticate.

There is less precedent for allowing anonymous access to the cn=monitor entry since the LDAP specifications do not make any requirement for making this kind of information available. However, it is ideal for periodic health checks and some customers use it in this manner. If the application or device making this health check expects to be able to retrieve the information in cn=monitor anonymously, then it could stop functioning if this access is removed.

Ultimately, it all comes down to whether you feel that making this information available anonymously really is a security risk and whether removing it will adversely impact any legitimate clients. If you feel that there legitimate reason for concern in providing clients with access to this information, then you should configure a test environment to remove these permissions and determine whether it will cause any problems with any of your clients. If there are problems, then you should evaluate the effort it will take to "fix" those clients versus the risk associated with making this information available. In some cases, you may be able to reestrict anonymous access to just the systems running those clients that need it (by either IP address or hostname).

Personally, I'm not aware of any problem that could arise from leaving these access controls in their default configurations. None of the information that the server makes available in this manner should make it significantly easier to attack the server, and clients that you may currently have (or may add in the future) might have a legitimate reason to require access to this information without authentication. Security by obscurity is rarely the correct approach, and if at any point a vulnerability is discovered that could be easier to exploit by the information provided by these entries, then the correct solution is to fix the underlying vulnerability rather than trying to hide it with access controls.

Posted by cn_equals_directory_manager ( Jan 27 2006, 07:53:07 AM CST ) Permalink

Comments: