Lots of WSUS Problems

Hello,

I got a lot of WSUS problems. First thing, I am using Ghost 8.0 so all
of these boxes are clones. Found out this is bad for WSUS! Found out
that Sysprep for XP was supposed to fix this mess. However, when I
started using Sysprep for XP, I was still getting the same problems!
The computers were not contacting WSUS, BITS was always failing and so
was AU! So, I created a script to delete all of the SIDS that need to
be deleted in order for WSUS, BITS, and AU to work.

All right! WSUS found them and they are contacting eachother just
fine! However...another problem came up!

After awhile, the computers crashed again! BITS and AU stopped working
and the computers stopped talking to the WSUS server. This is my
theory:

I noticed that the ONES that ARE WORKING have
NT_Authority\Authenticated users under the Administrators group on the
local machines. However, the ones that ARE NOT working do not have
NT_Authority\Authenticated users under the local Administrators group.
I could go and add Authenticated users to all of the machines that are
not working and then it should work? Just taking a shot in the dark
there.

However, is having the Authenticated Users group under the local ADMIN
group bad? I have been looking it up on the net, and I can't find any
solid answers! It is all across the board. I would love some help on
this! Thanks!

Forwarded to microsoft.public.windows.server.update_service newsgroup via
crosspost.
--
~Robear Dyer (PA Bear)
MS MVP-Windows (IE/OE, Shell/User, Security), Aumha.org VSOP, DTS-L.org

Chapio wrote:
> Hello,
>
> I got a lot of WSUS problems. First thing, I am using Ghost 8.0 so all
> of these boxes are clones. Found out this is bad for WSUS! Found out
> that Sysprep for XP was supposed to fix this mess. However, when I
> started using Sysprep for XP, I was still getting the same problems!
> The computers were not contacting WSUS, BITS was always failing and so
> was AU! So, I created a script to delete all of the SIDS that need to
> be deleted in order for WSUS, BITS, and AU to work.
>
> All right! WSUS found them and they are contacting eachother just
> fine! However...another problem came up!
>
> After awhile, the computers crashed again! BITS and AU stopped working
> and the computers stopped talking to the WSUS server. This is my
> theory:
>
> I noticed that the ONES that ARE WORKING have
> NT_Authority\Authenticated users under the Administrators group on the
> local machines. However, the ones that ARE NOT working do not have
> NT_Authority\Authenticated users under the local Administrators group.
> I could go and add Authenticated users to all of the machines that are
> not working and then it should work? Just taking a shot in the dark
> there.
>
> However, is having the Authenticated Users group under the local ADMIN
> group bad? I have been looking it up on the net, and I can't find any
> solid answers! It is all across the board. I would love some help on
> this! Thanks!

> Chapio wrote:

>> I noticed that the ONES that ARE WORKING have
>> NT_Authority\Authenticated users under the Administrators group on the
>> local machines.

This is not good.

>> However, the ones that ARE NOT working do not have
>> NT_Authority\Authenticated users under the local Administrators group.

And Authenticated Users should /not/ be a member of the local Administrators
group.

>> I could go and add Authenticated users to all of the machines that are
>> not working and then it should work?

Not as designed. More significantly you'd be creating a security hole the
size of a double length super-size dump truck!

>> However, is having the Authenticated Users group under the local ADMIN
>> group bad?

Yes. By putting Authenticated Users in the local Admin group, you
effectively make EVERY person in your network an authorized Administrator of
that machine. While it may not be so critical for a desktop system (many
desktops still run with everybody having local Admin privilege), it could be
a disaster for a server.

If adding Authenticated Users to the Administrators group allows the
Automatic Updates service to work as intended, then I'd venture an educated
guess that the Automatic Updates service is not configured to LogOn with the
SYSTEM account, or that the SYSTEM account has had its group memberships
changed, and is lacking some critical "System" permissions.


--
Lawrence Garvin, M.S., MVP-Software Distribution
Everything you need for WSUS is at
http://technet2.microsoft.com/window...s/default.mspx
And, everything else is at
http://wsusinfo.onsitechsolutions.com
.....

Thanks for all of the input Lawrence! I do have a few more questions
for you.
First, I am only a Systems Administrator at a call center. Our HQ is
clear across the states the people there set up the WSUS server that is
currently in my server room. So they did all of the configurations and
I just make sure the computers are getting updates. I have no control
on the WSUS server besides moving computers from one group to another
or removing them.

Also, I am only talking about desktop machines, we do not do servers
under WSUS.

My next question is, having the NT_Authority\Authenticated Users in the
Administrators local group on the machine and having a group policy
under AD enabled that locks the users down pretty tight, how "open"
would the machine be then?



Lawrence Garvin (MVP) wrote:
> > Chapio wrote:
>
> >> I noticed that the ONES that ARE WORKING have
> >> NT_Authority\Authenticated users under the Administrators group on the
> >> local machines.
>
> This is not good.
>
> >> However, the ones that ARE NOT working do not have
> >> NT_Authority\Authenticated users under the local Administrators group.
>
> And Authenticated Users should /not/ be a member of the local Administrators
> group.
>
> >> I could go and add Authenticated users to all of the machines that are
> >> not working and then it should work?
>
> Not as designed. More significantly you'd be creating a security hole the
> size of a double length super-size dump truck!
>
> >> However, is having the Authenticated Users group under the local ADMIN
> >> group bad?
>
> Yes. By putting Authenticated Users in the local Admin group, you
> effectively make EVERY person in your network an authorized Administrator of
> that machine. While it may not be so critical for a desktop system (many
> desktops still run with everybody having local Admin privilege), it could be
> a disaster for a server.
>
> If adding Authenticated Users to the Administrators group allows the
> Automatic Updates service to work as intended, then I'd venture an educated
> guess that the Automatic Updates service is not configured to LogOn with the
> SYSTEM account, or that the SYSTEM account has had its group memberships
> changed, and is lacking some critical "System" permissions.
>
>
> --
> Lawrence Garvin, M.S., MVP-Software Distribution
> Everything you need for WSUS is at
> http://technet2.microsoft.com/window...s/default.mspx
> And, everything else is at
> http://wsusinfo.onsitechsolutions.com
> ....

"Chapio" <> wrote in message
news: oups.com...
> Thanks for all of the input Lawrence! I do have a few more questions
> for you.
> First, I am only a Systems Administrator at a call center. Our HQ is
> clear across the states the people there set up the WSUS server that is
> currently in my server room.

Ouch... I feel your pain already.

> My next question is, having the NT_Authority\Authenticated Users in the
> Administrators local group on the machine and having a group policy
> under AD enabled that locks the users down pretty tight, how "open"
> would the machine be then?

If you give "Authenticated Users" local Admin rights on a machine, there's
not much you can 'lock down' via policy, since anything can be changed at
the local machine by any user that logs onto that machine with their own
domain account.

You should understand that all that 'group policy' really does is push
registry settings to the local machine. Unless you've actually applied ACLs
to the registry keys, any local admin can go edit the registry and
effectively override any group policy for at least 30 minutes, and
theoretically up to 2 hours, depending on when that desktop system does its
next policy refresh and resets the policy settings.

Given that you've applied a group policy that 'locks the users down pretty
tight'. I'd suggest having the Domain Administrators review those policies
for anything that might be unnecessarily affecting the Automatic Updates
service and/or NTFS ACLs, that could be causing access restrictions for the
SYSTEM account.

--
Lawrence Garvin, M.S., MVP-Software Distribution
Everything you need for WSUS is at
http://technet2.microsoft.com/window...s/default.mspx
And, everything else is at
http://wsusinfo.onsitechsolutions.com
.....

Hey Lawrence,

Thanks again for all of the input! So let me get this straight.
Whoever is an authenticated user and the authenticated users are in the
admin local group they have full access rights to the machine? My team
and I are the only ones that know the Admin password on the local
machine and we have no other local users setup on the computers. These
people are logging in via domain with a group policy that disables
about everything...they can only access the start menu and we set up a
profile that only shows the programs they need. The run command is
disabled, no icons on the desktop, you can't even right-click on the
desktop! So it is pretty tight.

My next question is why in the world would Authenticated Users have to
be in the local admin group on the box in order for the WSUS server to
communicate with the client machines? Thanks a lot!





Lawrence Garvin (MVP) wrote:
> "Chapio" <> wrote in message
> news: oups.com...
> > Thanks for all of the input Lawrence! I do have a few more questions
> > for you.
> > First, I am only a Systems Administrator at a call center. Our HQ is
> > clear across the states the people there set up the WSUS server that is
> > currently in my server room.
>
> Ouch... I feel your pain already.
>
> > My next question is, having the NT_Authority\Authenticated Users in the
> > Administrators local group on the machine and having a group policy
> > under AD enabled that locks the users down pretty tight, how "open"
> > would the machine be then?
>
> If you give "Authenticated Users" local Admin rights on a machine, there's
> not much you can 'lock down' via policy, since anything can be changed at
> the local machine by any user that logs onto that machine with their own
> domain account.
>
> You should understand that all that 'group policy' really does is push
> registry settings to the local machine. Unless you've actually applied ACLs
> to the registry keys, any local admin can go edit the registry and
> effectively override any group policy for at least 30 minutes, and
> theoretically up to 2 hours, depending on when that desktop system does its
> next policy refresh and resets the policy settings.
>
> Given that you've applied a group policy that 'locks the users down pretty
> tight'. I'd suggest having the Domain Administrators review those policies
> for anything that might be unnecessarily affecting the Automatic Updates
> service and/or NTFS ACLs, that could be causing access restrictions for the
> SYSTEM account.
>
> --
> Lawrence Garvin, M.S., MVP-Software Distribution
> Everything you need for WSUS is at
> http://technet2.microsoft.com/window...s/default.mspx
> And, everything else is at
> http://wsusinfo.onsitechsolutions.com
> ....

"Chapio" <> wrote in message
news: ups.com...
> Hey Lawrence,
>
> Thanks again for all of the input! So let me get this straight.
> Whoever is an authenticated user and the authenticated users are in the
> admin local group they have full access rights to the machine?

Yep.

> My team
> and I are the only ones that know the Admin password on the local
> machine and we have no other local users setup on the computers.

Good... but irrelevant. ;-)

Any DOMAIN account would also have immediate Administrative privileges, even
if that account was not a member of Domain Admins.

> My next question is why in the world would Authenticated Users have to
> be in the local admin group on the box in order for the WSUS server to
> communicate with the client machines? Thanks a lot!

It doesn't... except that somebody/something has excessively restricted a
permission(s) on that machine that the Automatic Updates service critically
needs to function properly.


--
Lawrence Garvin, M.S., MVP-Software Distribution
Everything you need for WSUS is at
http://technet2.microsoft.com/window...s/default.mspx
And, everything else is at
http://wsusinfo.onsitechsolutions.com
.....