![[Steve Friedl Logo]](/images/unixwiz-logo-140x80.gif){kind=logo}
This site uses advanced css techniques
YOU DON'T WANT TO DO THIS
Though the technical steps documented in this Evo Tip are correct, in practice we have found maintaining this to be much too much trouble over time (having to deal with it on every upgrade), so we no longer use this practice. Instead we simply define the printers locally via a Standard TCP/IP Printing port and avoid the whole issue of rights.
With the Garfield release of the Evolution payroll service-bureau system, the middle-tier systems rely on Windows services rather than programs running on the desktop. The Package Server, Registration Daemon, and Remote Access Server are among those serviced in this way.
By default, services run in the context of LOCAL\SYSTEM, which has unrestricted access to the local machine, but there are two limitations to this approach:
To ameliorate either or both of these limitations, it's possible to configure the services to automatically logon with a user account (with a password!) at startup, giving it rights to access those resources — including printers.
Before configuring the service to logon as a user, an account must be established for the service to use. It's possible to use the local Administrator account, but this is a poor idea (especially if it's the domain Administrator).
Better is to define a new user — perhaps EvoServer — to have full administrative rights on the Evolution middle-tier systems, limited rights to required network resources elsewhere (for printers, mainly), and no rights anywhere else. This limits just what can be done on the network should the credentials be compromised.
Those with a Windows domain controller can create a domain account which will more easily allow the Evolution servers to access network resouces. They can also be deployed with Group Policy.
For this Evo Tip, we'll be using the fictional account PAYROLLWIZ\EvoServer in our example.
These changes are made in the Services control-panel applet, which of course requires local administrative privileges. Select the service of interest, right-click and select Properties.
Select the Log On tab at the top, then click the second radio button and enter the account name. We're using PAYROLLWIZ\EvoServer, but those using the local administrator account — probably not a good security practice — would enter .\Administrator. The password must be entered twice.
It's common to receive a dialog box popup saying that the account has been granted Logon-as-service rights: this is expected and necessary.
With these steps completed, the service is now prepared to logon as the specified user next time it starts, but it doesn't apply to any currently running service: one must Restart the service for these credentials to take effect.
We'll note that the account name and password are used anew each time the service starts (including at boot time), so if the account's password is changed, so must the logon information. If the password doesn't validate, either because it was entered wrong, or it was changed in the User Manager, then the service will fail to start. This is another reason to use a separate, purpose-made logon account so that routine password rotation of administrator accounts doesn't invalidate critical services.
Even though the service has been granted network logon rights, there still must be printers defined for that user in order for them to be seen by the Registration Daemon. Because Windows stores printer definitions on a per-user basis, one must perform a one-time configuration of network printers for the service-account user.
To do this, login on the server running the Registration Daemon using the service account (DOMAIN\EvoServer or the proper Administrator account), open the "Printers and Faxes" control-panel applet. For each printer used by Evolution, perform the "Add Network Printer" procedure: printers not used by Evolution need not be added.
When a new release of Garfield is issued by iSystems, the file containing the updates is presented to the Evolution Version Service. Activation of a new version is done internally by uninstalling and reinstalling each service, and this has the effect of reverting all services to use the LOCAL\SYSTEM account.
After every upgrade, all services must be reconfigured with the logon information, and this applies to every Windows middle-tier server on which an applicable service is deployed. The Registration Daemon is found only on the main server, but there can be Package Servers on more than one.
The Registration Daemon requires this treatment in order to have access to network printers, but Package Servers only need it to allow a user to kill a hung process: there are no functional reasons why Package Servers require this, and we expect that most Service Bureaus will only treat the Registration Daemon specially this way.
Since this process must be re-applied after each Evolution version upgrade, it can get tedious to walk through all these steps every time, so we've written a small program in VBScript that uses the WMI interface to automate it.
This file can be saved to the desktop, but it must be edited to contain the account credentials used on the system in question. Only placeholder information is present now, and the logon (and service start) will surely fail if left unchanged.
... serviceUser = "PAYROLLWIZ\EvoServer" ' *EDIT THIS* servicePass = "secretword" ' *EDIT THIS* ...
Remember to restart the service(s) after this update.
NOTE: It's not a particularly good security practice to put account passwords in cleartext, so this strongly suggests that one should limit the logon account as much as possible (i.e., don't use a domain administrator account, don't use the same password for this account and for any other, etc.)
This information is not furnished, supported, or endorsed by iSystems, LLC.
First published: 2005/08/22
![[Steve's Email]](/images/steve-email.gif)
![[RSS Feed available]](/images/feed-icon-14x14.png){kind=icon}