Skip to content

LDAP Proxy Scenarios

Jump to bottom
Friedrich Weber edited this page Feb 6, 2017 · 5 revisions

We are looking at different scenarios how the application is using LDAP and thus talking to the LDAP proxy. The scenarios depend on the LDAP Request types used and either the user issues an LDAP request or a service account issues an LDAP request.

Scenarios

We assume, that applications will also use a service account, e.g. to enumerate users or to search user attributes in LDAP.

At first we are regarding these three sceanrios:

  1. No Service Account, Only User-Binds, No Search
  2. No Service Account, Only User-Bind and User-Search
  3. Service Account, User-Binds and Service Search

No Service Account. Only User-Bind.

The application does not use any service account. The user is authenticated by a bind request. The user usually logs in with a username, but the BIND request needs a DN.

Thus the application knows a mapping like

cn=*username*,ou=some_OU,dc=company,dc=com

Thus the web application will generate a DN from the username with a fixed configuration.

note: This will not work, if users are located in different OUs or Containers (CN) around the LDAP.

note: This scenario does not use any LDAP SEARCH Request.

LDAP Proxy Behaviour

The LDAP proxy receives the DN of the user in the User-Bind. But it has to verify the username and the password against privacyIDEA.

The LDAP proxy could be configured like

User_Bind_Mask = "cn=(.*),ou=some_OU,dc=company,dc=com"

If the configuration parameter User_Bind_Mask is available it does not have to query the LDAP but can simple deduce the login name from the DN. It then can verify the username and the OTP/password.

No Service Account. User-Bind and User-Search

After the user binds to the LDAP, the application uses this connection to do a LDAPSearchRequest in the user context. Thus the application will usually only fetch attributes of the user.

Still the users probably are located in one container in the LDAP directory. Otherwise the application could not find the user.

LDAP Proxy Behaviour

Also in this case the User_Bind_Mask parameter can be used to convert the DN to the username. This is for authenticating the user against privacyIDEA.

But the application could also issue User-Search Requests. The LDAP proxy needs to issue the request to the originial LDAP server. But the LDAP proxy does not know the LDAP password of the user. So the LDAP proxy needs a proxy service account, that can be used to issue the search request.

The following parameters could be be used:

Allow_Service_Account_Search = True
Service_Account_DN = ...
Service_Accoutn_Password = ...

Maybe we could omit the Allow_Service_Account_Search parameter and only do the service account search if the Service_Account_DN exists.

Current Approach: Once the user has been authenticated successfully against the privacyIDEA server, the LDAP proxy sends a bind request using the service account credentials to the LDAP backend. If a specific config option is set, the LDAP proxy forwards all search requests received on the connection to the LDAP server, where they get executed in the context of the service account.

Application with Service Account

The Application needs a service account if the application needs to enumerate the users (e.g. for role assignment) or if the users are located at different locations in the LDAP directory.

The user logs in with the username.

The application could probably use the service account to determine the DN of the user.

username1 -> DN: cn=username1,ou=finance,ou=stockholm,dc=company,dc=com username2 -> DN: cn=username2,ou=consulting,ou=berlin,dc=company,dc=com

Thus we assume the application to run the following flow:

  1. Service-Account-Bind
  2. Service-Account-Search to determine the DN of the username
  3. User-Bind with the provided credentials
  4. User-Search to show the user his mobile number ;-)

LDAP Proxy Behaviour

The LDAP proxy has to issue step 1 and 2 against the original LDAP. Thus the LDAP proxy will to a Service-Account-Bind and Service-Account-Search against the original LDAP.

Konfiguration

To be able to do so, the LDAP proxy gets a list of DNs, that are directly forwarded to the orignial LDAP directory. The Service-account-bind request, that appears at the LDAP proxy, in fact contains the LDAP password.

note: This could also be a user account, that is not supposed to authenticate against privacyIDEA!

service_accounts = ["CN=service1,ou=...", "CN=service2,ou=..."]

Then the LDAP proxy needs to identify the User-Bind in step 3. In fact this is a BIND request of a DN, that is not contained in the service_accounts parameters.

But the LDAP proxy needs to convert the User-DN to a username. For this the LDAP proxy needs a service account. It could use the parameters Serivce_account_DN and service_account_password from the first scenario.

Now the LDAP proxy knows the username and can check against privacyIDEA and send the corresponding response to the User-Bind.

TODO: Do we need to distinguish between User-Search and Service-Account-Search or do we use the internal Serive-Account-DN for all searches?

Clone this wiki locally