Service Configuration and Ingres Connection details FAQ

Document ID : KB000055607
Last Modified Date : 14/02/2018
Show Technical Document Details

DXserver service log on

Windows XP / 2003

The service log-on will be "LocalService". This is the display name in the services applet, but the internal name is NT AUTHORITY\LocalService. See below for more details on the LocalService user.

Windows 2000

The service log-on will be "LocalSystem". This is the display name in the services applet, but the internal name is NT AUTHORITY\LocalSystem. See below for more details on the LocalService user.

Why can't we use LocalService on Windows 2000?

Windows 2000 does not contain the "LocalService" user and we cannot add it so we must use the "LocalSystem" user on this operating system.

What users and groups are created in Ingres during installation?

  • A group called "dsaadmin" is created.
  • "localservice" or "system" user is added to Ingres, depending on the operating system, and given a default group of 'dsaadmin'. The reason we add "system" instead of "localsystem" is because Ingres internally converts "localsystem" over to "system" for its checking.

How are databases and tables created?

To create databases for eTrust Directory, the DXtool dxnewdsa is used. This tool will:

  1. Create an Ingres database (The DBA for this database is the current user).
  2. Grant access to the database to the group "dsaadmin" .
  3. Create the eTrust Directory database tables and indexes.
  4. Grant access to the tables and indexes to the group "dsaadmin".

In order to backup, restore, load or destroy the database the corresponding DXtool (dxbackupdb, dxrestoredb, dxloaddb and dxdestroydb) must be run by the DBA (or creator) of the database. Running these tools as another user, even if they have been granted access to the database will not be sufficient to perform these activities.


  • With Ingres 2.6 that eTrust Directory installed, all databases were created with an owner of "ingres". This was because we installed embedded Ingres. This also meant that any windows user could access any ingres database (un-secure).
  • With Ingres r3, there is no "embedded" concept anymore, so all databases created have an owner of the user who created the database (usually the user logged in). If the user wants other users to access the database, they must grant access to the database for the new users. If they used the r8.1 "dxnewdb" to create the database, the database would have an owner of <user logged in>, BUT access would also be granted to the "dsaadmin" group which all of our tools connect to Ingres with.

DXserver connection example

  • The service is started up and the logon user (localservice/localsystem) is then used by ingres as the connecting user.
  • Ingres then checks to see if that user has permission to connect.
  • If no then the connections fails.
  • If yes then Ingres connects the user to the database.
  • When accessing database objects (tables, views, procedures, etc) Ingres checks to see if the user can access the object for the type of operation requested. All of the eTrust Directory tables have grants to the dsaadmin group, and since the connecting user (system/localservice) has dsaadmin as its default group Ingres allows the connection to proceed.

Windows User Explanations


It has minimum privileges on the local computer and presents anonymous credentials on the network. This account does not have a password. If you specify the LocalService account in a call to the CreateService function, any password information you supply is ignored.

The user SID is created from the SECURITY_LOCAL_SERVICE_RID value.

The LocalService account has its own subkey under the HKEY_USERS registry key. Therefore, the HKEY_CURRENT_USER registry key is associated with the LocalService account.

The LocalService account has the following privileges:

Any privileges assigned to the "Users" and "Authenticated Users" groups

The LocalSystem account is a predefined local account. It has extensive privileges on the local computer, and acts as the computer on the network. The name of the account is NT AUTHORITY\LocalSystem. This account does not have a password. If you specify the LocalSystem account in a call to the CreateService function, any password information you supply is ignored.

A service that runs in the context of the LocalSystem account inherits the security context of the SCM. The user SID is created from the SECURITY_LOCAL_SYSTEM_RID value.

Known Issues

Windows XP / 2003 File System Permissions

By default, Windows grants the "Users" group permissions to Read, Read & Execute, and List Folder Contents for all local file systems. The default "Users" group contains the "Authenticated Users" group, which in turn encompasses the "NT AUTHORITY\Local Service" account used to start the DSA.

Security hardening of the Windows operating system is common place in real-world eTrust Directory deployments, and this may involve the removal of the rights assigned to the "Users" group.

If the "Users" group, or specifically the "NT AUTHORITY\Local Service" account, doesn't have access to Read & Execute the eTrust Directory installation directory (%DXHOME%), the Ingres Database installation directory (%II_SYSTEM%) and the CA Licensing directory (and all child objects of those directories), then the DSA will fail to start with the following error:

C:\>dxserver start democorp
democorp starting
Dxserver service could not start, possibly due to Ingres.
Access is denied. (0x5)

democorp failed to start
The command dxserver start failed.

This can be resolved by re-adding the permissions mentioned above for the "NT AUTHORITY\Local Service" account or "Users" group, and propagating them to all child objects.

Sysinterals' Filemon utility (a freeware tool, with source code) can be used to further diagnose permissions issues that prevent the DSA from starting with the error message shown above. Use the tool with the filter Include: dxserver.exe to show that cause of the "Access Denied" error.