|
fully agree on most of what you've said (except I'm not
such a big fan of DLGs, but I see your point).
I like the idea of converting a group to a DL from a
security group - I've just done a test and it really works well ;-) The
group is no longer applied to the security token of a user belonging to the
group, however, the group keeps it's SID and will also still be resolved
just fine when checking ACLs (you can obviously not set new permissions
based on the group...). "Reactivating", i.e. turning it back to a
security group, the group also worked well - good thinking
Joe!
/Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Donnerstag, 11. M�rz 2004 15:51 To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] AD Groups Group use detection is one of the more difficult things to
do in Windows.
The key thing is to have a very tight standard use process
for groups. The names should tell you what they are used on and you should
really put the smack down if people are found using them in a way outside of the
standard. Alternatively you can force everyone to document every single use of
the group. Since this means keeping additional documentation I have started work
internal to the company I contract for right now to actually create a new
attribute for groups called resources (or maybe joeware-Resources :oP ) which is
a multivalue unicode string attribute and when you apply the group to something
you you update that attribute, that way the group becomes the place to find out
where it is applied, of course this only works as long as people update it. You
could set up (and my future future goal) an automated system of sort that
creates the group and assigns it permissions to things and updates the attribute
all on one fell swoop. Most people are a ways from that and I know I
am.
This problem is yet another reason why I like domain local
groups so much. The scope of the problem is greatly reduced. With a gobal or
universal group the scope of your checking for its use is all domains in the
forest, all domains that trust the domain that the group exists in. This could
be trusted NT4, other Windows forests, etc. With a domain local group the scope
is limited to the one domain and the members thereof. This is also why I don't
like seeing groups named HR-DEPT or other role based groups because people tend
to see them and say, oh yeah, that is who I want, and apply that to whatever
they are trying to secure. I understand the reasoning behind role based stuff
like that, but much prefer resource securing with resource specific groups.
Actually I think it would be cool if you could have a role based group that
can't have permissions applied to it. It can however, be nested in resource
specific groups that can have permissions applied. (Hey Stuart/Eric you
listening, am I on crack here?).
Now where do you check for use if you have no idea where it
is being used?
You have to check every ACL on every file on every folder
on every machine within the group's scope. You have to check the rights
assignments in every machine and every gpo within the group's scope. You have to
check the acl on every registry key of every machine within the group's scope.
You have to check the ACL of every AD object in the group's scope. You have to
check the ACL of every service on every machine within the group's scope. You
have to check the ACL of every file share of every machine within the group's
scope. If you have Exchange you have to check every ACL (and MAPI Role Property)
of every mailbox within the group's scope. If you have fun programmers or
vendors with fun programmers who really play with security you could possibly
have to check every single securable kernel object within the group's scope.
This could be named pipes, processes, threads, job objects, etc etc. Do a search
on securable kernel objects and you should be able to find a list that will take
a security descriptor parameter which means they are
securable.
Every person on this list could take a reasonable swipe at
what objects above would *probably* be secured in their respective companies
(have fun in MS hehehe). No one could make any kind of statement for all of
them. Heck, I wouldn't make a statement for our company and I know what the
actual standards are and bust people when they don't follow them when I catch
them and we have been pushing our standards for 7+ years. Some people still just
do whatever they feel like simply because they don't know better or feel that
they know better and have the power.
Something I think could work is if you convert a group to a
DL from a security group, it will keep its SID and it won't get stripped off of
ACLs but the security tokens won't get build with the SID in it... That should
effectively flush out uses of the group over time without permanently deleting
the group. As people call you chase down where it might be getting used. If you
see the group being converted back into a security group automatically it means
somewhere Exchange is using it.
-------------
http://www.joeware.net (download joeware)
http://www.cafeshops.com/joewarenet (wear joeware)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nicolas Blank Sent: Thursday, March 11, 2004 2:16 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] AD Groups Another might be to
check where the groups are being used. If they're used to secure file/print type
resources and/or AD resources then they may be discovered using a decent
reporting tool, i.e check if group X is used in AD anywhere, or is present on
THAT server. You could explore this via scripts or use third party reporting
tools that support ACL level reporting From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of GRILLENMEIER,GUIDO
(HP-Germany,ex1) delete one by one and
see who screems ;-) or go through a
terrible audit of your whole IT environment to see which groups are used on
which resoures on any joined or trusted part of your AD infrastructure.
Welcome to the downsides of the DACL (Discretionary Access Control List) model,
where any owner controls ACLs on his objects => I sure hope that MS
is able to keep to their plans to try to replace DACL with RBAC (Role Based
Access Control) in future OSs - but they have a long way to go (won't even try
to imaging the compatibility issues...). /Guido From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Is there a way that I can see
what groups are not used anymore in AD. |
- [ActiveDir] AD Groups Philadelphia, Lynden - Revios Toronto
- RE: [ActiveDir] AD Groups GRILLENMEIER,GUIDO (HP-Germany,ex1)
- RE: [ActiveDir] AD Groups Nicolas Blank
- RE: [ActiveDir] AD Groups GRILLENMEIER,GUIDO (HP-Germany,ex1)
- RE: [ActiveDir] AD Groups GRILLENMEIER,GUIDO (HP-Germany,ex1)
