The server provides a set of operational attributes that restrict the proxied authorization capabilities of a client application and its proxyable target entry.
When present in an entry, the 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 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.
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
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 server evaluates the list of
users in the
uid=clientApp entry based on the presence of any
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
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
ds-auth-is-proxyable attribute with a value of
required, meaning the entry can only be accessed by means of proxied
uid=admin entry also has the
attribute with a value of
uid=clientApp, meaning it can only be requested
uid=clientApp entry. When both sets of attributes have been
uid=clientApp can bind to the server as the authenticated
Next, the 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.