Authentication

Authentication protects the identity of the user so that user credentials cannot be intercepted by malicious hackers when transmitted over the network. See Authentication for an overview.

The Oracle data provider supports the following methods of authentication:

• User ID/password authentication authenticates the user to the database using a database user name and password specified by the application.

• Kerberos authentication uses Kerberos, a trusted third-party authentication service, to verify user identities. Kerberos authentication can take advantage of the user name and password maintained by the operating system to authenticate users to the database or use another set of user credentials specified by the application.

  This method requires knowledge of how to configure your Kerberos environment and supports Windows Active Directory Kerberos, MIT Kerberos, and the Kerberos.NET library.

• Client authentication uses the user ID of the user logged onto the system on which the data provider is running to authenticate the user to the database. The Oracle database server relies on the client to authenticate the user and does not provide additional authentication.

  Note: Because the database server does not authenticate the user when client authentication is used, use this method of authentication if you can guarantee that only trusted clients can access the database server.

Except for NTLM authentication, which provides authentication for Windows clients only, these authentication methods provide authentication when the data provider is running on any supported platform.

Using the Authentication Method Connection String Option

The Authentication Method connection string option controls which authentication mechanism the data provider uses when establishing connections. When Authentication Method=UserIDPassword (the initial default), the data provider uses the Oracle user ID/password authentication when establishing a connection based on the following criteria:

• If a user ID and password is specified, the data provider uses user ID/password authentication when establishing a connection. The User connection string option provides the user ID. The Password connection string option provides the password.
• If a user ID and password is not specified and the data provider is not running on a Windows platform, the data provider uses Kerberos authentication when establishing a connection.

When Authentication Method=Kerberos, the data provider uses Kerberos authentication when establishing a connection. The data provider ignores any values specified by the User and Password properties.

When Authentication Method=KerberosUserIDPassword, the data provider first uses Kerberos when establishing a connection. Next, the data provider reauthenticates the user using user ID/password authentication. The User ID connection string option provides the user ID. The Password connection string option provides the password. If a user ID and password are not specified, the data provider throws an exception. If either Kerberos or user ID/password authentication fails, the connection attempt fails and the data provider throws an exception.

When Authentication Method=NTLM, the data provider uses NTLM authentication when establishing a connection if the data provider can load the DLL required for NTLM authentication. If the data provider cannot load the DLL, the data provider throws an exception. The data provider ignores any values specified by the User ID and Password properties.

When Authentication Method=Client, the data provider uses client authentication when establishing a connection. The Oracle database server relies on the client to authenticate the user and does not provide additional authentication. The data provider ignores any values specified by the User ID and Password connection string options.

When Authentication Method=UserIdPassword, the data provider uses user ID/password authentication when establishing a connection. The User connection string option supplies the user ID. The Password connection string option supplies the password. If a user ID is not specified, the data provider throws an exception.

Note: If any of these values are set, the data provider also can use data encryption by setting the Encryption Method connection string option.

Configuring User ID/Password Authentication

1. Set the Authentication Method connection string option to UserIdPassword. See Using the Authentication Method Connection String Option for more information about setting a value for this connection string option.
2. Set the User ID connection string option to provide the user ID.
3. Set the Password connection string option to provide the password.

Configuring Kerberos Authentication

Verify that your environment meets the requirements listed in the following below before you configure the data provider for Kerberos authentication.

Kerberos Authentication Requirements for the Oracle Data Provider

Specifying User Credentials for Kerberos Authentication (Delegation of Credentials)

By default, when Kerberos authentication is used, the Oracle data provider takes advantage of the user name and password maintained by the operating system to authenticate users to the database. By allowing the database to share the user name and password used for the operating system, users with a valid operating system account can log into the database without supplying a user name and password.

Many application servers or Web servers act on behalf of the client user logged on the machine on which the application is running, rather than the server user. If you want the data provider to use a set of user credentials other than the operating system user name and password, you must include code in your application to define the credentials.

Obtaining a Kerberos Ticket Granting Ticket

To use Kerberos authentication, the application user first must obtain a Kerberos Ticket Granting Ticket (TGT) from the Kerberos server. The Kerberos server verifies the identity of the user and controls access to services using the credentials contained in the TGT. To obtain a TGT explicitly, the user must log on to the Kerberos server using the kinit command. For example, the following command requests a TGT from the server with a lifetime of 10 hours, renewable for up to 5 days:

kinit -l 10h -r 5d user

where user is the application user name.

If the application uses Kerberos authentication from a Windows client and the Kerberos authentication is provided by Windows Active Directory Kerberos or the Kerberos.NET library using the Credentials Cache=MSLSA: option, the application user is not required to log onto the Kerberos server and explicitly obtain a TGT. The driver automatically obtains a TGT for the user.

The application user must explicitly obtain a TGT in the following cases:

• If the application uses Kerberos authentication from a UNIX or Linux client
• If the application uses Kerberos authentication from a Windows client and Kerberos authentication is provided by MIT Kerberos
• If the application uses Kerberos authentication from a Windows client and authentication is provided by the Kerberos.NET library using a file-based cache. Use the Credentials Cache option to specify the absolute path to the file-based cache.

Configuring Kerberos Authentication

Kerberos authentication employs Kerberos, a trusted third-party authentication service, to verify user identities. It can utilize the credentials maintained by the operating system to authenticate users to the database, or it can use an alternative set of credentials supplied by the application. Configuring Kerberos authentication requires familiarity with your Kerberos environment.

The Oracle data provider supports the following three Kerberos authentication methods:

• Windows Active Directory Kerberos
• MIT Kerberos
• Kerberos.NET based authentication

Each method is suited to a different deployment scenario. The following sections describe each method, specify when it should be used, and provide connection string examples.

Windows Active Directory Kerberos

Windows Active Directory Kerberos is the default Kerberos authentication method used by the driver when no GSSClient path is specified and the Use Kerberos DotNet option is set to false. The driver accesses Kerberos through the Windows Security Support Provider Interface (SSPI), which delegates authentication to the domain controller using the credentials of the currently logged-in Windows user. This method is available on Windows only and requires no additional libraries or configuration files.

Follow these steps to configure Kerberos authentication using Windows Active Directory.

1. Verify that the client machine is running Windows and joined to an Active Directory domain.
2. Log in to Windows using the Active Directory account that will be used for database authentication.
3. Ensure that no GSS client library or GSSClient path is configured so the driver defaults to SSPI.
4. Set AuthenticationMethod=KERBEROS in the connection string. For Example:

   Host=db-server.example.com;
   Port=1521;
   SID=ORCL;
   AuthenticationMethod=KERBEROS;
   

5. Connect to the database and allow the driver to authenticate using the logged-in user’s Kerberos credentials via SSPI.

Notes:

• When Oracle Advanced Security (OAS) is enabled on the database server, this method cannot be used. Oracle requires access to the Kerberos session key, which SSPI does not expose after ticket issuance. This limitation is inherent to SSPI and cannot be resolved through configuration.
• In environments where OAS is enabled, use MIT Kerberos or Kerberos.NET–based authentication instead.

MIT Kerberos

MIT Kerberos is an alternative Kerberos authentication method that uses a native GSS‑API library and a file‑based credentials cache. It is not included with Progress DataDirect products and must be installed separately on the client system. Install MIT Kerberos for Windows on Windows clients or the platform MIT Kerberos distribution, such as krb5 on Linux clients, then specify the full path to the GSS‑API shared library using the GSSClient connection option.

Follow these steps to configure Kerberos authentication using MIT Kerberos.

1. Install the appropriate MIT Kerberos distribution on the client machine. For example, MIT Kerberos for Windows on Windows, or the platform Kerberos package such as krb5 on Linux.

2. Verify that a native GSS-API shared library is installed as part of the MIT Kerberos distribution.

3. Ensure that a valid Kerberos credentials cache exists and is accessible from the default location or the path specified by the KRB5CCNAME environment variable.

4. Confirm that DDTek.OracleHelper.dll is present on the client system as part of the Oracle ADO.NET provider installation.

5. Specify the full path to the MIT Kerberos GSS-API library using the GSSClient connection option.

6. Set AuthenticationMethod=KERBEROS in the connection string.

7. Connect to the database and allow the driver to load DDTek.OracleHelper.dll, which in turn loads the specified GSS-API library and acquires the Kerberos service ticket and session key if Oracle Advanced Security is enabled. For Example:

   Host=db-server.example.com;
   Port=1521;
   SID=ORCL;
   AuthenticationMethod=KERBEROS;
   GSSClient=C:\Program Files\MIT\Kerberos\bin\gssapi64.dll;
   

Kerberos.NET-Based Authentication

Kerberos.NET‑based authentication provides a fully managed, .NET‑native Kerberos implementation that overcomes limitations of both SSPI‑based Active Directory Kerberos and MIT Kerberos. It supports retrieval of the Kerberos session key required by Oracle Advanced Security (OAS) while avoiding dependencies on external native GSS libraries.

This method uses DDTek.KerberosHelper.dll, which is included with the Progress DataDirect Oracle ADO.NET provider, and integrates at runtime with the open‑source Kerberos.NET library supplied by the customer. Use Kerberos.NET‑based authentication when Oracle Advanced Security (OAS) is enabled, when external native GSS libraries are restricted, or when a fully managed Kerberos implementation is preferred on Windows or Linux. On Windows, it supports seamless single sign‑on using the Local Security Authority (LSA) cache without requiring a separate kinit step. On Linux, it supports file‑based credential caches populated using kinit.

Follow these steps to configure Kerberos authentication using Kerberos.NET‑based authentication.

1. Obtain Kerberos.NET and all required dependency assemblies and place them in the application’s probing path.

2. Provide DDTek.KerberosHelper.dll in the application’s probing path. It is available as part of the Oracle data provider installation.

3. Ensure that a valid Kerberos configuration file is available and note its fully qualified local file path.

4. Generate Kerberos credentials using kinit cmd as mentioned in 'Obtaining a Kerberos Ticket Granting Ticket' section in case using file‑based credentials cache. Skip this step for Windows LSA cache.

5. Set AuthenticationMethod=KERBEROS and UseKerberosDotNet=TRUE in the connection string.

6. Specify the Kerberos configuration file using the KerberosConfigPath connection option.

7. Specify the Kerberos credentials using the CredentialsCache connection option.

8. Connect to the database and allow the driver to dynamically load DDTek.KerberosHelper.dll, which in turn loads Kerberos.NET and performs Kerberos authentication.

   Notes

   • DDTek.KerberosHelper.dll is shipped with the Oracle data provider. Kerberos.NET and its dependencies are not included and must be obtained separately (for example, via NuGet) and placed in the application’s probing path so they can be located at runtime.
   • The exact dependency assemblies and versions required are listed in net40\DEPENDENCIES_DDTek.KerberosHelper.md within the product installation directory. Always use the DEPENDENCIES file that corresponds to the specific version you are deploying, and do not mix dependency versions across releases.
   • If your application already uses different versions of Kerberos.NET assemblies, add binding redirects in app.config or web.config to resolve conflicts. For MSBuild projects, you can enable automatic binding redirects by setting AutoGenerateBindingRedirects to true in the project file.

The following example is a connection string with the required properties for making a connection with Kerberos authentication using file‑based credentials cache.

Host=db-server.example.com;
Port=1521;
SID=ORCL;
AuthenticationMethod=KERBEROS;
UseKerberosDotNet=TRUE;
KerberosConfigPath=C:\KerberosConfig\krb5.ini;
CredentialsCache=C:\KerberosCache\krb5cache;

The following is an example connection URL with the required properties for making a connection with Kerberos authentication using Windows LSA (MSLSA) credentials cache.

Host=db-server.example.com;
Port=1521;
SID=ORCL;
AuthenticationMethod=KERBEROS;
UseKerberosDotNet=TRUE;
KerberosConfigPath=C:\KerberosConfig\krb5.ini;
CredentialsCache=MSLSA:;

Configuring Client Authentication

Set the Authentication Method connection string option to Client. See Using the Authentication Method Connection String Option for more information about setting a value for this property.

Configuring NTLM Authentication

This section provides requirements and instructions for configuring NTLM authentication for the Microsoft SQL Server data provider.

Product Requirements

Verify that your environment meets the requirements listed in the following table before you configure your environment for NTLM authentication.

NTLM Authentication Requirements for the SQL Server Data Provider

Configuring the Data Provider

To configure the data provider, set the Authentication Method connection string option to NTLM. See Using the Authentication Method Connection String Option for more information about setting a value for this connection string option.