-
Notifications
You must be signed in to change notification settings - Fork 12
LDAP Proxy Scenarios
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.
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:
- No Service Account, Only User-Binds, No Search
- No Service Account, Only User-Bind and User-Search
- Service Account, User-Binds and Service Search
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.
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.
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.
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.