Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >
article

KB-4116: Unable to perform DA install if NT Authority\system account is unavailable

Centrify DirectAudit ,  

12 April,16 at 11:18 AM

Question:

Why is the NT Authority\System account needed to connect to SQL database, when the user in question running the install wizard is an SA. In the customer's environment, the NT Authority\System account does not exist which can lead to a problem. The issue is fixed by creating the account and giving the SA rights. The doc is not clear and the error message is

"Invalid Database. The database owner does not have Authenticate Server Permission on the SQL Server"


Answer:

This is by design. Please see the explanation below.

The install wizard has two phases. In first phase (DB creation phase), Centrify create the databases and tables (viz. schema) by running SQL statements. This phase is always run under the context of installation user (which would be an SA).

The second phase is the configuration phase in which the installer runs a bunch of stored procedures (these are our SPs that were created in phase-1) so that we generate the default data viz. factory settings. These stored procedures are always run under Local System account.

All our stored procedures have been configured to run under Local System account. This is by design and cannot be changed. Running stored procedures under Local System account gives us a distinct advantage of running high privilege operations/queries without granting individual users (such as auditors or administrators) any high privileges on the database server itself. In short, when a normal user (e.g. auditor) tries to perform a high privilege operation (e.g. delete session), the SQL will only take care of authentication. Once authentication is passed, the application logic takes care of validating authorization (e.g. make sure user has been granted the "delete session" permissions) and if authorized, we allow the operation to be carried out by the SP which is running under the high privilege NT Authority\SYSTEM account which is also a sysadmin.

Please note that by default, NT Authority\SYSTEM account is generally enabled on all SQL servers. Some customers delete the account after installing the SQL server. For all such customers, it is  requested to re-create the login for this account on SQL server. If there's a security concern, one can always disable the login privileges of the NT Authority\SYSTEM account (i.e. Account Status - Login: Disabled) and installer will still work. The only requirement from Centrify side is that the account must be present on the SQL server, even with a disabled login status.

Please also note that the above configuration will work if the collector and SQL server are located on different systems. If the SQL Server and Collector are running on the same system, and not using SQL authentication, the NT Authority Local System account must exist and have login enabled.  This is because the collector can only run under the Local System account and if SQL server is running locally on the same system, the incoming SQL login is that of the Local System account, not DOMAIN\COMPUTER$ account. Therefore, the Local System login must be in an enabled state. 
 

Still have questions? Click here to log a technical support case, or collaborate with your peers in Centrify's Online Community.