Troubleshooting Kerberos connections

If you get unexpected errors when attempting to enable or use Kerberos authentication, it is recommended that you enable additional diagnostic messages on the database server and client.

Specifying the -z option when you start the database server, or using CALL sa_server_option( 'DebuggingInformation', 'ON' ) if the server is already running includes additional diagnostic messages in the database server message log. The LogFile connection parameter writes client diagnostic messages to the specified file. See -z dbeng12/dbsrv12 server option.

As an alternative to using the LogFile connection parameter, you can run the Ping utility (dbping) with the -z parameter. The -z parameter displays diagnostic messages that should help identify the cause of the connection problem. See Ping utility (dbping).

Difficulties starting the database server

Symptom	Common solutions
"Unable to load Kerberos GSS-API library" message	Ensure a Kerberos client is installed on the database server computer, including the GSS-API library. The database server -z output lists the name of the library that it is attempting to load. Verify the library name is correct. If necessary, use the -kl option to specify the correct library name. Ensure the directory and any supporting libraries is listed in the library path (%PATH% on Windows). If the database server -z output states the GSS-API library was missing entry points, then the library is not a supported Kerberos Version 5 GSS-API library.
"Unable to acquire Kerberos credentials for server name "server-name"" message	Ensure there is a principal for server-name@REALM in the KDC. Principals are case sensitive, so ensure the database server name is in the same case as the user portion of the principal name. Ensure the name of the SQL Anywhere server is the primary/user portion of the principal. Ensure that the server's principal has been extracted to a keytab file and the keytab file is in the correct location for the Kerberos client. See Kerberos clients. If the default realm for the Kerberos client on the database server computer is different from the realm in the server principal, use the -kr option to specify the realm in the server principal.
"Kerberos login failed" client error	Check the database server diagnostic messages. Some problems with the keytab file used by the server are not detected until a client attempts to authenticate.

Troubleshooting Kerberos client connections

If the client got an error attempting to connect using Kerberos authentication:

Symptom	Common solutions
"Kerberos logins are not supported" error and the LogFile includes the message "Failed to load the Kerberos GSS-API library"	Ensure a Kerberos client is installed on the client computer, including the GSS-API library. The file specified by LogFile lists the name of the library that it is attempting to load. Verify that the library name is correct, and use the Kerberos connection parameter to specify the correct library name, if necessary. Ensure that the directory including any supporting libraries is listed in the library path (%PATH% on Windows). If the LogFile output states the GSS-API library was missing entry points, then the library is not a supported Kerberos Version 5 GSS-API library.
"Kerberos logins are not supported" error	Ensure the database server has enabled Kerberos logins by specifying one or more of the -krb, -kl, or -kr server options. Ensure Kerberos logins are supported by SQL Anywhere on both the client and server platforms. See Kerberos clients.
"Kerberos login failed" error	Ensure the user is logged into Kerberos and has a valid ticket-granting ticket that has not expired. Ensure the client computer and server computer both have their time synchronized to within less than 5 minutes.
"Login mode 'Kerberos' not permitted by login_mode setting" error	The public or temporary public database option setting for the login_mode option must include the value Kerberos to allow Kerberos logins. See login_mode option.
"The login ID 'client-Kerberos-principal' has not been mapped to any database user ID"	The Kerberos principal must be mapped to a database user ID using the GRANT KERBEROS LOGIN statement. Note the full client principal including the realm must be provided to the GRANT KERBEROS LOGIN statement, and principals which differ only in the instance or realm are treated as different. Alternatively, if you want any valid Kerberos principal which has not be explicitly mapped to be able to connect, create the guest database user ID with a password using GRANT CONNECT.

Discuss this page in DocCommentXchange.