Re: Nasty problem with time service after installing SP1.
- From: "David Wang [Msft]" <someone@xxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 6 Apr 2005 11:16:34 -0700
> Out of curiosity, how come this slip-up was allowed to happen, where
> W32TIME is now operaring under the LOCAL SERVICE account
> that can not normally change the system time?
I'm not on that team, but I believe this change is intentional and correct.
Security requirements suggest that services have to PROVE they need
LocalSystem privileges to remain using it.
For example, notice DCOM separated out into two different processes now --
RPCSS is now low privileged Network Service and handles all incoming
traffic, so even if exploited, it is less likely to be damaging; while DCOM
Launcher remains LocalSystem and is invoked separately by RPCSS to do the
heavy lifting as necessary. IIS6 goes one step further by making all
network-facing processes be Network Service and the process does not invoke
any other privileged process to do work.
My guess is that the need to change system time does not warrant LocalSystem
privileges, so W32Time service changed to a more secure Local Service
account and added the single privilege that it needed. This is a good change
and not a "slip-up". And of course, with any change, there is risk of
something breaking, but the security benefits outweigh the risks.
I actually do not see the issue you claim, neither with a slipstream SP1
installation nor a RTM + SP1 patch update, so I suspect you had some other
special set of circumstances to get to this point -- and a KB tried to apply
to all those circumstances but missed some. I think it is more useful if you
can help point out the special circumstances -- because simply neither
upgrading nor slipstream show any issues -- and we cannot update a KB
without this sort of info and independent verification. Was this machine
running beta patches, in a domain, etc?
--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Myron" <Myron@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:B22A763C-654B-48B5-9D7A-BB0163B3B056@xxxxxxxxxxxxxxxx
Yes. I rebooted the server afterwards. The KB article does need changing.
For servers on an active directory domain, I suggest that the `Change the
system time` is applied to `LOCAL SERVICE` *BEFORE* applying the service
pack. Also, is states that the user needs to add `Service` to `Change the
system time` user right. I think this is incorrect. It has to be `NT
AUTHORITY\LocalService`.
As to a stand alone server, `Change the system time` may be worth adding
`Change the system time` to `NT AUTHORITY\LocalSystem` before applying SP1.
Out of curiosity, how come this slip-up was allowed to happen, where W32TIME
is now operaring under the LOCAL SERVICE account that can not normally
change
the system time?
"David Wang [Msft]" wrote:
> After making the user permissions change, try to reboot the server.
>
> I tried to intentionally remove the "Change the system time" privilege for
> LocalService on my SP1 Slipstream build, and I find that on every user
> login, the permission was automatically added back such that W32Time
service
> would keep running. Also, I noticed that even when I removed the privilege
> from LocalService, W32Time continued to start/stop just fine on that user
> login session, so there is some user token caching somewhere, which would
> explain what you're seeing. Rebooting after adding the privilege should
> probably work.
>
> If it does, I can put in an update request for the KB.
>
> --
> //David
> IIS
> http://blogs.msdn.com/David.Wang
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> //
> "Myron" <Myron@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:825A8536-34E3-4E84-8118-28605471E43A@xxxxxxxxxxxxxxxx
> First of all, Microsoft's fix does not seem to work. URL to the fix is:
> http://support.microsoft.com/kb/892501
>
> I've made sure that `NT AUTHORITY\LocalService` has the `Change the system
> time` permission. The server still throws the error mentioned in
> Microsoft's
> KB article.
>
> So, I try and create another account for the Windows time service to
operate
> under and get the error:
>
> Event Type: Error
> Event Source: Service Control Manager
> Event Category: None
> Event ID: 7000
> Date: 01/04/2005
> Time: 15:25:52
> User: N/A
> Computer: SERVER1
> Description:
> The Windows Time service failed to start due to the following error:
> The account specified for this service is different from the account
> specified for other services running in the same process.
>
> So, how the hell do I fix this one, expecially if Microsoft's advise does
> not seem to work.
>
> There is also a discussion at
> http://bink.nu/Forums/ShowPost.aspx?PostID=8366
>
> How come Microsoft as released an update that breaks the Windows Time
> Service and this is by design, but the knowledge base article to re-enable
> the time service does not work?
>
>
>
.
- Follow-Ups:
- References:
- Nasty problem with time service after installing SP1.
- From: Myron
- Re: Nasty problem with time service after installing SP1.
- From: David Wang [Msft]
- Re: Nasty problem with time service after installing SP1.
- From: Myron
- Nasty problem with time service after installing SP1.
- Prev by Date: Re: Lots of $NtServicePackUninstall$ in my windows
- Next by Date: Upgrading Windows Server 2000 to 2003 environment
- Previous by thread: Re: Nasty problem with time service after installing SP1.
- Next by thread: Re: Nasty problem with time service after installing SP1.
- Index(es):
Relevant Pages
|
Loading
