Global Administrators with a subset of Admin Privileges

Oracle Unified Directory provides one default root DN or root user, "cn=Directory Manager". The default root DN is a user entry assigned with specialized privileges with full read and write access to all data in the server. Comparable to a Unix root user or superuser, the root DN can bypass access controls to carry out tasks on the server. The root user is defined below the "cn=Root DNs,cn=config" branch of the server atcn=Directory Manager,cn=Root DNs,cn=config. and is local to each OUD instance.  The server supports multiple root users who have their own entries and their own set of credentials on the server.

OUD also provides the notion of global administrators. Global Administrators are responsible for managing and maintaining administrative server domains in replicated environments. One Global Administrator is created when you set up replication servers using the graphical installer or the dsreplication command (you are prompted to set a user name and password for the Global Administrator) .

The Global Administrator created for the replication exists in the cn=Administrators,cn=admin data subtree, so it is replicated and can be used with every OUD instance of a replicated topology. To view the Global Administrator entry, run the following ldapsearch command:

$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file \
  --useSSL -b "cn=Administrators,cn=admin data" -s sub "(objectclass=*)"
dn: cn=Administrators,cn=admin data
objectClass: top
objectClass: groupofurls
description: Group of identities which have full access.
cn: Administrators
memberURL: ldap:///cn=Administrators,cn=admin data??one?(objectclass=*)
dn: cn=admin,cn=Administrators,cn=admin data
objectClass: person
objectClass: top
userPassword: {SSHA}+ed1wbhcWjxtv2zJ6OHEA2TuE9n1qIJGnuR94w==
description: The Administrator that can manage all the OUD instances.
cn: admin 

The Global Administrator created for the replication exists has the full set of admin privileges. In some situations, it might be useful to create additional administrators having only a subset of admin right. For instance, a Monitor Administrator would have the privilege to read the OUD configuration but he/she would not be able to modify it.

To do so, you can create your own admin container node in the cn=admin data suffix

./ldapmodify -a -p 4444 -Z -X -D "cn=directory manager"  -w ****
dn: cn= my admins,cn=admin data
objectclass: top
objectClass: ds-cfg-branch

dn: cn=monitor,cn=my admins,cn=admin data
objectClass: person
cn: monitor
sn: monitor 
userpassword: ****

At that stage, it is possible to use these credentials (cn=monitor,cn=my admins,cn=admin data) with dsconfig. dsconfig can authenticate that user, however the “admin” won’t be able to read the config as he/she does not have the privilege to do so. dsconfig reports the following error during navigation in the config:

The Administration Connector could not be modified because you do not 
have the correct authorization

Appropriate privileges must be assigned to the admin so that he/she has the right to perform the desired actions. In that example, the admin requires the config-read privilege. The bypass-acl is also required so that he/she can perform privileged actions on the configuration.

./ldapmodify -p 4444 -Z -X -D "cn=directory manager"  -w ****
dn: cn=monitor,cn=my admins,cn=admin data
changetype: modify
add: ds-privilege-name
ds-privilege-name: bypass-acl
ds-privilege-name: config-read

Now the admin can read the config via dsconfig. However, any attempt to modify it would raise the following error:

The Configuration could not be modified because you do not have 
the correct authorization 

How to lock every account in a LDAP subtree with OUD

Let’s assume a customer would like to lock every LDAP account in a given LDAP subtree stored in Oracle Unified Directory.
An account can be locked by setting the ds-pwp-account-disabled operational to true in the accounts to lock. More about account lockout and password mpolicy is available at Managing password policies

It is possible to assign the ds-pwp-account-disabled attribute to a set of accounts using virtual attributes.Virtual attributes are attribues whose values do not exist in persistent storage but are dynamically generated in some way.

OUD Collective attribute is a mean to manage virtual attributes. More about collective attributes at using-collective-attributes

To lock every account in the oud=people,dc=example,dc=com subtree, create the following collective attribute:

dn: cn=myattr,dc=example,dc=com
objectclass: top
objectClass: subentry
objectClass: collectiveAttributeSubentry
objectClass: extensibleObject
ds-pwp-account-disabled;collective: true
subtreespecification: {base “ou=people”, minimum 1}
collectiveConflictBehavior: virtual-overrides-real