Skip Navigation Links | |
Exit Print View | |
Oracle Fusion Middleware Administration Guide for Oracle Unified Directory 11g Release 1 (11.1.1) |
1. Starting and Stopping the Server
2. Configuring the Server Instance
3. Configuring the Proxy Components
4. Configuring Security Between Clients and Servers
Getting SSL Up and Running Quickly
To Accept SSL-Based Connections Using a Self-Signed Certificate
Configuring Key Manager Providers
Using the JKS Key Manager Provider
To Sign the Certificate by Using an External Certificate Authority
To Configure the JKS Key Manager Provider
Using the PKCS #12 Key Manager Provider
Using the PKCS #11 Key Manager Provider
Developing Custom Key Manager Providers
Configuring Trust Manager Providers
Overview of Certificate Trust Mechanisms
Using the Blind Trust Manager Provider
Using the JKS Trust Manager Provider
Using the PKCS #12 Trust Manager Provider
Configuring Certificate Mappers
Using the Subject Equals DN Certificate Mapper
Using the Subject Attribute to User Attribute Certificate Mapper
Using the Subject DN to User Attribute Certificate Mapper
Using the Fingerprint Certificate Mapper
Configuring SSL and StartTLS for LDAP and JMX
Configuring the LDAP and LDAPS Connection Handlers
To Enable a Connection Handler
To Specify a Connection Handler's Listening Port
To Specify a Connection Handler's Authorization Policy
To Specify a Nickname for a Connection Handler's Certificate
To Specify a Connection Handler's Key Manager Provider
To Specify a Connection Handler's Trust Manager Provider
To Enable SSL-Based Communication
Enabling SSL in the JMX Connection Handler
SASL Options for the ANONYMOUS Mechanism
SASL Options for the CRAM-MD5 Mechanism
SASL Options for the DIGEST-MD5 Mechanism
SASL Options for the EXTERNAL Mechanism
SASL Options for the GSSAPI Mechanism
SASL Options for the PLAIN Mechanism
Configuring SASL Authentication
Configuring SASL External Authentication
Configuring the LDAP Connection Handler to Allow SASL EXTERNAL Authentication
Configuring the EXTERNAL SASL Mechanism Handler
To Configure Kerberos V5 on a Host
To Specify SASL Options for Kerberos Authentication
Example Configuration of Kerberos Authentication Using GSSAPI With SASL
All Machines: Edit the Kerberos Client Configuration File
All Machines: Edit the Administration Server ACL Configuration File
KDC Machine: Edit the KDC Server Configuration File
KDC Machine: Create the KDC Database
KDC Machine: Create an Administration Principal and Keytab
KDC Machine: Start the Kerberos Daemons
KDC Machine: Add Host Principals for the KDC and Oracle Unified Directory Machines
KDC Machine: Add an LDAP Principal for the Directory Server
KDC Machine: Add a Test User to the KDC
Directory Server Machine: Install the Directory Server
Directory Server Machine: Create and Configure the Directory Server LDAP
Directory Server Machine: Configure the Directory Server to Enable GSSAPI
Directory Server Machine: Add a Test User to the Directory Server
Directory Server Machine: Obtain a Kerberos Ticket as the Test User
Client Machine: Authenticate to the Directory Server Through GSSAPI
Troubleshooting Kerberos Configuration
Testing SSL, StartTLS, and SASL Authentication With ldapsearch
ldapsearch Command Line Arguments Applicable To Security
Testing SASL External Authentication
Controlling Connection Access Using Allowed and Denied Rules
Property Syntax of Allowed and Denied Client Rules
Configuring Allowed and Denied Client Rules
5. Configuring Security Between the Proxy and the Data Source
6. Managing Oracle Unified Directory With Oracle Directory Services Manager
10. Managing Users and Groups With dsconfig
11. Managing Password Policies
This section describes the requirements for configuring directory server to use the various SASL authentication mechanisms.
Note - SASL is not supported for use with Oracle Unified Directory proxy.
The SASL EXTERNAL mechanism is used to allow a client to authenticate itself to the directory server using information provided outside of what is strictly considered LDAP communication. The directory server currently supports authentication using a client certificate presented to the server during SSL or StartTLS negotiation, for LDAP communication only.
For the directory server to be able to map the client certificate to a user entry, ensure that the connection handler is configured to handle client certificates. Use the dsconfig to set the following LDAP connection handler properties:
ssl-client-auth-policy. Specifies whether the directory server prompts the client to present its own certificate during the SSL or StartTLS negotiation process. To support SASL EXTERNAL authentication, the value must be either optional or required. If the value is disabled, clients are not prompted to provide a certificate and no certificate is available for authentication.
trust-manager-provider. Specifies the DN of the trust manager provider used to determine whether the directory server trusts the validity of the client certificate. If the directory server does not trust the client certificate, the SSL or StartTLS negotiation fails and it is not possible for the client to request SASL EXTERNAL authentication. If the directory server trusts illegitimate client certificates, it is possible for malicious users to forge certificates and impersonate any user in the directory. In most cases, the JKS or PKCS12 trust manager provider should be used and the corresponding trust store loaded only with the issuer certificates that are used to sign client certificates.
Note - The dsconfig command accesses the server configuration over SSL via the administration connector. As such, the relevant connection options must be specified, including how the SSL certificate is trusted. These examples use the -X option to trust all certificates.
The following example uses dsconfig to set LDAP connection handler properties:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager"-w password -X -n \ set-connection-handler-prop --handler-name "LDAP Connection Handler"
SASL EXTERNAL bind requests are processed by the SASL mechanism handler. Use the dsconfig command to set the following SASL mechanism handler properties:
java-class. Specifies the fully-qualified name of the Java class that provides the logic for the SASL mechanism handler. For the EXTERNAL mechanism, this value is always org.opends.server.extensions.ExternalSASLMechanismHandler. An advanced property.
enabled. Indicates whether the EXTERNAL SASL mechanism is enabled for use in the directory server. If you do not want to allow clients to use SASL EXTERNAL authentication, change its value to false.
certificate-mapper. Specifies the DN of the configuration entry for the certificate mapper to be used to map client certificates to user entries.
certificate-validation-policy. Specifies whether the directory server attempts to locate the client certificate in the user's entry after establishing a mapping. If the value is always, the authentication succeeds only if the mapped user's entry contains the certificate presented by the client. If the value is ifpresent (the default value) and the user's entry contains one or more certificates, the authentication succeeds only if one of those certificates matches the one presented by the client. If the value is ifpresent and the user's entry does not contain any certificates, the authentication still succeeds based on the fact that it would have been accepted by the trust manager and mapped by the certificate mapper. If the value is never, the server does not attempt to match the certificate to a value in the user's entry even if that entry contains one or more certificates.
certificate-attribute. Specifies the name of the attribute that holds user certificates to be examined if the certificate-validation-policy property has a value of either always or ifpresent.
The following example uses dsconfig to set EXTERNAL SASL mechanism handler properties:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager"-w password -X -n \ set-sasl-mechanism-handler-prop --handler-name "EXTERNAL" --advanced
This section explains the access control and privilege restrictions on a user using the authorization ID keyword (authzid). If the user is not using the authzid keyword, these restrictions do not apply. Any user that binds using DIGEST-MD5 and the authzid keyword must fulfill the following requirements:
The authentication ID (authid) must be granted access by an ACI that grants it the proxy right to the authorization ID.
The authentication ID (authid) entry must contain the proxied-auth privilege. The following example creates a test environment and demonstrates the requirements for user authentication using the DIGEST-MD5 SASL mechanism.
The following example creates a test environment and then demonstrates the requirements for a user authentication using the DIGEST-MD5 SASL mechanism.
Import the following entries into the directory. These entries define an ACI and three users:
The entry uid=user.0,ou=People,dc=example,dc=com does not have the proxied-auth privilege but is granted proxy access by the ACI.
The entry uid=user.1,ou=People,dc=example,dc=com has the proxied-auth privilege but is not granted proxy access by the ACI.
The entry uid=user.2,ou=People,dc=example,dc=com has the proxied-auth privilege and is granted proxy access by the ACI.
dn: ou=People,dc=example,dc=com objectClass: top objectClass: organizationalunit objectClass: posixGroup ou: People aci: (target="ldap:///uid=proxy user,ou=People,dc=example,dc=com") \ (targetattr="*") (version 3.0; acl "allow SASL Example"; \ allow (proxy) userdn="ldap:///uid=user.0,ou=People,dc=example,dc=com || ldap:///uid=user.2,ou=People,dc=example,dc=com";) dn: uid=user.0,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson ... description: This is the description for user.0 dn: uid=user.1,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson ... description: This is the description for user.1 ds-privilege-name: proxied-auth dn: uid=proxy user,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson ... description: This is the description for proxy user dn: uid=user.2,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson ... description: This is the description for user.2 ds-privilege-name: proxied-auth
Bind using DIGEST-MD5 as uid=user.1,ou=People,dc=example,dc=com:
$ ldapsearch --port 1389 -w password --saslOption mech=DIGEST-MD5 \ --saslOption authid=dn:uid=user.1,ou=People,dc=example,dc=com --saslOption \ authzid=dn:uid=proxy user,ou=People,dc=example,dc=com --baseDN "" \ --searchScope base "(objectClass=*)" The SASL DIGEST-MD5 bind attempt failed Result Code: 49 (Invalid Credentials)
The search fails because uid=user.1,ou=People,dc=example,dc=com is not granted the proxy right by the ACI.
Bind using DIGEST-MD5 as uid=user.0,ou=People,dc=example,dc=com:
$ ldapsearch --port 1389 -w password --saslOption mech=DIGEST-MD5 \ --saslOption authid=dn:uid=user.0,ou=People,dc=example,dc=com --saslOption \ authzid=dn:uid=proxy user,ou=People,dc=example,dc=com --baseDN "" \ --searchScope base "(objectClass=*)" The SASL DIGEST-MD5 bind attempt failed Result Code: 49 (Invalid Credentials)
The search fails because uid=user.0,ou=People,dc=example,dc=com does not have the proxied-authproperty.
Bind using DIGEST-MD5 as uid=user.2,ou=People,dc=example,dc=com authid with both access control access and the proxied-auth privilege:
$ ldapsearch --port 1389 -w password --saslOption mech=DIGEST-MD5 \ --saslOption authid=dn:uid=user.2,ou=People,dc=example,dc=com --saslOption \ authzid=dn:uid=proxy user,ou=People,dc=example,dc=com --baseDN "" \ --searchScope base "(objectClass=*)" dn: objectClass: ds-root-dse objectClass: top
The search succeeds because uid=user.2,ou=People,dc=example,dc=com has access allowed by the ACI and the proxied-auth privilege.
This section explains the access control and privilege restrictions on a user using the authorization ID keyword (authzid). If the user is not using the authzid keyword, the restrictions do not apply.
Any user that binds using GSSAPI must fulfill the following requirements:
The authentication ID (authid) must be granted access by an ACI that grants it the proxy right to the authorization ID.
The authentication ID (authid) entry must contain the proxied-auth privilege.
The following example creates a test environment with three example entries and demonstrates the requirements for user authentication using the GSSAPI SASL mechanism. These examples require a fully configured Kerberos environment, including a valid keytab file.
Create three Kerberos principals in the realm TESTLOCAL.NET:
user.0@TESTLOCAL.NET
user.1@TESTLOCAL.NET
user.2@TESTLOCAL.NET
Configure the GSSAPI SASL handler to be enabled, to use the regular expression identity mapper, and to use a valid TESTLOCAL.NET keytab file.
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -w password -X \ set-sasl-mechanism-handler-prop --handler-name "GSSAPI" \ --set enabled:true --set identity-mapper:"Regular Expression" \ --set keytab:keytabPath
The default value of the GSSAPI enabled property is false, so it must be set to true. The default value of identity-mapper is Regular Expression. The default value of the keytab property is /etc/krb5/krb5.keytab.
Import the following entries into the directory. These entries define an ACI and three users:
The entry uid=user.0,ou=People,dc=example,dc=com does not have the proxied-auth privilege but is granted proxy access by the ACI.
The entry uid=user.1,ou=People,dc=example,dc=com has the proxied-auth privilege but is not granted proxy access by the ACI.
The entry uid=user.2,ou=People,dc=example,dc=com has the proxied-auth privilege and is granted proxy access by the ACI.
dn: ou=People,dc=example,dc=com objectClass: top objectClass: organizationalunit objectClass: posixGroup ou: People aci: (target="ldap:///uid=proxy user,ou=People,dc=example,dc=com") \ (targetattr="*") (version 3.0; acl "allow SASL Example"; \ allow (proxy) userdn="ldap:///uid=user.0,ou=People,dc=example,dc=com" || "ldap:///uid=user.2,ou=People,dc=example,dc=com";) dn: uid=user.0,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson uid=user.0 ... description: This is the description for user.0 dn: uid=user.1,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson uid=user.1 ... description: This is the description for user.1 ds-privilege-name: proxied-auth dn: uid=user.2,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson uid=user.2 ... description: This is the description for user.2 ds-privilege-name: proxied-auth dn: uid=proxy user,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson uid=proxy user ... description: This is the description for proxy user
Run this command to demonstrate a failing GSSAPI SASL bind using the Kerberos principal, user.0@TESTLOCAL.NET:
$ ldapsearch --port 1389 \ --saslOption mech=GSSAPI \ --saslOption authid=user.1@TESTLOCAL.NET \ --saslOption authzid=dn:uid=proxy user,ou=People,dc=example,dc=com \ --baseDN "" --searchScope base "(objectClass=*)" The SASL DIGEST-MD5 bind attempt failed Result Code: 49 (Invalid Credentials)
This search fails because user.0@TESTLOCAL.NET maps to uid=user.0,ou=People,dc=example,dc=com, which has the proxied-auth privilege but does not have access control permissions to uid=proxy user,ou=People,dc=example,dc=com.
Run this command to demonstrate a failing GSSAPI SASL bind using the Kerberos principal, user.1@TESTLOCAL.NET.
$ ldapsearch --port 1389 \ --saslOption mech=GSSAPI \ --saslOption authid=user.2@TESTLOCAL.NET \ --saslOption authzid=dn:uid=proxy user,ou=People,dc=example,dc=com \ --baseDN "" --searchScope base "(objectClass=*)" The SASL DIGEST-MD5 bind attempt failed Result Code: 49 (Invalid Credentials)
This search fails because user.1@TESTLOCAL.NET maps to uid=user.1,ou=People,dc=example,dc=com, which has access control permissions to uid=proxy user,ou=People,dc=example,dc=com but does not have the proxied-auth privilege.
Run this command to demonstrate a successful GSSAPI SASL bind using the Kerberos principal user.2@TESTLOCAL.NET:
$ ldapsearch --port 1389 \ --saslOption mech=GSSAPI \ --saslOption authid=user.0@TESTLOCAL.NET \ --saslOption authzid=dn:uid=proxy user,ou=People,dc=example,dc=com \ --baseDN "" --searchScope base "(objectClass=*)" dn: objectClass: ds-root-dse objectClass: top }}} \\ \\
This search succeeds because user.2@TESTLOCAL.NET maps to uid=user.2,ou=People,dc=example,dc=com, which has both the proxied-auth privilege and access control permission to id=proxy user,ou=People,dc=example,dc=com.