Обсуждение: Win Server 2003: postgres can't logon
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.
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.
On 10/08/10 08:23, Mabry Tyson wrote: > 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". That sounds like Group Policy restrictions. You're going to have to get your IT staff to deal with it, because if the server is an AD domain member you probably don't have access to the group policy settings, and even if you do they're hellishly complicated. If they only used local policy you might be able to fix it up. The tool you want to edit local policy is "gpedit.msc" (execute via Run dialog). For more detail on Group Policy editing, see: http://technet.microsoft.com/en-us/library/cc736591%28WS.10%29.aspx -- Craig Ringer
On Mon, Aug 9, 2010 at 6:23 PM, Mabry Tyson <Tyson@ai.sri.com> wrote: > 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.) That's a really vague description. Is it possible to get a better one from the people who worked on your machine?