Setting up Kerberos authentication

The following procedure describes how to configure and use Kerberos authentication with SQL Anywhere.

To set up Kerberos authentication for a SQL Anywhere database

  1. Install and configure the Kerberos client software, including the GSS-API runtime library, on both the client and server computers. (If you already use Kerberos, then this should already be done).

    On Windows client computers using an Active Directory KDC, SSPI can be used and no Kerberos client needs to be installed. See Using SSPI for Kerberos logins on Windows.

  2. If necessary, create a Kerberos principal in the Kerberos Key Distribution Center (KDC) for each user.

    A Kerberos principal is a Kerberos user ID in the format user/instance@REALM, where /instance is optional. If you are already using Kerberos, the principal should already exist, so you will not need to create a Kerberos principal for each user.

    Principals are case sensitive and must be specified in the correct case. Mappings for multiple principals that differ only in case are not supported (for example, you cannot have mappings for both jjordan@MYREALM.COM and JJordan@MYREALM.COM).

  3. Create a Kerberos principal in the KDC for the SQL Anywhere database server.

    The Kerberos principal for the database server has the format server-name@REALM, where server-name is the SQL Anywhere database server name. Principals are case significant, and the server-name cannot contain multibyte characters, or the characters /, \, or @. The rest of the steps assume the Kerberos principal is my_server_princ@MYREALM.COM.

    Servers, like users, must authenticate themselves to the KDC. This is why you must create a server service principal within the KDC. Servers authenticate themselves through the use of a keytab file. The keytab file is a protected, encrypted file that the server uses to identify itself to the KDC.

  4. Securely extract and copy the keytab for the principal server-name@REALM from the KDC to the computer running the SQL Anywhere database server. The default location of the keytab file depends on the Kerberos client and the platform. The keytab file's permissions should be set so that the SQL Anywhere server can read it, but unauthorized users do not have read permission.

Once you have installed and configured Kerberos, you must enable Kerberos logins for your SQL Anywhere database. The login_mode database option determines whether Kerberos logins are allowed. As database options apply only to the database in which they are found, different databases can have a different Kerberos login setting, even if they are loaded and running on the same server.

The login_mode database option accepts one or more of the following values:

  • Standard   Standard logins are permitted. This value is the default. Standard connection logins must supply both a user ID and password, and do not use the Integrated or Kerberos connection parameters.

  • Integrated   Integrated logins are permitted.

  • Kerberos   Kerberos logins are permitted.

Caution

Setting the login_mode database option to Kerberos restricts connections to only those users who have been granted a Kerberos login mapping. Attempting to connect using a user ID and password generates an error unless you are a user with DBA authority.

The following steps assume you already performed the steps in the previous procedure to set up Kerberos.

To configure SQL Anywhere to use Kerberos

  1. Start the SQL Anywhere server with the -krb or -kr option to enable Kerberos authentication (alternatively, the -kl option can be used to specify the location of the GSS-API library and enable Kerberos).

    See:

    The following command starts the database server for the Kerberos principal my_server_princ@MYREALM.COM.

    dbsrv11 -krb -n my_server_princ C:\kerberos.db
  2. Change the public or temporary public option login_mode to a value that includes Kerberos. You must have DBA authority to change the setting of this option. See login_mode option [database].

    SET OPTION PUBLIC.login_mode = 'Kerberos,Standard';
  3. Create a database user ID for the client. You can use an existing database user ID for the Kerberos login, as long as that user has the correct permissions.

    CREATE USER "kerberos-user"
    IDENTIFIED BY abc123;
  4. Create a mapping from the client's Kerberos principal to an existing database user ID by executing a GRANT KERBEROS LOGIN TO statement. This statement requires DBA authority. See GRANT statement and Creating Kerberos login mappings.

    For example:

    GRANT KERBEROS LOGIN TO "pchin@MYREALM.COM" 
    AS USER "kerberos-user";

    If you want to connect when a Kerberos principal is used that does not have a mapping, ensure the Guest database user ID exists and has a password. See Creating a default integrated login user.

  5. Ensure the client user has already logged on (has a valid Kerberos ticket-granting ticket) using their Kerberos principal and that the client's Kerberos ticket has not expired. A Windows user logged in to a domain account already has a ticket-granting ticket, which allows them to authenticate to servers, providing their principal has sufficient permissions.

    A ticket-granting ticket is a Kerberos ticket encrypted with the user's password that is used by the Ticket Granting Service to verify the user's identity.

  6. Connect from the client, specifying the KERBEROS connection parameter (KERBEROS=YES in many cases, but KERBEROS=SSPI or KERBEROS=GSS-API-library-file can also be used). If the user ID or password connection parameters are specified, they are ignored. For example:

    dbisql -c "KERBEROS=YES;ENG=my_server_princ"
Interactive SQL example

For example, a connection attempt using the following Interactive SQL statement is successful if the user logs in with a user profile name that matches a Kerberos login mapping in a default database of a server:

CONNECT USING 'KERBEROS=YES';

The Interactive SQL statement CONNECT can connect to a database if all the following are true:

  • A server is currently running.
  • The default database on the current server is enabled to accept Kerberos authenticated connections.
  • A Kerberos login mapping has been created for the user's current Kerberos principal.
  • If the user is prompted with a window by the server for more connection information (such as occurs when using Interactive SQL), the user clicks OK without providing more information.
Open Client and jConnect connections

To connect from an Open Client or jConnect application, follow the previous steps (in the procedure To configure SQL Anywhere to use Kerberos), and set up Open Client/jConnect as you would for Kerberos authentication with Adaptive Server Enterprise. The server name must be the SQL Anywhere server's name and is case significant. Note you cannot connect using an alternate server name from Open Client or jConnect.

For information about setting up the Kerberos principals and extracting the keytab, see [external link] http://www.sybase.com/detail?id=1029260.

See also