A retail chain must authorize warehouse staff whose accounts live in a single OpenLDAP directory. The engineer creates an external LDAP identity source, enters the server address with StartTLS, and supplies a dedicated bind account with read access to the OU holding 4,000 users. Test Connection succeeds. A warehouse worker then signs in with their own directory password. How is the dedicated bind account used during that LDAP sign-in?
Select an answer to reveal the explanation.
Short Explanation
Your bind account gives ISE permission to find the worker’s directory entry; ISE then uses the worker’s own password to authenticate them. If that account cannot search the intended OU, ISE may not find the entry.
Full Explanation
The dedicated bind account is a service identity that lets ISE search the configured OU for the entry matching the submitted login name. After ISE resolves the worker’s DN, it verifies the sign-in using the worker’s own credentials, typically by attempting an LDAP bind with the worker’s password. The bind account supports the directory search; it does not authenticate the worker or replace the worker’s credentials. Constructing the DN directly from the login name and then binding as the worker is a legitimate LDAP pattern when the DN can be derived reliably, but it does not describe the role of the configured search account in this flow. Searching with the bind account and comparing the supplied password against a password attribute is not the described authentication method; directory deployments typically do not expose password values for this purpose. Using proxy authorization would require a suitably privileged LDAP identity able to act as another identity, rather than the read-access search account described here, and would not use the worker’s own credentials in a separate bind. Exam caveat: a successful connection test confirms connectivity and bind-account access, not that a user can authenticate; locating the user and verifying the password are separate steps. Practical check: test a known warehouse account and confirm the ISE authentication log shows the resolved LDAP DN and a successful user-bind result, while the service account remains limited to the intended read access.