New project!

I wanted to thank all the people that followed this blog and showed interest in EUS and OUD. This project was a big milestone in my professional life, I really learned a lot and enjoyed sharing my knowledge.

Since May this year, I moved to a new project as Software Development and Integration Engineer at Red Hat, in the Free IPA team. My new blog posts will still be about Identity Management, but with different products this time. I hope that you will continue to be interested in my articles!

Advertisements

EUS and OUD proxy: configure the proxy to use a non-directory manager user

When OUD is used for EUS as a proxy server, it needs specific credentials to connect to the LDAP server that is actually storing the users and groups.

Those credentials are set in the configuration of the proxy-ldap-workflow-element, through the parameters remote-ldap-server-bind-dn and remote-root-dn. Usually, the credentials for the LDAP server administrator are used: cn=directory manager for ODSEE or OUD, cn=administrator,cn=users,<baseDN> for Active Directory.

Some customers do not want to use the LDAP administrator credentials. In this case, it is possible to use an alternate user identity, but this user must comply with specific requirements depending on the LDAP server flavour.

It is also possible to use 2 different users, one that will be used as remote-root-dn and another one for remote-ldap-server-bind-dn.

Reminder: the remote-ldap-server-bind-dn is the identity used to connect to the LDAP server for all the operations directly performed by the Database. The remote-root-dn is the identity used to perform internal operations triggered by the Database.

For instance, if the database connects to OUD proxy and performs a search for (uid=joe) with a control requesting the user account status, the search may have to be handled in multiple steps by OUD proxy, depending on the LDAP server flavour. A first step would be the actual search on the LDAP server, and a second step would translate the control into an internal extended operation requesting the user account status.

Follow the steps corresponding to your LDAP server.

Active Directory deployments

• The remote-ldap-server-bind-dn must be able to read all the attributes on dc=example,dc=com.
• The remote-root-dn must be able to read all the attributes on dc=example,dc=com.

ODSEE deployments

• The remote-ldap-server-bind-dn must be able to read dc=example,dc=com. You can use the following command to define the required ACI on ODSEE (replace cn=eusproxy,dc=example,dc=com with the appropriate value):

$ ldapmodify -h odseehost -p odseeport -D odseeadmin -w odseepassword
dn: dc=example,dc=com
changetype: modify
add: aci
aci: (targetattr="*")(version 3.0; acl "Read access to eus proxy user"; allow (read, search, compare) userdn="ldap:///cn=eusproxy,dc=example,dc=com";)

• The remote-root-dn must be able to read dc=example,dc=com (replace cn=eusroot,dc=example,dc=com with the appropriate value):

$ ldapmodify -h odseehost -p odseeport -D odseeadmin -w odseepassword
dn: dc=example,dc=com
changetype: modify
add: aci
aci: (targetattr="*")(version 3.0; acl "example"; allow (read,search,compare) userdn="ldap:///cn=eusroot,dc=example,dc=com";)

• The remote-root-dn must be able to use the Password Policy Account Management extended operation

$ ldapmodify -h odseehost -p odseeport -D odseeadmin -w odseepassword
dn: oid=1.3.6.1.4.1.42.2.27.9.6.25,cn=features,cn=config
changetype: modify
add: act
aci: (targetattr != "aci")(version 3.0; acl "Pwd Policy Acct Mgt for eus proxy  user"; allow (read, search, compare) userdn="ldap:///cn=eusroot,dc=example,dc=com";)

• The remote-root-dn must be able to use the Account Usable Control (already allowed by default).

OUD deployments

• The remote-ldap-server-bind-dn must be able to use the control 2.16.840.1.113894.1.8.16. Define a global-aci using:

$ dsconfig -h oudhost -p oudadminport -D "cn=directory manager" -j pwd.txt -X -n set-access-control-handler-prop --add global-aci:\(targetcontrol=\"2.16.840.1.113894.1.8.16\"\)\(version\ 3.0\; acl\ \"Allow\ eusproxy\ user\ to\ use\ EUS\ control\"\; allow\(read\)\ userdn=\"ldap:///cn=eusproxy,dc=example,dc=com\"\;\)

• The remote-ldap-server-bind-dn must be able to read dc=example,dc=com and to write orclaccountstatusevent attribute on users below dc=example,dc=com. Use ldapmodify to create the following aci:

dn: dc=example,dc=com
changetype: modify
add: aci
aci: (targetattr="orclaccountstatusevent")(version 3.0; acl "EUS write orclaccountstatusenabled"; allow (write) userdn="ldap:///cn=eusproxy,dc=example,dc=com";)
aci: (targetattr="*")(version 3.0; acl "EUS reads users and groups"; allow (read,search,compare) userdn="ldap:///cn=eusproxy,dc=example,dc=com";)

• The remote-root-dn must be able to use the Password Policy State extended operation. Define a global-aci using:

$ dsconfig -h oudhost -p oudadminport -D "cn=directory manager" -j pwd.txt -X -n set-access-control-handler-prop --add global-aci:\(extop=\"1.3.6.1.4.1.26027.1.6.1\"\)\(version\ 3.0\; acl\ \"Allow\ eusroot\ user\ to\ use\ extop\"\; allow\(read\)\ userdn=\"ldap:///cn=eusroot,dc=example,dc=com\"\;\)

• The remote-root-dn must have the password reset privilege. Use ldapmodify to add the privilege:

dn: cn=eusroot,dc=example,dc=com
changetype: modify
add: ds-privilege-name
ds-privilege-name: password-reset

• The remote-root-dn must have the rights to read the tree below the base DN. Use ldapmodify to define the following act:

dn: dc=example,dc=com
changetype: modify
add: aci
aci: (targetattr="*")(version 3.0; acl "EUS reads users and groups"; allow (read,search,compare) userdn="ldap:///cn=eusroot,dc=example,dc=com";)

Novell eDirectory deployments

Refer to Novell documentation to define the appropriate eDirectory rights:

• The remote-ldap-server-bind-dn must have read access to all the attributes on dc=example,dc=com.
• The remote-root-dn must be able to retrieve the Universal Password and to write on dc=example,dc=com

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.

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.

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.

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.
     
   • 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.

Tips to troubleshoot EUS + OUD

I am often involved in customer issues involving EUS and OUD, and wanted to share some tips and strategies that could help in this type of situation.

As I am working mainly on OUD, the first thing that I usually check is OUD access log. It is enabled by default and located in $OUD_INSTANCE/OUD/logs/access. This file contains a trace of all the operations received by OUD and is often a great help in understanding where the problem lies.

I usually configure OUD so that it also logs internal operations and LDAP controls:

dsconfig set-log-publisher-prop \
 --publisher-name File-Based\ Access\ Logger \
 --set log-controls:true \
 --add operations-to-log:internal \
 --hostname $OUDHOST \
 --port 4444 \
 --trustAll \
 --bindDN cn=directory\ manager \
 --bindPasswordFile pwd.txt \
 --no-prompt

 

To debug an EUS issue, I perform the failing EUS command and look at the logs generated by this command in OUD access log. For instance, I run sqlplus joe/password and check that the command triggered operations on OUD server:

• if the command does not produce any log, this means that the authentication failed before the database actually contacted the OUD server. In this case, the root cause is likely to be a configuration issue on the database side (for instance the DB points to another LDAP server, or was not able to find its own DN/password in its wallet…)
  The next debugging step will be to enable the logs on the database.
• if the command produces logs in OUD, then the DB correctly points to OUD but there is either a communication issue (SSL, DB authentication…) or an EUS configuration issue (not able to find a user-schema mapping, unable to access the user’s password…)
  Usually the last LDAP operation can provide hints on the root cause. For instance, if the user could not be associated to any shared schema, the last LDAP operation will be a SEARCH with a filter (objectclass=orcldbEntrylevelMapping) or (objectclass=orcldbSubtreelevelMapping) that does not find any entry (nentries=0).

 

After you have identified if the issue happens between the sql client and the DB or between the DB and OUD, you can also have a look at OUD Admin guide, which provides a checklist with common configuration issues in the Troubleshooting section of Chapter 31: Integrating Oracle Unified Directory with Oracle Enterprise User Security.