Use this statement to add users to the database.
You must have the system privilege CREATE USER.
- For the user to be able to log in subsequently, the system privilege CREATE SESSION must be granted.
- For the user name, the same rules as for SQL identifiers apply. However, even with identifiers in quotation marks, no attention is paid to case sensitivity. This means that the usernames "Test", "TEST", and "test" are synonymous. For more information, refer to the SQL Identifier section.
Furthermore, different from other SQL identifiers, the dot symbol is allowed in usernames.
- For authentication, you can use passwords, Kerberos,
- A user created will not be automatically associated with a schema.
- A user can be altered by the ALTER USER command and renamed by using the RENAME command.
- For information about the database users, refer to the system tables EXA_DBA_USERS, EXA_ALL_USERS, and EXA_USER_USERS.
- For details about password security (complexity, expiry, locking accounts, refer to the Database Users and Roles and Privileges sections.
If you want to authenticate the database user with a password, create a user authenticated by a password. The database checks the user's password when they log in. The password has to be specified as identifier. If you use delimited (quoted) identifiers, then the password is case sensitive. For more information, refer to the SQL Identifier section.
In case of a regular identifier (unquoted) the password will be set to uppercase letters and has to be adjusted for the login.
If you want to enable single sign on with Kerberos, create a user authenticated by Kerberos. The JDBC and ODBC drivers will then authenticate the user by Kerberos service (single sign-on). The defined principal looks like <user>@<realm>.
For additional information about the overall Kerberos configuration, refer to the Kerberos Single Sign-On section.
If you want to authenticate the database user with LDAP Lightweight Directory Access Protocol (authentication service), create a user authenticated by LDAP. The database checks the password against an LDAP server which can be configured per database within EXAoperation. The parameter dn-string (string in single quotes) specifies the so-called distinguished name which is the username configured in an LDAP server. The SASL Simple Authentication and Security Layer and certification management are not supported.
Make sure that your LDAP server is already set up for authenticating the database users.
- Log in to EXAoperation.
- Shut down the database.
- Edit the database and add the LDAP Server URLs starting with either ldap:// or ldaps://.
For more information about how to edit a database, see Edit a Database.
- Click Apply to save the changes.
- Start the database.
- Log in to your database using an SQL client.
- Run the following statement to create a user with LDAP authentication.
You can find the required information for the above statement from the following methods depending on your operating system:
Windows OS: You can use one of the following commands to find the information from your LDAP server:
a) Get-ADUser: Use the command through Powershell. To use this method, you need Remote Server Administration Tools installed and the feature Active Directory-Module for Windows PowerShell at your system. Example:
b) dsquery: Use the command through cmd with admin privilege. To use this method, you need Remote Server Administration Tools installed on your system. Example:
Linux OS: You can use the LDAPSEARCH command to find the information from your LDAP server. Examples:
For more information, see Linux man page for LDAPSEARCH.
Further Information on LDAP in Exasol
If you want to know more about LDAP authentication in Exasol, see the following Exasol Knowledge Base articles:
Exasol allows you to authenticate database users by OpenID. OpenID verifies clients' identities using authentication done by an Authorization Server. With this method, Exasol acts as a resource server and authenticates database connections opened by Exasol ODBC, JDBC, ADO.NET, or WebSockets clients using OpenID/OAuth access token or refresh token. The implementation follows OpenID Connect Core 1.0, Internet standards RFC 6749, RFC 7517, and RFC 7519.
To configure OpenID authentication of database users, you must add the below parameters for either Access token or Refresh Token authentication. For more information, see Edit a Database.
The following table contains configuration parameters used to enable Access Token based authentication:
|-oidcProviderJKU||OpenID provider endpoint to retrieve the JSON Web Key Set (JWKS) used for signing JWS tokens (mandatory).|
|-oidcProviderAUD||Verifies the audience in an OpenID Access Token (optional/recommended).|
|-oidcProviderISS||Verifies the issuer in an OpenID Access Token (optional/recommended).|
The following table contains configuration parameters used to enable Refresh Token based authentication:
|-oidcProviderTokenEndpoint||OpenID provider endpoint to retrieve OAuth 2.0 and OpenID Connect tokens (mandatory).|
|-oidcProviderClientId||OpenID Client ID registered with OpenID provider (mandatory).|
Client Secret of the OpenID Client registered with the OpenID provider (mandatory).
If Proof Key for Code Exchange (PKCE) is enabled, it is not set.
|-oidcRefreshTokenGrantScope||OpenID scopes to be requested during Refresh Token Exchange (optional).
This parameter is required for integrations with Azure AD, which requires that you provide at least one application-specific scope with offline_access. Separate multiple application-specific scopes with a white space. To configure the scope in Azure, see Quickstart: Configure an application to expose a web API - Add a scope.
Cache capacity of the Refresh Token based authentication information (optional).
Interval (in seconds) for Exasol to perform maintenance procedures for a Refresh Token based authentication information cache (optional).
Default: 3600 seconds (1 hour)
The following table lists optional additional configuration parameters for OpenID authentication:
Interval (in seconds) for Exasol to fetch new signing keys from OpenID Provider JWKS.
Default: 86400 seconds (24 hours)
The Proxy URL to be used for connections in a Refresh Token OpenID Provider endpoints. Supported protocols:
After the parameters are set up, run the following statement to create a new user or modify an existing user with OpenID authentication.
CREATE USER oidctestuser IDENTIFIED BY OPENID SUBJECT 'email@example.com';
GRANT CREATE SESSION TO oidctestuser;