Specifications

Appendix A: LDAP Implementation Details
124
NI & DVX Central Controllers - WebConsole & Programming Guide
3. The client connects to the LDAP server and starts a bind operation with the BIND DN,
uid=amxBindAccount,ou=people,dc=example,dc=com, and the Search Password, secret.
4. The password, secret, is then compared by the server to the value of the userPassword attribute for the record
uid=amxBindAccount,ou=people,dc=example,dc=com.
If this step is successful, the bind is successful and the client is logged in.
5. If the bind is successful, the client then performs a search with the filter
(&(objectclass=person)(uid=DallasUser1)).
The objectclass=person portion of the filter is hard coded in the client firmware.
The uid=DallasUser1 portion of the filter is formed from the configured parameter User Query Attr and the user
name entered when logging in.
Since the User Query Attr is required to be unique in the search base LDAP BASE DN, the search should return
either 0 or 1 record.
If one record is found, the DN of the record is returned. In this example, the DN
uid=DallasUser1,ou=people,ou=Dallas,dc=example,dc=com is returned.
6. The client then unbinds as the user uid=amxBindAccount,ou=people,dc=example,dc=com.
7. If a record is found that matches, the client then attempts to bind as this DN using the password the user enters to
initiate the session.
In this example the DN uid=DallasUser1,ou=people,ou=Dallas,dc=example,dc=com and the password
DallasUser1Pswd would be used for this bind.
8. The server compares the user supplied password with the value of the userPassword attribute of
uid=DallasUser1,ou=people,ou=Dallas,dc=example,dc=com.
If this match is successful, the bind is successful and the client is logged in.
9. If the bind is successful, the client then performs another search using the filter (member=DN returned from the
first search) specifying that the commonName attribute of matching entries should be returned.
In this example, the filter is member=uid=DallasUser1,ou=people,ou=Dallas,dc=example,dc=com.
Since DallasUser1 is listed as a member of the groupOfNames objectclass
dn: cn=master01Admin,ou=groups,ou=Dallas,dc=example,dc=com
and
dn: cn=master01User,ou=groups,ou=Dallas,dc=example,dc=com,
the server will return the commonName attributes master01Admin and master01User.
The client then unbinds as this user and exits.
Example - Setting Up User's Access Rights
In order to give AMX equipment users access rights to the Master, group memberships for users will be defined by the
GroupOfNames object class (refer to LDAP RFC4519). Two records need to be created in the database:
One that represents users with administrative privileges (Admin Change Password Access, Terminal
(RS232) Access, FTP Access, HTTP Access, Telnet Access, Configuration, ICSPConnectivity, and
EncryptICSP Connection).
Another that represents users with user privileges (HTTP Access). The DNs of the AMX equipment users
will be listed under the appropriate GroupOfNames object class as a member attribute.
The AMX LDAP client configuration parameters are located on the System Security
Details page under the System Security Settings link. See the System Security -
System Level section on page 33); the LDAP configuration options are described on
page 34.