Security Template question

  • Thread starter Thread starter Chris Hall
  • Start date Start date
C

Chris Hall

Good afternoon,

I am using the W2K Security Hardening Guide templates as a starting point to
secure our workstations/servers. Looking at the Restricted Groups, I want to
add groups and make the appropriate restrictions. Would I be correct to
assume that having a group in the Restricted Groups, such as Server
Operators, I would be able to assign users and the security template would
keep other users from being added once the policy is applied?
 
One more question: the guide lists additional security settings that can be
configured using the registry editor or installing the sceregvl.inf. It
doesn't make it clear whether installing the inf file will actually make the
changes or just allow these changes to be made through the Security
Configuration and Analysis tool. Can someone clarify this?
 
It would not prevent other users/groups to be added to the restricted groups
but upon security policy refresh the user/group that is not specified in the
restricted group would be removed from the group. On domain computers
computer configuration policy that includes security policy is refreshed
every 90 minutes by default with a thirty minute random offset to prevent
all computers from refreshing at the same time. If you want to test it out
you can use secedit or gpupdate on XP/W2003 computers to force a refresh of
computer and or user policy. --- Steve
 
The link below explains this a lot better. The sceregvl.inf file determines
what registry settings show as "security options" in the security policy and
allows you to customize it if you want to add more options such as disable
lm hash storeage as an example of a possibility. Be sure to make a backup of
the existing sceregvl.inf before making changes or copying a new
sceregvl.inf to a computer. --- Steve


http://www.shavlik.com/Whitepapers/Customizing Microsoft Security Templates.pdf
 
Also, just a little info . . .
You will notice that for a Restricted Group definition there
are both members within and memberships of the group
that you can specify.
The members you state are to be within the group will be
the exact and total membership in the group (at least it will
be that way immediately after the policy is applied).
However, if you leave the memberships of the group not
defined, then the group that is being restricted can have
whatever nesting in other groups. If however you enter
a group in the memberships of area, then that will become
the complete and total set of groups in which the restricted
group will be nested as a member.
 
Thanks Steve & Roger. I would assume that when it comes to restricting
memberships to & of groups(nesting groups), I would use Delegation of
Authority to restrict that.
 
Not sure I totally follow your question.

If you ask how would you let someone manage the group
(its members and its memberships) after the group is under
control of a resticted group definition, the answer is that
they must be able to edit the settings in that GPO holding
the restricted group definition. (However, if there are
memberships defined of the resticted group in other groups,
i.e. that tab is blank in the restricted group definition, then
the group can be added to other groups in the normal way.)
 
major bloop . . .
the restricted group definition. (However, if there are
memberships defined of the resticted group in other groups,
Click to expand...
should have said
"However, if there are _no_ memberships defined for the restricted . . ."
 
Roger,

I was wondering if I wanted to limit what person(s) were or were not to be
allowed membership to a group, how would I do that and ensure that it
wouldn't not be changed in the future? Currently, we have a total of 5 in my
department, all of which are members of the administrators group. Also, 4 of
us share the administrator password. I am trying to tighten ALL security, so
I'm thinking that I should remove all members from the administrators group,
change the administrator password and use delegation of authority to handle
day-to-day administration like creating/modifying users/groups. By
controlling administrative access, I would be able to control the ability of
people adding users to groups willy-nilly.

One thing I say about handling administrative tasks was to use multiple
usernames for administrators. Each of us would have a username with basic
rights and another with administrative rights. Do you use this in your
network?
 
Chris Hall said:
Roger,

I was wondering if I wanted to limit what person(s) were or were not to be
allowed membership to a group, how would I do that and ensure that it
wouldn't not be changed in the future? Currently, we have a total of 5 in my
department, all of which are members of the administrators group. Also, 4 of
us share the administrator password. I am trying to tighten ALL security, so
I'm thinking that I should remove all members from the administrators group,
change the administrator password and use delegation of authority to handle
day-to-day administration like creating/modifying users/groups. By
controlling administrative access, I would be able to control the ability of
people adding users to groups willy-nilly.

One thing I say about handling administrative tasks was to use multiple
usernames for administrators. Each of us would have a username with basic
rights and another with administrative rights. Do you use this in your
network?
Click to expand...

Yes, sort of. What I advocate is giving everyone a normal user account,
and letting them know that this is the account for day-to-day use.
Then, those that have delegated responsibilities have a "privileged"
account, which is to be used only when its powers are being used.
Depending on circumstances, this might be a full admin but more often
it is only a plain user account that has been delegated powers and/or
granted specific access or right, all according to task.
If the sensitivity of the environment warrants, where the privileged
account are allowed to be used, allowed to login, is something one
should also look at (is it a secure, secured and healthy desktop? on
a non-sniffed, non-sniffable network, etc.)
I do believe there are trade offs between a shared admin account (no
individual accountability in the logged actions) and individual admin
accounts - the biggest being that everyone wants one. There should
be very few, and with use of delegation they do not need to be used
all that often (at least this is so of DA, i.e. Domain Admin, and this is
absolutely so of EA and SA)
 
Thanks for the input.

Roger Abell said:
in 4 security, ability

Yes, sort of. What I advocate is giving everyone a normal user account,
and letting them know that this is the account for day-to-day use.
Then, those that have delegated responsibilities have a "privileged"
account, which is to be used only when its powers are being used.
Depending on circumstances, this might be a full admin but more often
it is only a plain user account that has been delegated powers and/or
granted specific access or right, all according to task.
If the sensitivity of the environment warrants, where the privileged
account are allowed to be used, allowed to login, is something one
should also look at (is it a secure, secured and healthy desktop? on
a non-sniffed, non-sniffable network, etc.)
I do believe there are trade offs between a shared admin account (no
individual accountability in the logged actions) and individual admin
accounts - the biggest being that everyone wants one. There should
be very few, and with use of delegation they do not need to be used
all that often (at least this is so of DA, i.e. Domain Admin, and this is
absolutely so of EA and SA)
Click to expand...
 
Back
Top