Have to look into how AD LDS authentication works due to a funny ORACLE app NOT compatible with AD 2012.
AD LDS supports 3 types of security principles:
a. AD LDS its own principle – AD LDS identity
b. AD LDS server’s principle – local OS Identity
c. AD domain principle – the domain which AD LDS server join or trusted
For type 3 (Domain Principle), AD LDS has 2 ways to bind the LDAP request and authenticate with the AD domain
a. “Pass through” – this is the default bind request (also for type 2), and AD LDS will pass through the bind request from the application to AD domain, and the app does authenticate with AD directly.
Since this is a SASL binding, the authentication is secured.
b. “Bind Proxy” – this is called as “Bind Redirection”, and AD LDS will re-direct the bind request and authenticate with AD on the behalf of the app.
The bind redirection ONLY support the simple bind, and does not secure from app to AD LDS, then you have to secure the communication through LDAP/s, etc
Then which one do you prefer ? “Pass through” or “Proxy” ?
a. if the app has no issue to auth with AD, then “pass through” is definitely the solution
b. But why still need “Proxy”? if my app has any compatibility issue with AD, then this is the solution.