Re: Nasty problem with time service after installing SP1.
- From: "Myron" <Myron@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 14 Apr 2005 02:10:05 -0700
Possible. I didn't do nothing special when upfrading w2k3 server to SP-1.
The problem just happened. So, yes. It seems be a issue with the way a
domain works. A local server has the user rights applied locally. A domain
controller has the user rights applied within a group policy.
Pass. Good news is that it's still working as it should.
"David Wang [Msft]" wrote:
> No problem. I didn't know about the change until your post and I was curious
> as well.
>
> > 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.
>
> Based on what I see, it looks like the OS itself is automatically adding
> back the missing privilege -- perhaps on some situations, this cannot be
> done for some reason -- hence the Kb article. For example, when I manually
> remove the privileges from LocalService, not only does W32Time keep running
> (so the tokens are cached by services.exe), but on reboot, the privileges
> are automatically added back to LocalService such that I cannot even get
> into your state.
>
> I'm beginning to think that being the Domain Controller has something to do
> with the anomaly in behavior.
>
> --
> //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:F2A3A59C-F089-46CA-AF5F-62639FFF8CA6@xxxxxxxxxxxxxxxx
> 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?
> > >
> > >
> > >
> >
> >
> >
>
>
>
.
- 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
- Re: Nasty problem with time service after installing SP1.
- From: David Wang [Msft]
- Re: Nasty problem with time service after installing SP1.
- From: Myron
- Re: Nasty problem with time service after installing SP1.
- From: David Wang [Msft]
- Nasty problem with time service after installing SP1.
- Prev by Date: Re: Disable "welcome to windows" screen
- Next by Date: EFS, Shared Folder, Authorise on a PER FILE BASIS!?
- Previous by thread: Re: Nasty problem with time service after installing SP1.
- Next by thread: Post 2003 SP1 Errors
- Index(es):
Relevant Pages
|
