We would appreciate any help in resolving this problem so we can use the minimally privileged postgres account for logging in as the PostgreSQL service under Windows.
On a Windows Server 2003 server SP2 (not part of a domain), we had a PostgreSQL 8.3.1 server that was running fine. The site's IT staff (who are unavailable to us) did some kind of a security sweep that broke things so that postgres could no longer logon when the service starts. (The same thing happened on two systems at the site; I have a third system at my site that did not get this sweep, and continues to work.)
The PostgreSQL 8.3.1 Service is set to be started by logon as "postgres" (as configured by the MS installer). The postgres does have the "Can login as a service" privilege. The error we get is Event 553: Reason: User not allowed to logon at this computer
http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Windows+Operating+System&ProdVer=5.2&EvtID=533&EvtSrc=Security&LCID=1033 with the indication that the attempted login was as a service. The authentication is listed as "Negotiate".
Login fails in the same way either for an automatic start at boot or for a manual start. If we make postgres a member of the Administrators group, the service can login and starts properly (but we don't want to keep it that way permanently).
(This is not a password mismatch between service login & account. If that were the problem, the error is different, and you still couldn't login when postgres is added to the Adminstrators group.)
We did try the login as local system account, but that caused some other errors (lack of a SYSTEM role, IIRC) so we didn't go down that path.
In our struggles, we tried this:
(1) Remove old postgres user; create a new one (many things needed fixing here as the owner of directories was wrong) [We confirmed that the "Log on as a service" uses the new postgres, not the old one.]
(2) Uninstall & reinstall PostgreSQL. This helped fix the broken things from (1). It preserved the database for us & apparently corrected ownership (Thanks!)
(3) Try to give other user rights to the "postgres" user. Adding ones that seemed possibly relevant didn't work.
(4) We did reboot often to avoid having any cached information or running processes cause problems.