Setting Up a Proxy User for LDAP The final topic this chapter covers is setting up a proxy user for LDAP services (which in turn provides access to eDirectory). At discussed in Chapter 2, when a user performs an anonymous bind (that is, doesn't specify a password), the level of access is based on the rights of the pseudo-object [Public] . By default, [Public] can browse the entire tree hierarchy and read a limited number of attributes on entries. The attributes that [Public] can read are those that are flagged as Public Read . NOTE You can find a list of attributes defined in eDirectory 8.7.3, along with their flags, in Appendix C, "eDirectory Classes, Objects, and Attributes."
The default list of attributes accessible by [Public] is generally inadequate (for example, searching for CN is required for contextless login to function, but CN is not one of the Public Read attributes). There are two possible solutions to this issue: grant more rights to [Public] or use a proxy user that has the required rights. Some administrators are hesitant to grant additional rights to [Public] because every user in the tree is implicitly the security equivalent to [Public] . The additional rights may be undesirable. Consequently, most sites opt instead to use a proxy user authentication for LDAP anonymous binds. Because the proxy user is a real User object in the tree, you can easily restrict the types of objects and attributes that anonymous users can access by setting the appropriate DS rights the proxy user has in the tree. However, the proxy user must have a blank password (that is, an empty string) in order to work correctly. This is very different from having no password. If any user has no password, that user does not have a public/private key pair to compare against when attempting login. A blank password, however, generates a public/private key pair, although the actual string for the password is empty. TIP If you allow anonymous binds to your LDAP server, you should use a proxy user instead of [Public] . You should grant only the minimum necessary rights (such as Browse and Compare attribute rights) to selected attributes; you should not select the All Properties shortcut unless you have a good reason to. To discourage someone from logging in from a workstation by using this User object, you should ensure that it has no file system rights anywhere and has network address and concurrent login restrictions.
There may be situations in which you want or need to disallow LDAP anonymous binds, perhaps for the security reason that you don't want just anyone to be able to query your LDAP server. The easiest way to accomplish this is to simply upgrade to eDirectory 8.7 patched to 8.7.0.3 or higher. A new attribute called ldapBindRestrictions was introduced in these patches to control the availability of anonymous bind. WARNING Keep in mind that the ability for an LDAP server to accept anonymous binds is an RFC requirement. Disallowing anonymous binds may cause some LDAP -compliant applications to fail as they may first perform anonymous binds to do lookups before binding with the actual user credentials.
You perform the following steps to set the LDAP server to not accept anonymous binds: - Start ConsoleOne and browse to locate your LDAP server object.
- Right-click the object and select Properties from the context menu.
- Select the Restrictions tab.
- Change the Bind Restrictions setting to Disallow Anonymous Simple Bind (see Figure 15.30).
Figure 15.30. Disallowing anonymous simple binds. 
- Click OK to save the change.
You need to restart the LDAP server for the change to take effect. TIP Older versions of the LDAP snap-in for ConsoleOne do not have the Bind Restrictions setting. If you're using such a version, you need to use the Other tab to modify the value of the ldapBindRestrictions attribute. (If the ldapBindRestrictions attribute is not listed, click the Add button, select the ldapBindRestrictions attribute, and click OK.) To disable anonymous binds, put the value 1 in the Attribute Value field. Use the value to allow such connections. If you are running eDirectory 8.7.0.3 or later, if ldapBindRestrictions is not one of the available attributes that you can add in the Other tab, or if there is no Bind Restrictions setting under Restrictions, your schema may not have been properly extended for this new attribute. Refer to TID #10077872 for corrective measures.
If you are unable to upgrade to eDirectory 8.7.0.3 or higher, you will have to change the rights of [Public] and those of the proxy user if you are using one so that anonymous bind connections will not be able to browse the tree. You can't prevent users from connecting via anonymous binds, but you can limit what they can see. The reason you need to change the rights of [Public] is that, by default, it has object Browse rights to [Root] , which means even if the proxy user has no explicit rights to the tree, the proxy user will still have object Browse rights. You need to take the following measures to make sure the proxy user sees nothing in the tree: After you implement these two measures, the proxy user ”and thus, anonymous bind connections ”will be unable to browse the tree. | 