1. For this example, set up two user entries, uid=clientApp1 and uid=clientApp2, which will be proxying the uid=admin1 and uid=admin2 accounts to access the ou=People,dc=example,dc=com subtree. Both entries have the proxied-auth privilege assigned to it. Open a text editor and create an LDIF file. Add the file using the ldapmodify tool. Note that "..." indicates that other attributes present in the entry are not included in the example 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. Next, assign the ACI for each client application to the subtree, ou=People,dc=example,dc=com. Note that the ACIs should be on one line of text. The example displays the ACIs over multiple lines for readability.
    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. 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.
    $ 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. Next, limit the proxied authorization capabilities for each client application. Update the uid=clientApp1 entry to add the ds-auth-may-proxy-as attribute. In this example, the ds-auth-may-proxy-as attribute specifies that uid=clientApp1 can proxy as the uid=admin1 entry. Open a text editor, create the following LDIF file, save it, and add it using ldapmodify. Note that ds-auth-may-proxy-as is multi-valued:
    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, except specify the ds-auth-may-proxy-as-url. The client entry may proxy as any DN that matches the LDAP URL.
    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. Next, we want to create a group of client applications that has uid=clientApp1 and uid=clientApp2 as its uniquemembers to illustrate the use of the ds-auth-proxyable-by-group attribute. In this example, set 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 may be proxied as. Add the ds-auth-is-proxyable and the ds-auth-is-proxyable-by attributes. For instance, we make the uid=admin1 a required proxyable entry, which means that it can only be accessed by some form of proxied authorization. Then, specify each DN that can proxy as uid=admin1 using the ds-auth-is-proxyable-by. Open a text editor, create the following LDIF file, save it, and add it using ldapmodify. Note that the example includes all three types of ds-auth-is-proxable-by-* attributes as an illustration, but, in an actual deployment, only one type of attribute is necessary if they all target the same entries.
    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*)
  8. Next, prohibit proxying for the uid=admin2 entry by setting the ds-auth-is-proxyable to prohibited. Open a text editor, create the following LDIF file, save it, and add it using ldapmodify.
    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. For example, run a search first with uid=clientApp1 or uid=clientApp2 that proxies as uid=admin1 to return a successful operation. However, if you run a search for uid=clientApp1 that proxies as uid=admin2, as seen below, you will see an "authorization denied" message due to uid=admin2 not matching 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:
    $ 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=*)"
    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. You will see an "authorization denied" message due to the presence of the ds-auth-is-proxyable:prohibited operational attribute, which states that uid=admin2 is not available for proxied authorization.
    $ 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=*)"
    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