Authentication violation in SQL Anywhere 17

[#1]

I am using a sql anywhere 17 database with database_authentication in sysoptions, my applications use valid connection_authentication strings and sometimes (while using a new application or migrating the database) I get the authentication violation error (SQLCode=-98), so that I want to ask whether my understandings are correct:
- The only 2 factors which decide the violation is (the "database_authentication" in the table SYSOPTIONS should match with the "connection_authentication" being used in the application.

- All native applications (dbisql, dbremote, scjview...) are of the violation excempted, so I never get the violation error while using these applications.

- An empty "database_authentication" in the table SYSOPTIONS means that any other application can connect to the database without the need for a correct "connection_authentication".

- In order to be able to unload a database I should copy the string "database_authentication" in a script file under the sybase installation folder, but is this really a protecting mechanism? What is the goal of this script having that any user in the database has select permission on the table SYSOPTIONS and so can create the file himself and unload/load the database.

[chris_keating]

The Authenticated Edition requires that both the DATABASE_AUTHENTICATION option to be set at the time the database is started and each connection to set the CONNECTION_AUTHENTICATION option prior to write operations. As long as the options are correct, you will also have a 30sec grace period where read-write operations are permitted.  

As noted, all SQL Anywhere tooling is self-authenticating.  

A database running on an Authenticated Engine must have the DATABASE_AUTHENTICATION set with a valid value when started. Otherwise, connections will always fail with -98 Authentication Violation with any write operation. This will also be true for  SQL Anywhere tooling. 

The purpose of Authentication is not security. It provides a reduced licensing cost option for applications that use SQL Anywhere.  I believe there is a requirement to advise the end-customer of the application that they are only permitted to use the SQL Anywhere software included with that application (except for the purpose of read access for reporting use cases).

If the application permits the creation (or rebuilding) of databases, the DATABASE_AUTHENTICATION must be provided in the authenticate.sql file in the deployment as that is the only mechanism to set that option on an Authenticated engine.  The OEM application, if concerned about their end users using the SQL Anywhere embedded with their application for other purposes via that mechanism, could opt to not deploy the command line dbinit, for example, and opt to implement creating databases either in SQL (CREATE DATABASE...) or using DBTools API. They can then limit access to users with suitable privileges.   

[Baron]

Thanks for the reply, what means "Authenticated engine" does it mean an OEM Installation of sql anywhere?
According to my experiment the authentication violation can only happen on machines with OEM Installation and never happens on a machine which has the developer version of SQL Anywhere

[chris_keating]

There are several variations of OEM licensing so I like to be specific. Authenticated Edition is an OEM license that uses the Authentication options to enable read-write access from an OEM application. The Developer Edition does not use the Authentication signatures - you would need to be an Authenticated Edition licensed organization to request those signatures.

[Baron]

In my last experiment I used dbunload.exe to rebuild a productive database on an OEM (Authenticated engine) Installation, without the authenticate.sql file this was not possible, but once i created the file under scripts with a valid (not correct) "database_authentication" then the rebuild was successful and surprisingly with a correct "database_authentication" inside the new created database, which means it has been taken from the original database and not from the authenitcate.sql

[chris_keating]

Baron, the authenticate,sql should contain a valid DATABASE_AUTHENTICATION option value. Here is what I expect and see when the %sqlany17%\scripts\authenticate.sql contains a bad DATABASE_AUTHENTICATION option value:

Unloading triggers
Unloading SQL Remote definitions
Unloading MobiLink definitions
Creating new database
***** SQL error: Authentication violation

 If you are seeing something different, can you consider opening a support case documenting exactly the content of the authenticate.sql as well as its specific location in the SQL Anywhere install context that the engine is running.  Also, ensure that you are in fact running an Authenticated Server.  The engine console will output the following:

OEM Authenticated Edition, licensed only for use with authenticated OEM applications.
...
This database is licensed for use with:
    Application: <application>
    Company: <company>

Licenses that are OEM but not requiring authentication report the following:

OEM Edition, licensed only for use with OEM applications.

This is a license that is primarily used in SAP applications that are embedding SQL Anywhere.