--- title: Restricting proxied authorization for specific users description: Use the following example scenario with proxied users to restrict proxied authorization. component: pingdirectory version: 11.0 page_id: pingdirectory:managing_access_control:pd_ds_restrict_proxied_authn_users canonical_url: https://docs.pingidentity.com/pingdirectory/11.0/managing_access_control/pd_ds_restrict_proxied_authn_users.html revdate: May 10, 2024 section_ids: about-this-task: About this task steps: Steps example: Example: example-2: Example: example-3: Example: example-4: Example: example-5: Example: example-6: Example: example-7: Example: example-8: Example: example-9: Example: result: Result: example-10: Example: result-2: Result: --- # Restricting proxied authorization for specific users Use the following example scenario with proxied users to restrict proxied authorization. ## About this task To illustrate how the proxied authorization operational attributes work, set up a simple example where two LDAP clients, `uid=clientApp1` and `uid=clientApp2`, can freely proxy two administrator accounts, `uid=admin1` and `uid=admin2`. Add the `ds-auth-may-proxy-as-*` and `ds-auth-is-proxyable-*` attributes to these entries to restrict how each account can use proxied authorization. For example, the two client applications can continue to proxy the `uid=admin1` account but the `uid=admin2` account are no longer able to be used as a proxied entry. ![A flowchart showing an example configuration of restricting proxied authorization for specific users. In the first configuration, both client apps can proxy as either of the admins to perform operations. In the second configuration, both client apps must proxy as the first admin to perform operations.](_images/hyl1689877195250.jpg)Proxy Users Example Scenario ## Steps 1. Set up two user entries, `uid=clientApp1`and `uid=clientApp2`, with the `proxied-auth` privilege assigned to them. The user entries will proxy as the `uid=admin1` and `uid=admin2` accounts to access the `ou=People,dc=example,dc=com` subtree. 1. Open a text editor and create an LDIF file. 2. Add the file using the `ldapmodify` tool. ### Example: | | | | - | -------------------------------------------------------------------------------------------------------------------- | | | In this example, `…` indicates that other attributes present in the entry are not included for readability purposes. | ``` dn: uid=clientApp1,ou=Applications,dc=example,dc=com objectClass: top ... ds-privilege-name: proxied-auth dn: uid=clientApp2,ou=Applications,dc=example,dc=com objectClass: top ... ds-privilege-name: proxied-auth ``` 2. Assign the access control instruction (ACI) for each client application to the subtree, `ou=People,dc=example,dc=com`. | | | | - | ------------------------------------------------------------------------------------------------------------ | | | ACIs should be on one line of text. The following example displays ACIs over multiple lines for readability. | ### Example: ``` dn: ou=People,dc=example,dc=com aci: (version 3.0; acl "People Proxy Access"; allow(proxy) userdn="ldap:///uid=clientApp1,ou=Applications,dc=example,dc=com";) aci: (version 3.0; acl "People Proxy Access"; allow(proxy) userdn="ldap:///uid=clientApp2,ou=Applications,dc=example,dc=com";) ``` 3. Run a search for each entry. ### Example: In this example, assume that there are two admin accounts, `admin1` and `admin2`, that have full access rights to user attributes. You should be able to proxy as the `uid=admin1` and `uid=admin2` entries to access the subtree for both clients. ```shell $ bin/ldapsearch --port 1389 \ --bindDN "uid=clientApp1,ou=Applications,dc=example,dc=com" \ --bindPassword password \ --proxyAs "dn:uid=admin1,dc=example,dc=com" \ --baseDN ou=People,dc=example,dc=com \ "(objectclass=*)" $ bin/ldapsearch --port 1389 \ --bindDN "uid=clientApp2,ou=Applications,dc=example,dc=com" \ --bindPassword password \ --proxyAs "dn:uid=admin2,dc=example,dc=com" \ --baseDN ou=People,dc=example,dc=com \ "(objectclass=*)" ``` 4. Limit the proxied authorization capabilities for each client application. In the following example, the `ds-auth-may-proxy-as` attribute specifies that `uid=clientApp1` can proxy as the `uid=admin1` entry. 1. Open a text editor and create the following LDIF file. 2. Update the `uid=clientApp1` entry to add the `ds-auth-may-proxy-as` attribute. | | | | - | --------------------------------------- | | | `ds-auth-may-proxy-as` is multi-valued. | 3. Save the file and add it using `ldapmodify`. ### Example: ``` dn: uid=clientApp1,ou=Applications,dc=example,dc=com changetype: modify add: ds-auth-may-proxy-as ds-auth-may-proxy-as: uid=admin1,dc=example,dc=com ``` 5. Repeat the previous step for the `uid=clientApp2` entry, but specify the `ds-auth-may-proxy-as-url` attribute. The client entry can proxy as any distinguished name (DN) that matches the LDAP URL. ### Example: ``` dn: uid=clientApp2,ou=Applications,dc=example,dc=com changetype: modify add: ds-auth-may-proxy-as-url ds-auth-may-proxy-as-url: ldap:///dc=example,dc=com??sub?(uid=admin*) ``` 6. To illustrate the `ds-auth-proxyable-by-group` attribute, create a group of client applications that has `uid=clientApp1` and `uid=clientApp2` as its `uniquemembers`. ### Example: This example sets up a static group using the `groupOfUniqueNames` object class. ``` dn: ou=Groups,dc=example,dc=com objectClass: top objectClass: organizationalunit ou: groups dn: cn=Client Applications,ou=Groups,dc=example,dc=com objectClass: top objectClass: groupOfUniqueNames cn: Client Applications ou: groups uniquemember: uid=clientApp1,ou=Applications,dc=example,dc=com uniquemember: uid=clientApp2,ou=Applications,dc=example,dc=com ``` 7. Update the `uid=admin1` entry to provide the DN that it can be proxied as. 1. Open a text editor and create the following LDIF file. 2. Use the `ds-auth-is-proxyable` to make the `uid=admin1` a required proxyable entry, meaning that it can only be accessed by some form of proxied authorization. 3. Use the `ds-auth-is-proxyable-by` attribute to specify each DN that can proxy as `uid=admin1`. 4. Save the LDIF file and add it using `ldapmodify`. ### Example: ``` dn: uid=admin1,dc=example,dc=com changetype: modify add: ds-auth-is-proxyable ds-auth-is-proxyable: required - add: ds-auth-is-proxyable-by ds-auth-is-proxyable-by: ou=clientApp1,ou=Applications,dc=example,dc=com ds-auth-is-proxyable-by: ou=clientApp2,ou=Applications,dc=example,dc=com - add: ds-auth-is-proxyable-by-group ds-auth-is-proxyable-by-group: cn=Client Applications,ou=Groups,dc=example,dc=com - add: ds-auth-is-proxyable-by-url ds-auth-is-proxyable-by-url: ldap:///ou=Applications,dc=example,dc=com??sub?(uid=clientApp*) ``` | | | | - | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | The example includes all three types of `ds-auth-is-proxable-by-*` attributes as an illustration, but only one type of attribute is necessary if they all target the same entries. | 8. Prohibit proxying for the `uid=admin2` entry. 1. Open a text editor and create the following LDIF file. 2. Set the `ds-auth-is-proxyable` attribute to `prohibited`. 3. Save the LDIF file and add it using `ldapmodify`. ### Example: ``` dn: uid=admin2,dc=example,dc=com changetype: modify add: ds-auth-is-proxyable ds-auth-is-proxyable: prohibited ``` 9. Run a search using the proxied account. 1. To return a successful operation, run a search with `uid=clientApp1` or `uid=clientApp2` that proxies as `uid=admin1`. 2. To return an unsuccessful operation, run a search for `uid=clientApp1` that proxies as `uid=admin2`. ### Example: ```shell $ bin/ldapsearch --port 1389 \ --bindDN "uid=clientApp1,ou=Applications,dc=example,dc=com" \ --bindPassword password \ --proxyAs "dn:uid=admin2,dc=example,dc=com" \ --baseDN ou=People,dc=example,dc=com \ "(objectclass=*)" ``` ### Result: The operation is unsuccessful because `uid=admin2` does not match the list of potential entries that can be proxied. The `ds-auth-may-proxy-as-*` attributes specify that the client can only proxy as `uid=admin1`. ``` One of the operational attributes (ds-auth-may-proxy-as, ds-auth-may-proxy-as-group, ds-auth-may-proxy-as-url) in user entry 'uid=clientApp1,ou=Applications,dc=example,dc=com' does not allow that user to be proxied as user 'uid=admin2,dc=example,dc=com' Result Code: 123 (Authorization Denied) Diagnostic Message: One of the operational attributes (ds-auth-may-proxy-as, ds-auth-may-proxy-as-group, ds-auth-may-proxy-as-url) in user entry 'uid=clientApp1,ou=Applications,dc=example,dc=com' does not allow that user to be proxied as user 'uid=admin2,dc=example,dc=com' ``` 10. Run another search using `uid=clientApp2`, which attempts to proxy as `uid=admin2`. ### Example: ```shell $ bin/ldapsearch --port 1389 \ --bindDN "uid=clientApp2,ou=Applications,dc=example,dc=com" \ --bindPassword password \ --proxyAs "dn:uid=admin2,dc=example,dc=com" \ --baseDN ou=People,dc=example,dc=com \ "(objectclass=*)" ``` ### Result: The operation is unsuccessful because the `ds-auth-is-proxyable:prohibited` operational attribute states that `uid=admin2` is not available for proxied authorization. ``` The 'ds-auth-is-proxyable' operational attribute in user entry 'uid=admin2,dc=example,dc=com' indicates that user may not be accessed via proxied authorization Result Code: 123 (Authorization Denied) Diagnostic Message: The 'ds-auth-is-proxyable' operational attribute in user entry 'uid=admin2,dc=example,dc=com' indicates that user may not be accessed via proxied authorization ```