A logistics company is adding an external LDAP identity source in ISE so warehouse staff can sign into the corporate Wi-Fi with their existing directory passwords. The directory team created exactly one dedicated service account, policy allows only that account to bind, and directory traffic must be encrypted in transit. Which bind setup should the ISE administrator configure?
Select an answer to reveal the explanation.
Short Explanation
You’ve got the right setup: use the dedicated account the directory team permits, protect the connection with LDAPS, and search the warehouse user subtree. That scoped search keeps the lookup focused on the staff who need Wi-Fi access while meeting the bind and encryption rules.
Full Explanation
The required setup uses the dedicated account that the directory team permits to bind, connects over LDAPS to encrypt directory traffic, and searches the warehouse user subtree. Together, these settings meet the single-account and encryption requirements while limiting lookup to the intended staff. Using the same account over LDAPS but searching the entire directory keeps the permitted bind and encryption, yet fails to scope the search to warehouse users; it may return users outside the intended population. Using a separate read-only bind account over LDAPS and searching the warehouse subtree has suitable encryption and scope, but violates the policy that only the dedicated account may bind. Using the dedicated account over LDAPS and then validating Wi-Fi credentials with MSCHAPv2 meets the account and transport requirements, but MSCHAPv2 challenge-response credentials cannot be validated through an ordinary LDAP bind. An exam caveat is that the warehouse subtree must actually contain the intended users; a search base does not itself select users by job role. In practice, verify that ISE trusts the LDAPS server certificate and can connect, then test a warehouse account and confirm the configured search base finds it.