When present in an entry, the Directory Server evaluates each operational attribute together to form a whitelist of potential users that can be proxied. If none of those attributes are present, the user can potentially proxy as anyone.

The Directory Server supports a two-tier provision system that can restrict specific users for proxied authorization:

  • The first tier is a set of ds-auth-may-proxy-as-* operational attributes on the client entry that binds to the server and carries out operations under the identity of another user.
  • The second tier is a set of ds-auth-is-proxyable-* operational attributes on the user entry that defines whether access is allowed, prohibited, or required through proxied authorization. If proxied authorization is allowed or required, the attributes define which client entries can proxy as the user.
Proxying operational attributes

A flowchart showing the process of proxying operational attributes. The client application proxies as uid=admin to perform operations.

For example, the following command demonstrates the client application uid=clientApp requesting to search the ou=People,dc=example,dc=com branch as the user uid=admin.

ldapsearch --bindDN uid=clientApp,dc=example,dc=com \
--bindPassword password \
--proxyAs uid=admin,dc=example,dc=com \
--baseDN ou=People,dc=example,dc=com \
"(object-class=*)

At bind, the Directory Server evaluates the list of users in the uid=clientApp entry based on the presence of any ds-auth-may-proxy-as-* attributes.

In the previous figure, the uid=clientApp entry has a ds-auth-may-proxy-as attribute with a value of uid=admin, meaning the client app user can proxy only as the uid=admin account.

Next, the server confirms that uid=admin is in the list of proxyable users and then evaluates the ds-auth-is-proxyable-* attributes present in the uid=admin entry. These attributes determine the list of restricted users that either are allowed, prohibited, or required to proxy as the uid=admin entry. In this case, the uid=admin entry has the ds-auth-is-proxyable attribute with a value of required, meaning the entry can only be accessed by means of proxied authorization.

The uid=admin entry also has the ds-auth-is-proxyable-by attribute with a value of uid=clientApp, meaning it can only be requested by the uid=clientApp entry. When both sets of attributes have been satisfied, the uid=clientApp can bind to the server as the authenticated user.

Next, the Directory Server performs access control instruction (ACI) evaluation on the branch and determines if the requested user has access rights to the branch. If the uid=clientApp entry can access the branch, the search request is processed.