Re: Nasty problem with time service after installing SP1.

Sorry if my reply came over all wrong. Was not supposed to be a challenge,
but both of a question born of of curiosity.

Both servers are run-of-the-bill servers. Nothing Beta has been applied and
apart from RepliStor being the lowest level application I have (data
mirroring between servers), there is nothing untowards and the group security
policies generally unchanged. So, the user right assignments have been
unchanged since the first installation of the servers and then, obviously,
promoting both to DCs and putting them in the only forest containing the one
domain.

To me it seems that when SP-1 was applied, W32TIME was removed from
`LocalService` and as you mention put in `LocalServce`, but in the case of
the installation I manage, `LocalService` never had the right to change the
system time, and there the knowledgebase article comes into play.

There are errors. For instance it states to add `Service` to the change
system time right. This should be `LOCAL SERVICE` or `NT
AUTHORITY\LocalService` and an addition needs to be made that very clearly
states that, in the case of a domain, once the default domain policy is
changed, every domain controller needs to be restarted.

In the case of a stand-alone server, just the servers affected need to be
re-started.

I guess where the people who looked after this particular part of the
Service Pack development did slip-up as it W32TIME should have remained in
`NT AUTHORITY\LocalSystem`, but the service secured even further, or the
service pack introduced an additional system account that acted lile `NT
AUTHORITY\NetworkService`, but had the additional right assigned to it to
allow changing the system time. Actually, this additional setup is mentioned
in the KB article. I'm just mentoning that instead of doing this manually,
it could have been done automatically by the SP-1 installer.

There be my constructive comments. Hope they help.

"David Wang [Msft]" wrote:

> > 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?
> >
> >
> >
>
>
>
.

Relevant Pages