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!
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.
$ 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";)
$ 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";)
$ 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";)
$ 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\"\;\)
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";)
$ 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\"\;\)
dn: cn=eusroot,dc=example,dc=com changetype: modify add: ds-privilege-name ds-privilege-name: password-reset
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";)
Refer to Novell documentation to define the appropriate eDirectory rights:
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:
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.
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:
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.
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)
)
)
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)
)
)
$ $ORACLE_HOME/bin/lsnrctl stop $ $ORACLE_HOME/bin/lsnrctl start
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)
)
)
$ 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
$ orapki wallet add -wallet <PathToDBWallet> -cert joe-cert.txt -trusted_cert -pwd <password>
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>
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.
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.
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:
In this post, I will explain how to configure Kerberos authentication. I am assuming that you already have a Kerberos server up and running.
$ 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.
$ scp /tmp/orcl11g.keytab oracle@dbhost:/path/to/orcl11g.keytab
$ 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 $
$ 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
[...]
[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 $
$ 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
$
$ 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
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
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
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.
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
WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /path/to/db/wallet) ) )
$ ls /path/to/db/wallet cwallet.sso ewallet.p12
$ 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>
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:
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.
EUS does not support nested groups. This means that an enterprise role is granted to a user only if the user is a direct member of the group. But it is possible to leverage the LDAP_MATCHING_RULE_IN_CHAIN feature of active directory.
If you perform a ldapsearch against AD with a filter like this: (member:1.2.840.113556.1.4.1941:=cn=myuser,cn=users,dc=example,dc=com)
then AD will return all the groups the user myuser belongs to, including the nested groups.
The trick here is to transform the search filter performed by EUS (member=cn=myuser,cn=users,dc=example,dc=com) into a search with the matching rule (member:1.2.840.113556.1.4.1941:=cn=myuser,cn=users,dc=example,dc=com). This is done by creating a transformation in OUD proxy that operates on the member attribute in a search filter, and inserting this transformation in the processing.
$ dsconfig create-transformation \
--set client-attribute:member=%member:1.2.840.113556.1.4.1941:% \
--type map-attribute \
--transformation-name adrecursivemember
$ dsconfig create-workflow-element \
--set enabled:true \
--set next-workflow-element:proxy-we1 \
--set transformation:adrecursivemember \
--type transformations \
--element-name adrecursivegroupsearch \
--set entry-match-filter:'(objectclass=dummy)'
$ dsconfig set-workflow-element-prop \
--element-name eus-we1 \
--set next-workflow-element:adrecursivegroupsearch
Note that this transformation requires OUD 11gR2PS3 (a bug in older releases prevents its use).
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
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:
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
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.
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>
$ 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.
Florence Blanc-Renaud's technical spot 