![background image](http://html.mh-extra.com/html/amx/dvx-21xxhd/dvx-21xxhd_webconsole-and-programming-manual_2937827108.webp)
Appendix A: LDAP Implementation Details
108
NetLinx Integrated Controllers (Firmware v4)- 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 ID's appended to membership DN's.
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 username and password.
2.
DallasUser1
enters username:
DallasUser1
and his/her password:
DallasUser1Pswd
.
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.