This is a really great analysis (as usual). From the perspective of how my
company works, the problem is completely intractable because most of our
usage of groups fall into the 2-6 category. There is just no way to track
down application usage of groups, especially when they start doing LDAP
calls to figure out what's in the directory. Our enterprise is not as large
as the very large organization that Joe used to run, but we've got about
130K users and about 70K groups, so we have a lot of stuff to look after.
Our Director of Security frequently asks me if we can figure out how a given
group is used and I tell him no. The other more insidious thing is that
they often tell me that they want/need a tool that allows them to manage all
of the application usage of groups from some sort of central system.
Frequently, some vendor will come in with a web access control product that
can supposedly do this that a high level exec will get excited about.
The problem is that these things can't really work. For web access control
products, they can generally only integrate at the web server level, so they
can only apply security based on URLs. This is way to simplistic to even
begin to cover the various types of role-based security that applications
really need, so it provides little benefit to central management (the apps
will use some code to implement the rest of their role-based security that
won't use the central tool). Additionally, these tools are inevitably
difficult to integrate with servers and apps and won't integrate with all of
them, especially if you have lots of platforms and lots of vendor apps
written in different technologies that cost money. Plus, there is a huge
cost to retrofitting the apps you do control. Since these systems don't
really solve the problem unless they cover everything and they will never
cover everything, they don't solve the problem and waste a ton of money
trying to.
A framework like AzMan from MS actually has the potential to cover all of
the granular security needs of an app and be able to store the policy
centrally in AD or ADAM, so it seems like it would be just what you want.
However, I'm never going to get SAP, Siebel or SharePoint to work with AzMan
(maybe SharePoint someday, but I'm not holding my breath), so already it is
a niche for just a few apps which are basically custom and written in ASP or
.NET. The integration effort to retrofit it to an existing app is not small
and is the kind of thing that will always get chopped by budget priorities,
especially if new features for the app are needed or it is supposedly
"frozen" in maintenance mode.
An externally imposed web access control system like RSA ClearTrust works on
whole URLs, so it can't even handle a scenario as simple as having a web
page render different content for different users based on role on the same
page. Since you frequently need to do that (and much more complicated
security stuff when you get into multi-tier), it is already relegated to a
partial solution.
The process-based suggestion that Joe suggests is really just about the only
way you can practically begin to cobble together a solution. The main
drawback with such a thing is that since it is process-based, it is not
really a source of truth for what is really going on. You are 100%
dependent on people following the process and keeping the documentation up
to date for the data generated by the process to be reliable. It is at
least something you can try that might provide some value without wasting a
ton of money on false promises.
Joe K.
----- Original Message -----
From: "joe" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Saturday, September 16, 2006 12:12 AM
Subject: RE: [ActiveDir] Is a Global Security group being used?
Yep, as sucky as a method as it is it is something that has been floating
around as *a* method for years and years to work out the Windows security
related uses. I know I started mentioning it to folks once I noticed
non-security groups maintained their SID. I find causing temporary easy to
reverse pain much more desirable than deleting it and finding slightly
longer lived pain.
For the general question though, actually chasing down everywhere a group is
used is a tremendously difficult task and I am not aware of any tool that
can do it for every single possible use. The solution is truly to have very
good process around the use of groups and a tight support definition around
their use. This is one of the reasons why I like local and domain local
resource groups, the scope is naturally limited.
So, you may ask where all can the groups be used? The answer is anywhere
that a SID or a DN can be specified. To name a few...
1. Windows Security Descriptors - this includes any kernel securable objects
that can accept a security descriptor as well as many other objects that
have "customized" ACL-like definitions like the customSD for event logs. A
partial list of the "official" securable objects off the top of my head:
O Active Directory Objects
O SAM Objects (users and groups on member machines)
O File System Objects (files/directories)
O Threads/Processes
O Synchronization objects (mutexes, events, semaphores, timers)
O Job Objects
O Network shares
O Printers
O Services
O As of 2003 SP1 the Service Control Manager itself
O Registry keys
O Windows Desktops and Windows Stations
O Access tokens
O File Mapping objects
O Pipes (named or anonymous)
Basically anything that allows you to pass in a SECURITY_ATTRIBUTES
structure when creating the object plus more....
2. Microsoft supplied Windows based applications. This includes things like
ADAM, SQL Server, Exchange, SharePoint, etc etc etc ad nauseum.
3. Third party applications that run on Windows and were written "properly"
to take advantage of Windows security. This list could be long and wide,
there are hundreds of thousands of Windows applications out there.
4. Third party applications that run on Windows and were written incorrectly
to take advantage of Windows security. These apps don't use Windows security
descriptors, they use custom security structures but rely on SIDs or GUIDs
(if they are smart) or names or DNs otherwise.
5. Ditto #4 but running on non-Windows platforms.
6. Applications that use the groups for something other than security. For
instance an IM app that uses groups for contact lists or an email app using
groups for mail distribution.
Numbers 3-6 are exceptionally hard to trace because in all but limited
cases, it is pretty much guaranteed no well known well used interface is
available to enumerate this info. You are completely dependent on how well
you understand your environment and how well you know the underpinnings of
what is running in that environment.
7. Any attribute in AD or ADAM or in fact any directory that takes a DN,
GUID, Text, or SID. As an example here, in an Exchange/LCS enabled R2 Forest
there are 195 DN NON-Backlink type attributes alone, roughly 20 SID
attributes, who knows how many GUID attributes (they aren't marked as GUIDs,
you get to guess...), hundreds of string types, etc.
8. Cross forest uses which are represented through FSPs in the foreign
forests.
9. Privileges/Rights (in GPOs or security policy files)
This is just the stuff I can think of off the top of my head between writing
this and smoothing out the moving parts in AdMod for general release. I am
sure there is more. It is something that I have sat down and thought about
multiple times through the years and have code in various stages of
development to try and generate reports or running databases of the current
use of security principals. If anyone tells you they can give you a
comprehensive list and you have anything but the simplest Windows only
environment which is well locked down by process/procedure (i.e. you don't
even need the list) you can probably assume they are trying to sell you the
moon or they don't actually understand the scope of the issue. I would
generally assume the latter because there are quite a few folks who think
they understand Windows security that really don't[1]. I often am not sure
if I understand it. :)
joe
[1] Try not to attribute to malice that which is adequately ascribed to
ignorance. ;)
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
