--- title: Restricting proxy users description: The PingDirectory server provides a set of operational attributes that restrict the proxied authorization capabilities of a client application and its proxyable target entry. component: pingdirectory version: 11.0 page_id: pingdirectory:managing_access_control:pd_ds_restrict_proxy_users canonical_url: https://docs.pingidentity.com/pingdirectory/11.0/managing_access_control/pd_ds_restrict_proxy_users.html revdate: September 13, 2023 page_aliases: ["pd_ds_ds_auth_may_proxy_as_op_attribute.adoc", "pd_ds_ds_auth_is_proxyable_op_attribute.adoc"] section_ids: about-the-ds-auth-may-proxy-as-operational-attributes: About the ds-auth-may-proxy-as-* operational attributes about-the-ds-auth-is-proxyable-operational-attributes: About the ds-auth-is-proxyable-* operational attributes --- # Restricting proxy users The PingDirectory 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 PingDirectory 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 PingDirectory 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. ![A flowchart showing the process of proxying operational attributes. The client application proxies as uid=admin to perform operations.](_images/pej1689876400281.jpg)Proxying operational attributes 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 PingDirectory 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 PingDirectory 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. ## About the ds-auth-may-proxy-as-\* operational attributes The PingDirectory server first evaluates the list of potential users that can be proxied for the authenticated user depending on the presence of the `ds-auth-may-*` operational attributes in the entry. These operational attributes are multi-valued and are evaluated together if all are present in an entry: * `ds-auth-may-proxy-as` Specifies the user distinguished names (DNs) that the associated user can proxy as. For example, you can specify in the `uid=clientApp` entry that it can proxy operations as `uid=admin` and `uid=agent1`. ``` dn: uid=clientApp,ou=Applications,dc=example,dc=com objectClass: top ... ds-privilege-name: proxied-auth ds-auth-may-proxy-as: uid=admin,dc=example,dc=com ds-auth-may-proxy-as: uid=agent1,ou=admins,dc=example,dc=com ``` * `ds-auth-may-proxy-as-group` Specifies the group DNs and its group members that the associated user can proxy as. For example, you can specify that the potential users that the `uid=clientApp` entry can proxy as are those members who are present in the group `cn=Agents,ou=Groups,dc=example,dc=com`. This attribute is multi-valued, so you can specify more than one group. Nested static and dynamic groups are also supported. ``` dn: uid=clientApp,ou=Applications,dc=example,dc=com objectClass: top ... ds-privilege-name: proxied-auth ds-auth-may-proxy-as-group: cn=Agents,ou=Groups,dc=example,dc=com ``` * `ds-auth-may-proxy-as-url` Specifies the DNs that are returned based on the criteria defined in an LDAP URL that the associated user can proxy as. For example, the attribute specifies that the client can proxy as those entries that match the criteria in the LDAP URL. This attribute is multi-valued, so you can specify more than one LDAP URL. ``` dn: uid=clientApp,ou=Applications,dc=example,dc=com objectClass: top ... ds-privilege-name: proxied-auth ds-auth-may-proxy-as-url: ldap:///ou=People,dc=example,dc=com??sub?(l=austin) ``` ## About the ds-auth-is-proxyable-\* operational attributes After the PingDirectory server evaluates the list of users that the authenticated user can proxy as, the server checks to see if the requested authorized user is in the list. If the requested authorized user is present in the list, then the server continues processing the proxable attributes in the entry. If the requested authorized user is not present in the list, the bind fails. The operational attributes on the proxying entry are as follows: * `ds-auth-is-proxyable` Specifies whether the entry is proxyable or not. Possible values are: * `allowed` Operations can be proxied as this user. * `prohibited` Operations can't be proxied as this user. * `required` The account cannot authenticate directly but can only be accessed by some form of proxied authorization. * `ds-auth-is-proxyable-as` Specifies any users allowed to use this entry as a target of proxied authorization. * `ds-auth-is-proxyable-as-group` Specifies any groups allowed to use this entry as a target of proxied authorization. Nested static and dynamic groups are also supported. * `ds-auth-is-proxyable-as-url` Specifies the LDAP URLs that are used to determine any users that are allowed to use this entry as a target of proxied authorization.