LDAP Services for NDS allows LDAP clients to access data in NDS directories. All LDAP clients bind, or connect, to NDS as one of the following types of users:
Login restrictions and password restrictions will still apply; however, any restrictions will be relative to where LDAP is running. Time and address restrictions are honored, but address restrictions are relative to where the NDS login occurred--in this case, the LDAP server. Also, as LDAP does not support grace logins, it is possible to log in to NetWare and yet not be able to bind to LDAP.
An anonymous bind is a bind that does not contain a username or password. If an LDAP client binds to LDAP Services for NDS and the service is not configured to use a proxy user, the user is authenticated to NDS as user [Public]. User [Public] is a nonauthenticated NDS user. By default, user [Public] is assigned the Browse right to the objects and attributes in the NDS tree. The default Browse right for user [Public] allows users to browse NDS objects but blocks user access to object attributes. The default [Public] rights are typically too limited for most LDAP clients. Although you can change the [Public] rights, this will give these rights to all users. Because of this, use of the Proxy User Anonymous bind is suggested.
To enable user [Public] access to object attributes, you must make user [Public] a trustee of the appropriate container or containers and assign the appropriate object and attribute rights.
NOTE: Rights to specific attributes currently cannot be inherited in NDS. If you want to grant Read and Search rights to a particular attribute, you must do so for all NDS objects to be accessed, not just a parent object. The rights assigned to user [Public] are available to anyone who accesses NDS. This access can be set up through LDAP Services for NDS or through any NetWare utility, such as NetWare Administrator.
A proxy user anonymous bind is an anonymous bind that is linked to a normal NDS username. If an LDAP client binds to LDAP Services for NDS anonymously and the service is configured to use a proxy user, the user is authenticated to NDS as the proxy user, whose name is configured in LDAP Services for NDS and in NDS.
To implement proxy user anonymous binds, you must create the Proxy User object in NDS and assign the appropriate rights to that user. Assign the Proxy User Read and Search rights to all objects and attributes in each subtree where access is needed. Use LDAP Access Control Lists (ACL) to restrict access as necessary. You also need to enable the proxy user in LDAP Services for NDS by specifying the same proxy username.
The key concepts of proxy user anonymous binds are as follows:
An NDS user bind is a bind that an LDAP client makes using a complete NDS username and password. The NDS user bind is authenticated in NDS, and the LDAP client is allowed access to any information the NDS user is allowed to access.
When LDAP Services for NDS is installed, NDS user bind requests using cleartext (unencrypted) passwords are refused by default. Cleartext passwords and NDS usernames entered by LDAP clients on non-Secure Socket Layer (SSL) connections are vulnerable to capture by network monitoring equipment. Anyone who captures an NDS username and password has immediate access through an LDAP or NDS client to all the NDS objects to which the captured username has access. NDS user binds should only be used on LDAP servers that are configured to use SSL.
NOTE: Even though cleartext passwords are not accepted by default, this does not prevent users from trying to bind with their usernames and passwords. On an unsecured connection, all attempted binds expose the username and password to eavesdropping, whether or not the bind is successful. However, not allowing cleartext passwords for NDS user binds discourages users from using their names and passwords, because this method of binding will be unsuccessful.
To support NDS user binds on non-SSL connections, you must allow cleartext passwords within the LDAP Group object.
The key concepts of NDS user binds are as follows:
The type of bind with which the user authenticates has a direct effect on the content the LDAP client can access. LDAP clients access a directory by building a request and sending it to the directory. When an LDAP client sends a request through LDAP Services for NDS, NDS completes the request for only those attributes to which the LDAP client has the appropriate access rights. For example, if the LDAP client requests an attribute value (which requires the Read right) and the username is granted only the Compare right to that attribute, the request is rejected.