Does this site look plain?

This site uses advanced css techniques

Evolution Logo

When using and administering the Evolution payroll service-bureau software from iSystems, usually with a mix of Windows and Linux servers, one runs into a range of supporting user accounts and passwords. It's not always clear where and how they are used and relate to each other, so this Evo Tip discusses the various accounts found throughout the system, plus some advice on best practices for using them.

OS: Windows middle-tier server users

[Windows server logo] The middle-tier software -- the Registration Daemon, Package Servers, and the like - run on Windows servers, and these require administrative privileges to execute properly. This is often done by logging in as the user Administrator and launching the various daemons by hand.

There are two kinds of users - local and domain - and our guess is that most Evolution installations use the domain administrator MYDOMAIN\Administrator for these server logins. Though this works from a strictly technical perspective, it's a very poor security practice, and we strongly object to it.

Since the Evo servers run with that account logged in at all times, any user at that console has full run over the entire network. This is unnecessary and dangerous.

A much better practice is to define a new domain-wide user -- perhaps EvoServers - and make that user a member of the Administrators local group only on the Evo servers in question. This account can be further restricted on the domain controller to only permit logins on those specific servers, which limits how much can be done across the network with those credentials.

Being a member of the Domain Users global group ought to be sufficient for performing network-wide activities such as email and printing - there is no need for the EvoServer user to be in the Domain Admins global group.

Note!
Previous version of Evolution used DCOM technology for communications, and this may have required that the Administrator user on the middle-tier machines be a member of the Domain Administrators group: this is no longer required by Evolution and strongly not recommended.

At no time will Evolution software ever ask for a Windows password.

OS: Linux database server users

[Redhat Linux logo] The Linux database servers also have accounts, and two come into play with Evolution.

First is the traditional root account, also classically known as the "superuser". This user has full rights to do essentially everything on the machine, and it's used for system maintenance and software installation purposes. Only the superuser can add a new user, for instance.

Important note:
This Linux superuser account has nothing whatsoever to do with the Evolution superuser account.

Unlike on Windows, where it's common for even ordinary users to have full administrative rights to their own workstations, Unix and Linux have long had a culture of "don't work as root if you don't have to", and we recommend that here as well. Fortunately, the database servers don't require nearly as much hands-on support as do the middle tier systems, so this won't come up as often.

Anybody with superuser access can do anything, including read, modify, or destroy the Evolution database data without using any Evolution logins. This password should be protected carefully.

The Firebird database that's used by Evolution to store the payroll files also has a corresponding user, not surprisingly known as firebird. The database itself runs as this user, which is also a security precaution: if the Firebird service processes are compromised over the network, they grant access to the data, but not full superuser control over the whole system.

The firebird user owns the files in the /db/evolution directory, but this account should almost never be used to login to the system directly. Instead, login as a "real" user or root and accomplish the tasks that way.

We recommend locking the Linux firebird account: 

# passwd -l firebird

This command, when run as the root user, prevents the account from ever being logged into directly (there is no correct password for a locked account). Since no user should ever be doing this anyway, it's a security precaution that doesn't leave a password to be disclosed or guessed.

OS: Windows workstation users

[Windows XP logo] Of course, users at their workstations (typically Windows 2000 or Windows XP) require logins as well, and these are almost certainly domain logins that authenticate against the main server (the DC) and provide access across the network. This is used for much more than just Evolution: email, fileserver, etc. all require a network-wide credential.

The conversation between Evolution and the servers does not use any of the Windows credentials - we'll cover the Evo users later - but as delivered, running the Evolution.exe program itself requires that the user be a member of the workstation's local Administrators group.

Normal operations don't typically require these permissions, but when a new Evolution release comes out, the auto-update process that downloads the newer modules from the server requires the right to update files in a normally-protected area. When faced with these permissions errors, Evolution simply quietly fails and never completes the job (repeatedly goes back to the login prompt).

This can be fixed by one time changing the security permissions on C:\Program Files\Evolution to grant Full Control over this and all child directories, usually with the Everyone or Domain Users objects. This done, periodic updates are permitted without granting the user full administrative access to the whole machine.

Firebird Database Users

[Firebird Database logo] All of the raw database files (/db/evolution/*.gdb) are stored on the Linux system and owned by the Linux firebird user, the database itself imposes its own additional user structure that Evolution uses.

Firebird uses the gsec command to manage the database users, and it must be run as the Linux root system user. One can display the current list of database users when logged in as the root Linux user: 

# gsec
GSEC> display
 user name       uid   gid     full name
---------------------------------------------------------------------------
SYSDBA            0     0
EUSER             0     0

The first Firebird user, which is created automatically, is SYSDBA and is found in all Firebird installations (Evolution or not), and it's the default owner of everthing: it could be considered the "superuser" of the database.

Evolution's Franklin release introduced an additional user, EUSER, for all of its access, and this follows the security best-practice of not using the superuser-equivalent account for routine, day-to-day work.

Curiously, the uid and gid fields of both users are zero, even though it looks suspiciously like EUSER ought to be assigned the user and group numbers of the firebird Linux user. This is specifically not the case.

Each of these accounts has a password, and it's typically the same for all Evolution installations (we believe it's hardcoded into the software). We won't list the password here in a public document, but it should be available from any valid Evolution user or from iSystems Technical Support.

Keeping the Firebird DB users apart

Though the Evolution software clearly knows which Firebird user to employ for any given operation, there's been some confusion as to just which one should be used for "manual" operations such as gbak and isql. We've seen user mismatches cause non-obvious problems that were very difficult to track down.

Generally speaking, SYSDBA should be used for database patching and database backups, with EUSER for database restores or general query access.

In the event that a DB file has been erroneously restored with SYSDBA, it can be "fixed" by backing it up as SYSDBA, removing the .gdb file, then restoring it with EUSER.

Evo: The "admin" account

All Evolution users are found in the S_BUREAU database's SB_USERS table, and there are two "special" accounts: admin and superuser. We'll discuss both.

The admin account is used to perform the highest-security functions, such as granting new permissions for others, but it's nevertheless a "regular" login that a person uses while logging into Evolution. Though it's possible to actually perform routine day-to-day payroll activities while logged-in to this account, it's a really bad idea: there is no audit trail showing which actual person performed any particular activity (just "admin").

It's also dangerous, in that the system's security architecture won't prevent you from making catastrophic mistakes: you have rights to do everything.

Instead, admin should grant administrative rights to logins used by real people (say, a steve account) and have him login that way. Only a few things can only be done with admin account.

Evo: The superuser account

The superuser account is different: though it's stored in the same user database, it's not not intended for human consumption or direct login. Instead, it's used by Evolution itself to perform security-sensitive operations such as "process payroll". This allows Evolution to access sensitive data as a protected user that the "regular" logged-in user doesn't have rights to.

The name of the account (it doesn't have to be called literally superuser, though that's not a bad idea), password, and security permissions (what's required?) are assigned in the usual way, and the name and password are also entered into the Registration Daemon via the Settings tab:

[Registration daemon password]

Once the login name and password are entered, click Apply button.

This two-step operation (create a user, enter it into the Registration Daemon) must always be done together with matching information. If there is a mismatch of any kind, Evolution won't be able to actually use the Evo superuser account and will report an error:

Error message:
Server servername returned
Failed to switch to SU mode
Server servername returned
Invalid login or password
(Internal code: EInvalidLogin)
(Internal package: Payroll processing procedures)
(Internal code: EServerException)
(Internal package: Payroll processing procedures)

To fix this - where the actual password is presumably unknown - simply go into Evolution's user management and find or define the superuser, and set a password. Then enter this same information into the Registration Daemon.

Evo: Enterprise Controller accounts

With the introduction of the Garfield system (summer 2005), Evolution has moved all of its daemons to system services, replacing the user-launched RegistrationDaemon, PackageServer, and RemoteAccessService programs. One no longer needs to login to Windows to launch these - they're started automatically at boot time.

To control these services is the Enterprise Controller, which provides a web-based interface to the whole system. During installation, one is asked to create a username and password: these are required to logon to the control panel and are unrelated to any other users or passwords on the system.

Screenshots to be added

Evo: Server Setup Codeword

Installing the Garfield release of Evolution requires three components: the Enterprise Controller, the Version Directory, and the Deployment Controller. Each prompts for the entry of a "setup codeword", and this is used to allow associated services to communicate with each other.

This comes into play when running separate test and production systems: the initial service discovery is based on this codeword. Entering livesystem for the production servers and testsystem for test allows all these services to keep themselves separated.

These codewords aren't strictly passwords in the security sense: they're more like identifiers, and need not be kept confidential.

This information is not produced or endorsed by iSystems, LLC.

First published: 2005/02/24