Friday Sep 04, 2015

Integrating OUD in Monitoring Frameworks: Service Users

Oracle Unified Directory is an all-in-one directory solution with storage, proxy, synchronization and virtualization capabilities.

It can be monitored and integrated in various Monitoring Solutions including Oracle Enterprise Manager, via a dedicated plugin that provides performance monitoring of hundreds of directory metrics, raise alerts based on thresholds and provides rich out-of-the-box reports. By default, monitoring data are retrieved from OUD over LDAPS from the OUD administration port.

In order to use this method, it is recommended to define a dedicated directory user with read privilege on monitoring statistics and configuration. Such user can either be a so-called Root User or a Global Admin User. Root Users are local to a OUD instance and have some special privileges. Global Admin Users are quite similar to Root Users except that they are replicated across OUD servers, so this is more convenient if you want to monitor several OUD instances.

The following rights and privileges are required to access monitoring data and config:  Read access on cn=config and cn=monitor naming contexts and config-read privilege.

Root Users automatically inherit a bunch of default privileges, much more than what is strictly needed to monitor OUD, so unnecessary privileges must be removed and read access must be granted. To create a Root User called "cn=monitor" with sufficient privileges , do the following

./ldapmodify  -h <hostname> -p <adminport> \
-D "cn=Directory Manager" -w <password> -X --useSSL  <<EOF
dn : cn=monitor,cn=Root DNs,cn=config
changetype: add
objectclass: inetOrgPerson
objectclass: person
objectclass: ds-cfg-root-dn-user
objectclass: top
userPassword: <password>
ds-cfg-alternate-bind-dn: cn=monitor
cn: monitor
sn: monitor


Let's remove unnecessary privileges (basically all but config-read)

./ldapmodify  -h <hostname> -p <adminport> \
-D "cn=Directory Manager" -w <password> -X --useSSL <<EOF
dn : cn=monitor,cn=Root DNs,cn=config
changetype: modify
add: ds-privilege-name
ds-privilege-name: -config-write
ds-privilege-name: -modify-acl
ds-privilege-name: -ldif-import
ds-privilege-name: -ldif-export
ds-privilege-name: -backend-backup
ds-privilege-name: -backend-restore
ds-privilege-name: -server-shutdown
ds-privilege-name: -server-restart
ds-privilege-name: -disconnect-client
ds-privilege-name: -cancel-request
ds-privilege-name: -unindexed-search
ds-privilege-name: -password-reset
ds-privilege-name: -update-schema
ds-privilege-name: -privilege-change
ds-privilege-name: -bypass-acl

If you prefer to use Global Admin Users, do the following:

./ldapmodify  -h <hostname> -p <adminport> \ 
-D "cn=Directory Manager" -w <password> -X --useSSL <<EOF
dn : cn=monitor,cn=Administrators,cn=admin data
changetype: add
objectclass: person
objectclass: top
userPassword: <password>
cn: monitor
sn: monitor


Let's add config-read privilege:

./ldapmodify  -h <hostname> -p <adminport> -D "cn=Directory Manager" -w <password> -X -Z <<EOF
dn : cn=monitor,cn=Administrators,cn=admin data
changetype: modify
add: ds-privilege-name
ds-privilege-name: config-read


No matter what User type you choose to use, you need to grant read access to the config and the monitoring information using OUD global acis:
For Root Users, add the following acis using dsconfig: Start dsconfig, select Authentication and Authorization, then Access Control Handler and add the 2 following global acis:

(target="ldap:///cn=config")(targetattr="*")(version 3.0; acl "Monitor config access"; allow (read,search) \
  userdn="ldap:///cn=monitor,cn=Root DNs,cn=config";)
(target="ldap:///cn=monitor")(targetattr="*")(version 3.0; acl "Monitor access"; allow (read,search) \
  userdn="ldap:///cn=monitor,cn=Root DNs,cn=config";) 

For Global Admin Users, here are the corresponding acis:

(target="ldap:///cn=config")(targetattr="*")(version 3.0; acl "Monitor config access"; allow (read,search) \
  userdn="ldap:///cn=monitor,cn=administrators,cn=admin data";) 
(target="ldap:///cn=monitor")(targetattr="*")(version 3.0; acl "Monitor access"; allow (read,search) \
  userdn="ldap:///cn=monitor,cn=administrators,cn=admin data";) 


At that stage, config and monitoring stats are available from the OUD admin port to the cn=monitor user (if you choose to use Root Users) or to cn=monitor,cn=administrators,cn=admin data (for Global Admins).:

Friday Jan 30, 2015

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 

Wednesday May 02, 2012

Cohabitation/Migration ODSEE->OUD: privileges

OUD provides a privilege subsystem, which can be used to define capabilities that will be granted to users. The privilege subsystem works in conjunction with the access control implementation in the process of determining whether a user will be allowed to perform a certain operation.

In general, default OUD access control settings are stricter than ODSEE. Appropriate privileges must be added to achieve behavior that is equivalent to that of ODSEE. For instance, by default, OUD ACIs don’t allow users to reset another users’s password. Alternatively, it is possible to disable the privilege subsystem.

By default, normal users are not granted any of the privileges listed above. Therefore, if a user should be allowed to perform any of the associated operations, they must be granted the appropriate privileges. This can be done by adding the ds-privilege-name operational attribute to the user's entry. ds-privilege-name is a multivalued attribute, and if a user is to be given multiple privileges, then a separate value should be used for each one. When the virtual attribute subsystem is in place, it should also be possible to grant privileges to groups of users automatically by making ds-privilege-name a virtual attribute in those user entries.

As an example, the following modification can be used to add the proxied-auth privilege to the user cn=Proxy User,dc=example,dc=com:

dn: cn=Proxy User,dc=example,dc=com
changetype: modify
add: ds-privilege-name
ds-privilege-name: proxied-auth

Granting privileges explictely to users may not be the optimal solution when OUD and ODSEE cohabit in a replication topology as the OUD-specific ds-privilege-name would be replicated by to ODSEE, so privileges can also be assign implicitely to a set of user based on group membership for example, using the notion of virtual attribute. I'll cover Virtual attribute in a subsequent post.

Alternatively, It is possible to disable those privileges leading to aci behavioral differences between OUD and ODSEE. For instance, the  unindexed-search privilege can be disabled  so that users can perform un-indexed searches. A privilege (unindex search checking in the example below) can be disabled using the following command:

set-global-configuration-prop  --add \
disabled-privilege: unindexed-search -n

The list of OUD privileges is available here.


I am Sylvain Duloutre, I work as a Software Architect in the Oracle Directory Integration Team, the customer-facing part of Directory Services & Identity Management Product Development, working on Technical Field Enablement.

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.


« October 2015