"User rights Assignment" - catch 22

[Gerry Hickman]

Hi,

Setup:
Pure native-mode Win2k network
Dozens of member servers, running range of services
Hundreds of Win2k clients, some are development boxes

Problem:
How do domain wide settings interact with "Local security Policy" settings?

Until yesterday, everything worked fine. Then, head office changed the
service account for our domain wide anti-virus software. In order to
avoid changing the service account on every machine they added it to a
domain-wide computer policy. Lot's of things broke, the reason being
that the domain-wide policy killed all the locally defined service
accounts. I fixed most of it by blocking inheritance of their policy,
but obviously the Anti-Virus software won't work anymore.

I assume there's a "proper" way to deal with this type of thing? It
seems there's no way to "add" a service account to a group policy that
will allow existing locally defined service accounts to continue to work?

 

[Steven L Umbach]

Domain policy will override "defined" settings in Local Security Policy if
the same setting is also defined at the domain level. You can however create
another GPO at the OU level [assuming you have the authority] to define the
settings to your needs and that will override domain policy unless they
enable " no override" on the GPO in the domain that they configured. For
Windows 2000 you can open Local Security Policy on any computer and see both
the local and "effective" settings for any defined setting. If effective is
different than local then there is an overriding policy. In a domain Group
Policy is applied in this order with the last defined setting normally being
applied if that setting is applied in multiple GPO's. The order is
local>site>domain>OU>child OU. If you have an XP Pro domain computer
available you can install the Group Policy Management Console on it and use
it to track down what is going on with Group Policy. You can also use the
gpresult command line tool to see what GPO's are applied to a computer and
when they were last applied.

I wonder what they actually did via the Group Policy. With services you can
define startup [auto/manual/disabled] and what accounts have what
permissions to the service. You could reconfigure that to your needs at the
OU level. --- Steve

 

[Gerry Hickman]

Hi Steven,

Domain policy will override "defined" settings in Local Security Policy if
the same setting is also defined at the domain level. You can however create
another GPO at the OU level [assuming you have the authority]

I tried that, still catch 22 - see below.

to define the
settings to your needs and that will override domain policy unless they
enable " no override" on the GPO in the domain that they configured.

Currently, "no override" is "off", so I can play at OU level.

For
Windows 2000 you can open Local Security Policy on any computer and see both
the local and "effective" settings for any defined setting. If effective is
different than local then there is an overriding policy.

OK makes sense.

In a domain Group
Policy is applied in this order with the last defined setting normally being
applied if that setting is applied in multiple GPO's. The order is
local>site>domain>OU>child OU.

This does not seem to be what is happening, "local" is being "killed"
(see below).

If you have an XP Pro domain computer
available you can install the Group Policy Management Console on it and use
it to track down what is going on with Group Policy.

Is this a special console that only works on XP?

You can also use the
gpresult command line tool to see what GPO's are applied to a computer and
when they were last applied.

That's a new one, I'll look it up.

I wonder what they actually did via the Group Policy.

What they did was define a list of NT accounts who have the "Log on as a
service" right. What happened is that this list stomped on ALL locally
defined service accounts, meaning dozens of services on both member
servers and workstations failed to start after a reboot. The error from
SCM was that the account "does not have log-on permission on this
computer" (something like that). When I looked at "Local Security
Policy" on various computers all the previously defined accounts were
GONE and the only accounts in the list were THEIR NEW ACCOUNTS.

Why is this a problem?

Well here's some possible reasons:

1. They're giving the "Log on as a service" right to accounts that
should not have that right on some servers. Remember it's domain-wide so
they just added a huge (but not complete) list.

2. Some workstations have accounts such as WS1\aspnet, and these type of
machine accounts can not be defined in a group policy!

In the case of #2 setting an OU policy does not help.

What I did in the end was disable inheritance of the domain-wide policy,
and then added their new Anti-Virus service account to EVERY workstation
using a script. So far this is working fine.

I still don't know what the "best practice" solution would be.

 

[Steven L Umbach]

Hey Gerry.

Thanks for the details on what happened. First off Group Policy Management
Console will run only on Windows 2003 or XP Pro computers which is why I
suggested such since your description of the domain indicates all Windows
2000 Servers and probably all W2K domain members. If you don't have an XP
Pro computer in the domain it may be worthwhile investing in it just so you
can use GPMC, it is that good in my opinion when it comes to managing and
configuring Group Policy. It can also be used to backup and restore a GPO.

It is amazing that they unleashed that on you without any warning or testing
and yes domain policy can override local policy as you experienced. You are
correct in that you can not define non default local users/groups in a GPO
security policy. Since you are using non default local accounts [I believe]
the sid would not be the same from computer to computer and in your case you
would need to configure via Local Security Policy as you had been doing.
Enabling "block inheritance" is about the only solution I can think of and
adding the new domain account to local policy with something like ntrights
via a startup script. Glad you got things in some semblance of order and I
hope someone got a royal butt chewing over what they did at the domain
level. --- Steve

Hi Steven,

Domain policy will override "defined" settings in Local Security Policy
if the same setting is also defined at the domain level. You can however
create another GPO at the OU level [assuming you have the authority]

I tried that, still catch 22 - see below.

to define the settings to your needs and that will override domain policy
unless they enable " no override" on the GPO in the domain that they
configured.

Currently, "no override" is "off", so I can play at OU level.

For Windows 2000 you can open Local Security Policy on any computer and
see both the local and "effective" settings for any defined setting. If
effective is different than local then there is an overriding policy.

OK makes sense.

In a domain Group Policy is applied in this order with the last defined
setting normally being applied if that setting is applied in multiple
GPO's. The order is local>site>domain>OU>child OU.

This does not seem to be what is happening, "local" is being "killed" (see
below).

If you have an XP Pro domain computer available you can install the Group
Policy Management Console on it and use it to track down what is going on
with Group Policy.

Is this a special console that only works on XP?

You can also use the gpresult command line tool to see what GPO's are
applied to a computer and when they were last applied.

That's a new one, I'll look it up.

I wonder what they actually did via the Group Policy.

What they did was define a list of NT accounts who have the "Log on as a
service" right. What happened is that this list stomped on ALL locally
defined service accounts, meaning dozens of services on both member
servers and workstations failed to start after a reboot. The error from
SCM was that the account "does not have log-on permission on this
computer" (something like that). When I looked at "Local Security Policy"
on various computers all the previously defined accounts were GONE and the
only accounts in the list were THEIR NEW ACCOUNTS.

Why is this a problem?

Well here's some possible reasons:

1. They're giving the "Log on as a service" right to accounts that should
not have that right on some servers. Remember it's domain-wide so they
just added a huge (but not complete) list.

2. Some workstations have accounts such as WS1\aspnet, and these type of
machine accounts can not be defined in a group policy!

In the case of #2 setting an OU policy does not help.

What I did in the end was disable inheritance of the domain-wide policy,
and then added their new Anti-Virus service account to EVERY workstation
using a script. So far this is working fine.

I still don't know what the "best practice" solution would be.

 

[Gerry Hickman]

Hi Steven,

Thanks for the details on what happened. First off Group Policy Management
Console will run only on Windows 2003 or XP Pro computers which is why I
suggested such since your description of the domain indicates all Windows
2000 Servers and probably all W2K domain members.

Damn. The thought of running Macromedia XP, eeek!

If you don't have an XP
Pro computer in the domain it may be worthwhile investing in it just so you
can use GPMC, it is that good in my opinion when it comes to managing and
configuring Group Policy. It can also be used to backup and restore a GPO.

OK, maybe I could run one in the cupboard under the stairs and long as
no one sees me.

It is amazing that they unleashed that on you without any warning or testing
and yes domain policy can override local policy as you experienced.

Yes, unfortunately this is all too common, but numerous complaints have
landed on deaf ears

You are
correct in that you can not define non default local users/groups in a GPO
security policy. Since you are using non default local accounts [I believe]

Yes, because things like ASP.NET will install them like that.

the sid would not be the same from computer to computer and in your case you
would need to configure via Local Security Policy as you had been doing.
Right.

Enabling "block inheritance" is about the only solution I can think of

I just hope they don't turn it off one day without telling me

Glad you got things in some semblance of order

Thanks. I think I'm going to keep a copy of NTRIGHTS.EXE close to hand
and maybe even try to write a more fully featured LSP manager, but it
means using C++ which is a lot of work.