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 

Tuesday Feb 04, 2014

Binding a server to privileged port on Linux w/o running as root

This is applicable to any service using privileged ports (< 1024), for instance to run a HTTP server on port 80 or a LDAP directory server on port 389.

  • Running the server as root is not a recommended option for security reasons.
  • Using iptables to map privileged port (e.g. 389) to non-privileged port is a well-know method.
  • Updating the Linux config to put 389 on the non-privileged port list is another option.

There is another option that I use frequently, based on setcap to run OUD on port 389 in my labs:

This solution requires install and modification of a java 7 JVM specifically for OUD use.

Such configuration has security implications, as anyone running that JVM has the right to bind on privileged ports (settings are JVM wide, not restricted to a specific jar file/application), so the jvm access should be restricted to the appropriate user only (the one allowed to start OUD)

Here is the procedure:

  1. download patchelf sources from here and compile them on target Linux.
  2. install setcap package on Linux if needed
  3. install a java 7 SDK on target system e.g. /space/java/jdk1.7.0_45
  4. restrict access to that jvm (java and jre) to the appropriate user only (the one used to start OUD).
    Put in place additional security if needed.
  5. as root, run the following commands to allow java to bind as priviledged ports

    setcap cap_net_bind_service=+epi <JAVA_HOME>/bin/java
    setcap cap_net_bind_service=+epi <JAVA_HOME>/jre/bin/java

  6. - change java dynamic library loading strategy as default strategy is not compatible with setcap

    patchelf --set-rpath <JAVA_HOME>/jre/lib/amd64/jli <JAVA_HOME>/jre/bin/java
    patchelf --set-rpath <JAVA_HOME>/lib/amd64/jli <JAVA_HOME>/bin/java

  7. - Modify jvm used by oud

    edit and modify property e.g
    run dsjavaproperties

  8. - start OUD with standard start-ds command.

Wednesday Feb 08, 2012

Oracle Unified Directory Root DSE entry and schema

The root DSE entry (empty dn) is often used by LDAP client applications to discover directory services capabilities.  For instance, attribute namingContexts gives indications about the suffixes managed by the directoy server instance. All these attributes are flagged as OPERATIONAL, so, they should not be returned to client applications unless they are explicitely specified in the search attribute list.

OUD strictly adheres to LDAP standards so these attributes are not returned by default. In Oracle Directory Server Entreprise Edition (ODSEE), these attributes are treated as standard ones and are systematically returned to client applications. Applications depending on the ODSEE behaviour might be impacted as many of them do no specify any search attribute list. To make OUD behave like ODSEE with regards to the access of rootDSEE attributes, run the following command:

dsconfig set-root-dse-backend-prop --set show-all-attributes:true

To make OUD treat schema operational attribute like user attributes, run the following too:

dsconfig set-workflow-element-prop --element-name schema --set show-all-attributes:true


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.


« November 2015