Category Archives: OUD

Use an alternate identity for EUS configuration

During EUS setup, the administrator needs to provide a user DN and password to authenticate to the directory server (for instance during the dbca step, or while using eusm or Enterprise Manager).

 

In some companies, the database and the LDAP server are managed by different teams and the LDAP administrator credentials cannot be provided to the database administrator. In this case, it is possible to administer EUS using an alternate identity, i.e not cn=directory manager. The requirements for this alternate identity are the following:

  • the user must be a member of the group cn=OracleContextAdmins,cn=Groups,cn=OracleContext,<base DN>
  • the user must have the password-reset privilege

 

Here is an example of configuration steps: create a input.ldif file with the following content

$ cat input.ldif
dn: cn=eusadmin,cn=oraclecontext
changetype: add
objectclass: inetorgperson
cn: eusadmin
sn: eusadmin
uid: eusadmin
userpassword: password

dn: cn=eusadmin,,cn=oraclecontext
changetype: modify
add: ds-privilege-name
ds-privilege-name: password-reset

dn: cn=OracleContextAdmin,cn=groups,cn=OracleContext,dc=example,dc=com
changetype: modify
add: uniquemember
uniquemember: cn=eusadmin,cn=oraclecontext

And perform

$ $ORACLE_HOME/bin/ldapmodify -h localhost -p 1389 -D "cn=directory manager" -w password -f input.ldif

Note 1: this EUS admin user can be stored in your preferred location inside the DIT, but NOT BELOW cn=oraclecontext,<base DN>. For instance, cn=eusadmin,ou=people,dc=example,dc=com is valid, but cn=eusadmin,cn=oraclecontext,dc=example,dc=com is NOT valid.

Note 2: the EUS admin user does not have to be named eususer.

Note 3: if OUD is installed as a proxy server, then the EUS admin user must be stored locally inside OUD proxy, and for instance cn=eususer,cn=oraclecontext would be a valid location.

Advertisements

How to configure EUS + SSL authentication with OUD

During an EUS authentication, there are 2 communication channels: one between the sql client and the database, and another one between the database and the LDAP server. In a previous post, I explained that the database-to-OUD communication can be authenticated either through user/password or SSL.

EUS_auth

The sql client-to-database connection also supports multiple authentication methods:

  • user/password
  • SSL
  • Kerberos (described in this post)

In this post, I will explain how to configure SSL authentication. Note that SSL authentication is usually used in conjunction with DB-to-OUD SSL authentication. This post assumes that DB-to-OUD SSL authentication has already been set up as described there and that the database already has a wallet containing the DB certificate.

Using sqlplus, it is possible to connect to the DB using a client certificate instead of username/password. In order to do this, the DB must be configured with an SSL listener, and the sqlplus client must be configured to use a client certificate.

  1. Configure the database to allow SSL authentication:
    The file sqlnet.ora located in $ORACLE_HOME/network/admin must be modified to look like the following:

    NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
      
    ADR_BASE = <$ORACLE_BASE>
    
    #ADDED FOR SSL 
    SQLNET.AUTHENTICATION_SERVICES= (TCPS, BEQ)
    SSL_CLIENT_AUTHENTICATION = TRUE
    WALLET_LOCATION = 
      (SOURCE =
        (METHOD = FILE)
        (METHOD_DATA =
          (DIRECTORY = <$ORACLE_BASE>/admin/<$ORACLE_SID>/wallet)
        )
      )
  2. Configure a SSL listener on the database:
    The listeners are defined in the configuration file listener.ora, located in $ORACLE_HOME/network/admin. The content of this file defines the port and protocol used by the listener, and the location of the wallet that will store the database certificate.

    LISTENER =
      (DESCRIPTION_LIST =
        (DESCRIPTION =
          (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
          (ADDRESS = (PROTOCOL = TCP)(HOST = <hostname>)(PORT = 1521))
    #ADDED FOR SSL
          (ADDRESS = (PROTOCOL = TCPS)(HOST = <hostname>)(PORT = 1575))
        )
      )
    
    ADR_BASE_LISTENER = <$ORACLE_BASE>
    
    #ADDED FOR SSL
    WALLET_LOCATION = (SOURCE=
      (METHOD = FILE)
        (METHOD_DATA =
          (DIRECTORY=<$ORACLE_BASE>/admin/<$ORACLE_SID>/wallet)
        )
      )
    
  3. Restart the listener:
    the modification of listeners.ora requires to restart the database listener with the following commands

    $ $ORACLE_HOME/bin/lsnrctl stop
    $ $ORACLE_HOME/bin/lsnrctl start
  4. Configure the sql client to use SSL authentication:

    The sql client reads its configuration from sqlnet.ora and tnsnames.ora. By default, those files are located in the same location as the DB configuration files ($ORACLE_HOME/network/admin), which can cause issues because the client and the server use a different wallet. In order to avoid configuration issues, it is recommended to have separate configuration files. To do this, the environment variable TNS_ADMIN is used to configure the path containing the client configuration files:

    $ setenv TNS_ADMIN /path/to/files
    

    or

    $ export TNS_ADMIN=/path/to/files
    

    Then the file tnsnames.ora will define how to reach the database using SSL:

    $ cat /path/to/files/tnsnames.ora 
    ORCL11G =
      (DESCRIPTION =
        (ADDRESS = (PROTOCOL = TCPS)(HOST = <hostname>)(PORT = 1575))
        (CONNECT_DATA =
          (SERVER = DEDICATED)
          (SERVICE_NAME = orcl11g)
        )
      )
    

    And finally the file sqlnet.ora defines the SSL configuration (wallet location…):

    $ cat sqlnet.ora 
    NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
    SQLNET.AUTHENTICATION_SERVICES = (TCPS,BEQ)
    SSL_CLIENT_AUTHENTICATION = TRUE 
    WALLET_LOCATION =
      (SOURCE =
        (METHOD = FILE)
        (METHOD_DATA =
          (DIRECTORY = /path/to/client/wallet)
        )
      )
  5. Create the client wallet and the client certificate:
    The client wallet will store the client certificate as well as the certificates trusted by the client (i.e. the server certificate).
    The client certificate must contain a DN that corresponds to a LDAP entry on OUD server. The following commands create a client wallet, then add a self-signed certificate to the wallet for the user cn=Joe, and finally export the self-signed certificate to a file.

    $ orapki wallet create -wallet /path/to/client/wallet -pwd <password> -auto_login
    
    $ orapki wallet add -wallet /path/to/client/wallet -dn cn=Joe,ou=users,dc=example,dc=com -keysize 1024 -self_signed -validity 365 -pwd <password>
    
    $ orapki wallet export -wallet /path/to/client/wallet -dn cn=Joe,ou=users,dc=example,dc=com -cert joe-cert.txt
    

  6. Add the client certificate to the DB wallet:
    the database must trust the client certificate in order to accept SSL connections. As the above steps created a self-signed user certificate, the client certificate has to be imported as a trusted cert in the DB wallet.

    $ orapki wallet add -wallet <PathToDBWallet> -cert joe-cert.txt -trusted_cert -pwd <password>
    
  7. Add the DB certificate to the client wallet:
    the client must trust the DB certificate. If the DB certificate is a self-signed certificate, this means that the DB cert must be added to the client wallet.

    $ orapki wallet add -wallet /path/to/client/wallet -cert db-cert.txt -trusted_cert -pwd <password>
  8. Allow EUS to accept SSL connections between the client and the database:

     log in to Enterprise Manager: https://<hostname>:1158/em

    In the “Server” tab, select “Enterprise User Security” in the “Security” section, then “Manage Enterprise Domain” and click on “Configure”. In the “Configuration” tab, select the authentication methods that you want to allow between the client and the DB: Password, SSL, Kerberos.

  9. Test the SSL connection between the client and the database:

    The following command reads the sql configuration files, extracts the path to the client wallet, then connects to the DB using the certificate found in the client wallet:

    $ export TNS_ADMIN=/path/to/files
    $ sqlplus /@orcl11g
    
    SQL*Plus: Release 11.2.0.2.0 Production on Wed Mar 28 11:18:57 2012
    
    Copyright (c) 1982, 2010, Oracle.  All rights reserved.
    
    
    Connected to:
    Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    
    SQL>

Once authenticated with the client certificate, the enterprise user will be mapped to a schema exactly as a user/password authenticated user. EUS will also find the groups for the LDAP user and grant the corresponding roles to the EUS user.

How to configure EUS + Kerberos authentication with OUD

During an EUS authentication, there are 2 communication channels: one between the sql client and the database, and another one between the database and the LDAP server. In a previous post, I explained that the database-to-OUD communication can be authenticated either through user/password or SSL.

EUS_auth

The sql client-to-database connection also supports multiple authentication methods:

  • user/password
  • SSL
  • Kerberos

In this post, I will explain how to configure Kerberos authentication. I am assuming that you already have a Kerberos server up and running.

 

  1. Create a Kerberos Principal for the Database:
    The database service needs to have a corresponding Kerberos principal in the Kerberos server. If your Kerberos server is running on a Linux machine, this can be done with the kadmin utility. In my example, the kerberos administrator is kws/admin and creates a principal for the database having ORACLE_SID=orcl11g, running on host dbhost, with a Kerberos realm EXAMPLE.COM:

    $ kadmin -p kws/admin
    Authenticating as principal kws/admin with password.
    Password for kws/admin@EXAMPLE.COM: 
    kadmin:  add_principal -randkey orcl11g/dbhost
    WARNING: no policy specified for orcl11g/dbhost@EXAMPLE.COM; defaulting to no policy
    Principal "orcl11g/dbhost@EXAMPLE.COM" created.
    kadmin: ktadd -k /tmp/orcl11g.keytab orcl11g/dbhost@EXAMPLE.COM
    Entry for principal orcl11g/dbhost@EXAMPLE.COM with kvno 2, encryption type AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/tmp/orcl11g.keytab.
    Entry for principal orcl11g/dbhost@EXAMPLE.COM with kvno 2, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/tmp/orcl11g.keytab.
    Entry for principal orcl11g/dbhost@EXAMPLE.COM with kvno 2, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/tmp/orcl11g.keytab.
    Entry for principal orcl11g/dbhost@EXAMPLE.COM with kvno 2, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/tmp/orcl11g.keytab.
    kadmin:  exit

    The add_principal command creates a principal, and the ktadd command creates and stores the secret key in the file /tmp/orcl11g.keytab.

  2. Copy the keytab to the database host:
    $ scp /tmp/orcl11g.keytab oracle@dbhost:/path/to/orcl11g.keytab
  3. Create a Kerberos principal for the EUS user:
    The user that will use sqlplus also needs to be provisioned in the KDC. In the example, the user principal name is eususer@EXAMPLE.COM:

    $ kadmin -p kws/admin
    Authenticating as principal kws/admin with password.
    Password for kws/admin@EXAMPLE.COM: 
    kadmin:  add_principal eususer
    WARNING: no policy specified for eususer@EXAMPLE.COM; defaulting to no policy
    Enter password for principal "eususer@EXAMPLE.COM": 
    Re-enter password for principal "eususer@EXAMPLE.COM": 
    Principal "eususer@EXAMPLE.COM" created.
    kadmin:  exit
    $
  4. Configure the database to allow Kerberos authentication:
    By default the database supports only user/password authentication. In order to allow Kerberos authentication, the file sqlnet.ora (located in $ORACLE_HOME/network/admin) needs to be modified to look like the following:

    $ cat sqlnet.ora
    NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
    ADR_BASE = /export/home/oracle/app/oracle
    
    #ADDED FOR KERBEROS
    SQLNET.AUTHENTICATION_SERVICES= (BEQ, KERBEROS5)
    SQLNET.AUTHENTICATION_KERBEROS5_SERVICE=orcl11g
    SQLNET.KERBEROS5_CONF=/etc/krb5.conf
    SQLNET.KERBEROS5_KEYTAB=/path/to/orcl11g.keytab
    SQLNET.KERBEROS5_CONF_MIT=true
    
    
  5. Configure the database host as a Kerberos client:
    Edit /etc/krb5.conf and set the values for the Kerberos server in kdc and admin_server properties. In my example, the Kerberos server is running on kdc_host.fr.oracle.com:

    [...]
    [libdefaults]
     default_realm = EXAMPLE.COM
     dns_lookup_realm = false
     dns_lookup_kdc = false
     ticket_lifetime = 24h
     forwardable = yes
    [realms]
     EXAMPLE.COM = {
      kdc = kdc_host.fr.oracle.com
      admin_server = kdc_host.fr.oracle.com
     }
    [domain_realm]
     .example.com = EXAMPLE.COM
     example.com = EXAMPLE.COM
     .fr.oracle.com = EXAMPLE.COM
     fr.oracle.com = EXAMPLE.COM
    [...]

    You can test that the database host is properly configured by trying to get a Kerberos ticket-granting ticket for the database with the kinit utility:

    $ kinit -k -t /path/to/orcl11g.keytab orcl11g/dbhost@EXAMPLE.COM
    $ klist
    Ticket cache: FILE:/tmp/krb5cc_54321
    Default principal: orcl11g/dbhost@EXAMPLE.COM
    Valid starting Expires Service principal
    03/03/16 11:35:50 03/03/16 21:35:50 krbtgt/EXAMPLE.COM@EXAMPLE.COM
     renew until 03/04/16 11:35:50
    Kerberos 4 ticket cache: /tmp/tkt54321
    klist: You have no tickets cached
    $
  6. Configure the sql client host as a Kerberos client:
    this step is the same as the previous one (edition of /etc/krb5.conf), except that it must be done on the host where the sql client is running. You can test that the Kerberos configuration is working by getting a ticket-granting ticket for the Enterprise user:

    $ kinit eususer
    Password for eususer@EXAMPLE.COM: 
    $ klist
    Ticket cache: FILE:/tmp/krb5cc_54321
    Default principal: eususer@EXAMPLE.COM
    
    Valid starting     Expires            Service principal
    03/29/12 16:32:41  03/30/12 02:32:41  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 03/30/12 16:32:38
    
    
    Kerberos 4 ticket cache: /tmp/tkt54321
    klist: You have no tickets cached
    $
    
  7. Configure the sql client to authenticate with Kerberos:
    Create a directory to store the SQL client configuration, and define the environment variable TNS_ADMIN to point to this directory:

    $ mkdir -p /path/for/sql/config
    $ export TNS_ADMIN=/path/for/sql/config

    In this directory, create a tnsnames.ora file defining how to contact the database:

    $ cat $TNS_ADMIN/tnsnames.ora
    ORCL11G = (DESCRIPTION =
     (ADDRESS = (PROTOCOL = TCP)(HOST = dbhost)(PORT = 1521))
     (CONNECT_DATA = (SERVER = DEDICATED)(SERVICE_NAME = orcl11g))
     )

    In the same directory, create a sqlnet.ora file defining the connection method to the database:

    $ cat $TNS_ADMIN/sqlnet.ora 
    NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
    SQLNET.AUTHENTICATION_SERVICES = (BEQ,KERBEROS5)
    SQLNET.KERBEROS5_CONF=/etc/krb5.conf
    SQLNET.KERBEROS5_CONF_MIT=true
  8. Link the LDAP user entry to the Kerberos principal:
    The Kerberos principal that will be used with SQL client must correspond to a LDAP user. In order to do this, you have 2 options:

    • if your LDAP users have the objectclass orcluserV2, you can add the attribute krbprincipalname to the user entry. For instance, if Kerberos principal eususer must correspond to LDAP entry cn=user,dc=example,dc=com, you must add krbprincipalname: eususer@EXAMPLE.COM to the entry.
      EUS_kerberos_auth
    • if your LDAP users do not have the objectclass orcluserV2, you can user another attribute to store the Kerberos principal name. In this case, you must declare this attribute by setting the attribute orclcommonkrbprincipalattribute of the entry cn=Common,cn=Products,cn=OracleContext,dc=example,dc=com. For instance:
      dn: cn=Common,cn=Products,cn=OracleContext,dc=example,dc=com
      orclcommonkrbprincipalattribute: mail

      will correspond to a user entry

       dn: cn=user,dc=example,dc=com
       mail: eususer@EXAMPLE.COM
  9. Test the connection:

    The user must first get a Kerberos ticket-granting ticket, then call sqlplus with the / option that specifies to use the Kerberos TGT:

    $ kinit eususer
    Password for eususer@EXAMPLE.COM: 
    $ klist
    Ticket cache: FILE:/tmp/krb5cc_54321
    Default principal: eususer@EXAMPLE.COM
    
    Valid starting     Expires            Service principal
    03/29/12 16:47:29  03/30/12 02:47:29  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 03/30/12 16:47:27
    
    
    Kerberos 4 ticket cache: /tmp/tkt54321
    klist: You have no tickets cached
    $ sqlplus /@orcl11g
    
    SQL*Plus: Release 11.2.0.2.0 Production on Thu Mar 29 16:47:35 2012
    
    Copyright (c) 1982, 2010, Oracle.  All rights reserved.
    
    
    Connected to:
    Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    
    SQL> exit
    Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    $ klist
    Ticket cache: FILE:/tmp/krb5cc_54321
    Default principal: eususer@EXAMPLE.COM
    
    Valid starting     Expires            Service principal
    03/29/12 16:47:29  03/30/12 02:47:29  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 03/30/12 16:47:27
    03/29/12 16:47:35  03/30/12 02:47:29  orcl11g/dbhost@EXAMPLE.COM
        renew until 03/30/12 16:47:27
    
    
    Kerberos 4 ticket cache: /tmp/tkt54321
    klist: You have no tickets cached
    $ 
    
    

    You can see using klist utility that after the sql connection, the user has a second ticket corresponding to the database service.

Troubleshooting tips:

If your setup is not working, you can enable Kerberos logs by adding the following in the /etc/krb5.conf of the Kerberos server:

[logging]
 kdc = FILE:/var/log/krb5kdc.log

then restart the KDC to apply the changes:

$ sudo service krb5-kdc restart

The problem can be linked to the host names (if the database hostname is defined as a fully-qualified-domain-name but the database service principal uses only the short name or vice-versa). The logs will show you which service principal is used by the database and if there is a mismatch.

Another common problem is when the database is not able to find any user entry matching the Kerberos principal from the ticket. In this case, you can have a look at OUD access log and check the search done by the database to find the user entry. This will be a search equivalent to:

$ ldapsearch -b <orclcommonusersearchbase> "(<orclcommonkrbprincipalattribute>=<krb_principal from the ticket>)"

You need to make sure that the database is using the proper search base and search filter. The search base is configured in the entry cn=Common,cn=Products,cn=OracleContext,dc=example,dc=com, in the attribute orclcommonusersearchbase. To find its value, you can perform the following search operation:

$ OracleUnifiedDirectory/bin/ldapsearch -h $LDAPSERVER -p $PORT -b cn=common,cn=products,cn=oraclecontext,$BASEDN  "(objectclass=*)" orclcommonusersearchbase
dn: cn=Common,cn=Products,cn=OracleContext,dc=example,dc=com
orclcommonusersearchbase: ou=people,dc=example,dc=com


EUS: ORA-28030 error with CONNECT/DISCONNECT in OUD logs

You may face the following issue with EUS and OUD. When trying to authenticate using sqlplus, the authentication fails and sqlplus displays:

ORA-28030: Server encountered problems accessing LDAP directory service

Unfortunately, OUD access logs do not help a lot as you can find only the following:

[23/Feb/2016:13:48:29 +0100] CONNECT conn=73 from=10.166.139.54:30238 to=10.166.139.64:1636 protocol=LDAPS
[23/Feb/2016:13:48:29 +0100] DISCONNECT conn=73 reason="Client Disconnect"

 

This type of error happens when the database is not able to find its credentials in its wallet. To troubleshoot, first check which wallet is picked by the database, then make sure that the wallet contains the DN and password for the database.

  1. Enable the database logs to find the wallet location
    Edit $ORACLE_HOME/network/admin/sqlnet.ora and add the following lines:

    DIAG_ADR_ENABLED=OFF
    TRACE_DIRECTORY_SERVER=/path/to/logs/server
    TRACE_LEVEL_SERVER=16
    TRACE_LEVEL_CLIENT=16
    TRACE_DIRECTORY_CLIENT=/path/to/logs/client
    
    
  2. run the sqlplus command and examine the logs in /path/to/logs/server. They will contain references to WALLET_LOCATION and display the path used to find the wallet.
  3. If the path is not consistent with your expectations (by default the wallet is in $ORACLE_BASE/admin/$ORACLE_SID/wallet), edit $ORACLE_HOME/network/admin/sqlnet.ora and add the following lines:
    WALLET_LOCATION =
      (SOURCE =
        (METHOD = FILE)
        (METHOD_DATA =
          (DIRECTORY = /path/to/db/wallet)
        )
      )
    
    
  4. Make sure that the specified wallet is an auto-login wallet (the wallet directory must contain a cwallet.sso file):
    $ ls /path/to/db/wallet
    cwallet.sso ewallet.p12
  5. Make sure that the specified wallet contains a DN and password for the database (they were generated by dbca when the database was registered in the LDAP server):
    $ mkstore -wrl /path/to/db/wallet -viewEntry ORACLE.SECURITY.DN
    Oracle Secret Store Tool : Version 11.2.0.2.0 - Production
    Copyright (c) 2004, 2010, Oracle and/or its affiliates. All rights reserved.
    Enter wallet password: ******** 
    ORACLE.SECURITY.DN = cn=orcl11gr2,cn=OracleContext,dc=eusovd,dc=com
    
    $ mkstore -wrl /path/to/db/wallet -viewEntry ORACLE.SECURITY.PASSWORD
    Oracle Secret Store Tool : Version 11.2.0.2.0 - Production
    Copyright (c) 2004, 2010, Oracle and/or its affiliates. All rights reserved.
    Enter wallet password: ******** 
    ORACLE.SECURITY.PASSWORD = <password generated by dbca>
    
    
  6. If it is not the case, you can re-run dbca and choose to generate a new password. dbca will then create the ORACLE.SECURITY.DN and ORACLE.SECURITY.PASSWORD entries in the wallet.

EUS, OUD and dynamic groups

EUS allows to define enterprise roles or proxy permissions and assign them to all the members of a given group. The issue is that EUS supports only static groups (it expects the groups to have the objectclass “groupofuniquenames” or “groupofnames”), and eusm will fail to grant an Enterprise Role to a dynamic group with the following error:

$ eusm grantRole enterprise_role=my_role domain_name=OracleDefaultDomain realm_dn=dc=example,dc=com group_dn=cn=dyngroup,ou=groups,dc=example,dc=com ldap_host=$OUD_HOST ldap_port=1389 ldap_user_dn="cn=directory manager" ldap_user_password=$PWD
EUSException: There is no such group in directory

Enterprise Manager will also fail with this type of message, even though the group exists:

Configure Domain : OracleDefaultDomain - Errors
my_role - cn=dyngroup,ou=groups,dc=example,dc=com : EUSException: There is no such group in directory

 

OUD provides a nice feature to workaround this issue: Virtual Static Groups. You need to create a virtual static group that will appear as a static group to Enterprise User Security, but mirrors a dynamic group.

For instance, perform a ldapmodify with the following ldif to define a virtual static group for your group cn=dyngroup:

dn: cn=virtualstatic,ou=groups,dc=example,dc=com
cn: virtualstatic
ds-target-group-dn: cn=dyngroup,ou=groups,dc=example,dc=com
objectclass: groupofuniquenames
objectclass: ds-virtual-static-group
objectclass: top

You will then be able to use this group instead of the dynamic group in eusm or EM, and you can still benefit from the dynamicity of the original group:

$ eusm grantRole enterprise_role=my_role domain_name=OracleDefaultDomain realm_dn=dc=example,dc=com group_dn=cn=virtualstatic,ou=groups,dc=example,dc=com ldap_host=$OUD_HOST ldap_port=1389 ldap_user_dn="cn=directory manager" ldap_user_password=$PWD

How to use SSL authentication between the EUS database and OUD

During an EUS authentication, Oracle Database connects to OUD server using a simple bind over SSL. The username and the password are stored in the database wallet (default location is $ORACLE_BASE /admin/<ORACLE_SID>/wallet), and can be read using the mkstore command:

$ $ORACLE_HOME/bin/mkstore -wrl $ORACLE_BASE/admin/$ORACLE_SID/wallet -viewEntry ORACLE.SECURITY.DN
Oracle Secret Store Tool : Version 11.2.0.2.0 - Production
Copyright (c) 2004, 2010, Oracle and/or its affiliates. All rights reserved.

Enter wallet password: 
 
ORACLE.SECURITY.DN = cn=orcl11g,cn=OracleContext,dc=example,dc=com
$ $ORACLE_HOME/bin/mkstore -wrl $ORACLE_BASE/admin/$ORACLE_SID/wallet -viewEntry ORACLE.SECURITY.PASSWORD
Oracle Secret Store Tool : Version 11.2.0.2.0 - Production
Copyright (c) 2004, 2010, Oracle and/or its affiliates. All rights reserved.

Enter wallet password: 
 
ORACLE.SECURITY.PASSWORD = rIwfee96
$

This behavior can be changed, and the Database can switch to certificate authentication over SSL. In order to do this:

  1. Create a certificate for the Database

    For testing purpose, it is possible to create a self-signed certificate using the orapki utility (located in $ORACLE_HOME/bin).

    $ orapki wallet add -wallet <PathToDBWallet> -dn cn=<ORACLE_SID>,cn=oraclecontext,dc=example,dc=com -keysize 1024 -self_signed -validity 365 -pwd <WalletPassword>
    

    The DB certificate must then be exported to a file:

    $ orapki wallet export -wallet <PathToDBWallet> -dn cn=<ORACLE_SID>,cn=oraclecontext,dc=example,dc=com -cert db-cert.txt
    
  2. Add the DB certificate to OUD truststore

    By default, OUD installed with EUS option configures SSL and a JKS truststore. The trusted certificates must be imported into <OUD_INSTANCE>/config/truststore using /usr/bin/keytool utility:

    $ keytool -importcert -alias db-cert  -file db-cert.txt -keypass <value in keystore.pin> -keystore <OUD_INSTANCE>/config/truststore -storepass <value in keystore.pin>
    

    OUD must be stopped and restarted for the truststore to be re-read.

  3. Add OUD certificate to the DB wallet

    By default, OUD uses a self-signed certificate that must be added to the DB truststore. You first need to export the certificate using keytool:

    $ keytool -exportcert  -alias server-cert -keystore <OUD_INSTANCE>/config/keystore -storepass <value in keystore.pin> -file oud-cert.txt
    

    Then the certificate must be imported in the DB wallet using orapki:

    $ orapki wallet add -wallet <PathToDBWallet> -cert oud-cert.txt -trusted_cert -pwd <WalletPassword>
    
  4. Configure the DB to use certificate authentication instead of password authentication.
    $ sqlplus sys as sysdba
    
    SQL*Plus: Release 11.2.0.2.0 Production on Thu Feb 4 10:55:59 2016
    
    Copyright (c) 1982, 2010, Oracle. All rights reserved.
    
    Enter password: 
    
    Connected to:
    Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    
    SQL> ALTER SYSTEM SET LDAP_DIRECTORY_ACCESS = SSL;
    
    System altered.
    
    SQL>
    

    The possible values for LDAP_DIRECTORY_ACCESS are NONE, PASSWORD or SSL, and govern the authentication method between the Database and OUD server.

EUS and SSLv3 issues

Starting with JDK 7u75 release, the SSLv3 protocol (Secure Socket Layer) has been deactivated and is not available by default. If your OUD server is running with JDK 7u75 or higher, you may experience issues with EUS when trying to authenticate:

ORA-28030: Server encountered problems accessing LDAP directory service

And OUD access log will display the following error:

[08/Jan/2016:10:43:13 +0100] CONNECT conn=26 from=10.166.139.54:48916 to=10.166.139.54:1636 protocol=LDAPS
[08/Jan/2016:10:43:13 +0100] DISCONNECT conn=26 reason="I/O Error" msg="Client requested protocol SSLv3 not enabled or not supported"

The proper method to fix this issue is to apply patch 19285025 on the database, which will fix the LDAP library used to perform the connection between the database and OUD and use another algorithm.

A quick workaround is to edit the file $JRE_HOME/lib/security/java.security and remove “SSLv3” from the line defining jdk.tls.disabledAlgorithms (on the machine where OUD runs, for the java version used by OUD), then stop and restart OUD. This will allow OUD to use SSLv3. Note that this workaround should not be applied in production as SSLv3 is obsolete and should not be used anymore. The correct fix is to patch the database.