Specifications

Appendix A: LDAP Implementation Details
119
NX-Series Controllers - WebConsole & Programming Guide
Appendix A: LDAP Implementation Details
Overview
The process of verifying credentials and obtaining user authorization is designed to support most organizations
requirements for 'least privilege'. The account used to search LDAP to provide user objects for authentication never
needs access to user information. Authorization lookups are performed as the authenticated user and as such, no elevated
permission is required. Please refer to RFC 2256, RFC 2798, and RFC 4519.
Assumptions and Prerequisites
Assumptions made about the LDAP implementation or environment in which the AMX client will participate include:
1. Must support simple authentication (for example, NetLinx Masters do not support Kerberos or SASL).
2. The account setup for a bind DN must have search capability along with the necessary permissions to read the 'uid',
'cn', 'member' and 'objectclass' attributes.
3. When a search is performed to find a DN with the specified user ID, a search must return one and only one object if
the user exists. No object will be returned if an account does not exist for that user ID.
4. An account is considered valid if a user can authenticate/bind. No other attributes are considered during the
authentication process.
5. AMX LDAP implementation supports both encrypted and un-encrypted connections using SSL.
6. When a person authenticates, that account must have access to all the attributes defined by RFC 2798 with the
following exception:
User passwords are not necessarily accessible for anything except to perform a bind to the directory (for example,
this attribute may not be directly available to the user).
7. When a person authenticates, that account must have the ability to search for the groups of which that account is a
member (for example, the account is able to perform a search with a filter which contains 'member=' followed by
the DN of the authenticated user. If exceptions exists, those groups cannot/will not be necessary for AMX client
security decisions.
8. When a person authenticates, that account must have access to "cn" attributes for all groups of which it is a member.
9. Group membership for users will be defined by the GroupOfNames object class. GroupOfUniqueNames is not
supported due to ambiguities associated with implementations which use unique IDs appended to membership
DNs.
10. When performing searches for group membership, no restrictions exist which would the restrict returning the full
list of objects for which the user is a member with the possible exception of reasonable response timeouts. AMX
LDAP implementation does not support paged search results.
11. AMX LDAP implementation does not support following referrals.
AMX LDAP Client Authentication Sequence
An example of the operation of the AMX client, using the example LDAP directory tree in the server section of this
document, is presented next in a step-by-step breakdown. DallasUser1 will be used for this example.
Client Setup:
LDAP Enabled: yes
LDAP URI: ldaps://myLDAPServer01: 636
LDAP BASE DN: dc=example,dc=com
BIND DN: uid=amxBindAccount,ou=people,dc=example,dc=com
User Query Attr: uid
Search Password: secret
1. DallasUser1 initiates a HTTP session with the master and is prompted for a user name and password.
2. DallasUser1 enters user name: DallasUser1 and his/her password: DallasUser1Pswd.