AD 2003 Upgrading – AD LDS authentication


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.

Reference

Overview of Authentication Mechanisms in AD LDS

Introduction to Administering Authentication and Access Control

Supported Types of Security Principals

Advertisements
This entry was posted in AD. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s