A Tips and Troubleshooting
This appendix contains usage tips and troubleshooting information about authentication and encryption challenges that may arise. It contains the following sections:
A.1 Optimizing Authentication
This section contains solutions for a number of common problems encountered with authentication in EDQ. Many LDAP configuration problems are the result of typographical errors or unexpected characters in the configuration files; files should be carefully checked in case of problems.
A.1.1 Correcting Excessive LDAP Connections
EDQ automatically regularly updates its internal cache of users from the LDAP directory, which can lead to a large number of connections. If only a small subset of users require access to EDQ, this process can be streamlined by associating EDQ users with an LDAP group and setting the ldap.prof.defaultusergroup option for the realm. EDQ will then constrain the subset of users retrieved to those in that group. See Section 2.6, "Configuring Individual Realm LDAP Settings" for details of the ldap.prof.defaultusergroup option.
A.1.2 Configuring LDAP Server Failover
Configuring LDAP server failover with EDQ integrated LDAP support can be done by specifying multiple servers for a realm. For OPSS, see the WebLogic documentation for details of setting up server failover: http://docs.oracle.com/middleware/1221/wls/SECMG/ldap_atn.htm#SECMG180
A.1.3 Reconciling Multiple User Display Names
In rare cases, the default display names of users may include duplicates. In this case the display name can be configured to be generated from different user properties. The userdisplayname property (in LDAP and OPSS profile configurations) is an expression which can build a value from attributes read from LDAP. Here are two example solutions, showing how users appear in the mail notification dialogue for jobs:
A.1.3.1 Use Email Address, or Login ID if not Set
Override the LDAP profile's userdisplayname option by putting the following in to login.properties:
opss.prof.userdisplayname = mail == '' ? loginid : mail
The example below shows the email notification configuration (of a job) with this setting applied:
Figure A-1 Email Notification Configuration dialog
Description of ''Figure A-1 Email Notification Configuration dialog''
Here reg123 is the single user who does not have an email address, so their login ID is displayed instead.
Note that if integration is through OPSS, AD attributes cannot be used directly; instead you would use one of the names listed with the IGF UserProfile class. The loginid OPSS attributes maps to the User Name Attribute set in WLS; if you switch this from sAMAccountName (the Windows login ID) to cn the list changes to:
Figure A-2 Email Notification Configuration dialog used to reconcile display names
Description of ''Figure A-2 Email Notification Configuration dialog used to reconcile display names''
Here the final name is the cn value for the user with sAMAccountName = reg123.
A.1.3.2 Use Email Address and Login ID
If there are any duplicate email addresses in AD, the exception will still occur, so in this case you can combine the email address with the login ID to ensure the string is unique.
opss.prof.userdisplayname = mail == '' ? loginid : mail || ' (' || loginid || ')'
The result is:
Figure A-3 Combining email address with login to create a unique string
Description of ''Figure A-3 Combining email address with login to create a unique string''
A.1.4 Resolving Error Messages
This section contains common error messages and their solutions.
A.1.4.1 Error processing GSS server login
GSS errors when configuring EDQ to authenticate against an LDAP server are likely to indicate that the method for authenticating to the LDAP server (ldap.auth) is not set, and gss has been used as a default. Typically this would be set to simple. See Section 2.5, "Using LDAP Server Profile" for details on the ldap.auth setting.
A.1.4.2 Invalid argument (400) - Cannot find key of appropriate type to decrypt…
This error can occur when integrating EDQ with Kerberos, and indicates that the keytab file on the EDQ server does not support the required encryption type. To correct this, the keytab file must be updated to support the missing encryption type. See the documentation for the ktpass tool for further details: https://technet.microsoft.com/en-us/library/cc753771.aspx
(for additional background information, see also: https://community.oracle.com/thread/1527533
A.1.4.3 Cannot insert null in DN_EXTUSERMAP.OBJECT_KEY
This error can occur where an external domain is configured to use a field which can be null as the unique ID for a user. For example, with AD integration, normally the objectguid attribute in AD is used to provide a unique identifier for users, however if it is changed to a different attribute, this error could arise if the named attribute is missing or empty on a user record.
A.2 Optimizing Encryption
This section contains solutions for a number of common problems encountered with encryption in EDQ.
A.2.1 Untrusted Certificate Errors
Untrusted certificate errors indicate that the client does not trust the X.509 certificate presented by the server for a TLS connection. This can be for various reasons, although the most common is that the client cannot verify the chain of certificates used to verify the certificate that the server presents. Other reasons might be that the certificate is out of date, or is not yet valid (certificates have date ranges for which they are valid), or that the certificate was issued for a different server than the one being connected to.
Certificates are trusted based on either the client knowing the certificate already (that is, it's pre-installed, often shipped with the operating system), or it being signed by a certificate the client trusts. Servers present a certificate that identifies themselves, along with a signature from a certificate the client trusts (trusted root). Optionally server certificates may have intermediary certificates which are signed by the trusted root, and sign the server certificate, forming a chain of certificates to be validated by the client. These intermediary certificates and signatures are presented to the client along with the server certificate.
Common problems here include self-signed server certificates, server certificates which are not signed by a certificate authority the client trusts, and missing intermediate certificates or signatures.
A.2.1.1 Connecting to EDQ (HTTPS)
When connecting to EDQ the server certificate is managed by WebLogic Server or Apache Tomcat, and as such any problems with untrusted certificates must be resolved by following the instructions for the relevant server.
A.2.1.2 Connecting to LDAP (EDQ Integrated)
EDQ verifies server certificates when connecting to LDAP over TLS, and where servers use certificates that are not automatically recognized, certificates must either be installed into EDQ or verification-disabled. Certificate verification can be disabled by using Start TLS rather than TLS (this is an EDQ-specific behavior difference). See Section 2.7, "Validating Credentials When Single Sign-On Is Not Used" for details.
A better solution is to extract the certificate from the LDAP server and install it in the EDQ server so that it is recognized as being trusted.See Section 2.7, "Validating Credentials When Single Sign-On Is Not Used" for details.
A.2.1.3 Connecting to LDAP (WebLogic with OPSS)
For instructions on managing the key/certificate stores used by WebLogic, see the Fusion Middleware Administrator's Guide. For instructions on importing certificates into WebLogic Server, see https://docs.oracle.com/middleware/1221/opss/JISEC/cfgauthr.htm#JISEC2293
A.3 Optimizing Auditing
This section contains information about auditing in EDQ.
A.3.1 ”BAD PASSWORD” Events Not Captured for External Domain
Where authentication is handled by an external system such as OID or AD, EDQ's audit trails do not include events such as bad passwords, as these are managed by the external authentication system. Auditing for such events must be configured in the external system.
All events will be captured as normal for any internal domain.