Re: Security using positions and organizations
- From: "nugget" <newsgroup.replies@xxxxxxxxxxxx>
- Date: 27 Sep 2006 05:58:02 -0700
Joe:
Thanks for the numbers. This helps a bunch. In our case, though, we'd
be talking about 150K groups minimum (since we'd have a position group
for each user); fortunately, we don't have near that many users, but it
looks like big object counts are handled well by AD either way.
As for maintenance, HR keeps these positions pretty well-maintained in
their database and, while they don't maintain anything in AD, we have a
home-grown agent that performs all the grunt work of translating that
data to our AD scheme. It uses that DB, compares it to a "snapshot" of
the positions, reporting relationships, and organizations, and does the
necessary adds, removes, and group membership changes in our new
groups. I know what you mean by a pain and this saves us quite a bit.
As for Dist Groups, we do need to use these groups as well for file
security, so we do need to stick with security groups.
Joe Kaplan wrote:
I tend to agree here. People do this kind of thing all the time with AD,
both for security and email list management, and there are even tools out
there to help automate this process.
I don't think this is an excessive amount of groups. We've got around 150K
users and 70K groups and our AD works fine. :) We use groups primarily for
application security, more than file shares and other Windows ACLs.
You do have some options, though, if you are doing this stuff for simple
application security. For example, these groups could potentially be
distribution instead of security. That would mean that they would not go
into the login token, so they would not contribute to "token bloat"
(although at this small number of groups, if there isn't a lot of nesting,
you won't have much token bloat anyway). The downside is that you would not
be able to use any of the Windows security features for getting a user's
group membership and would need to rely on LDAP queries to the memberOf
attribute.
Another thing to consider in this model is potentially using an
authorization framework like AzMan to support your application-specific
roles and provide a mapping between security principals (users and groups)
and roles. AzMan even supports query-based groups, which means that you
could populate attribute data in AD to indicate your positions and reporting
relationships and have AzMan build the groups automatically for you. It is
probably a good idea to consider putting the metadata to represent your
organization into AD directly (setting attributes to indicate the user's
position and such) so that you can use some sort of LDAP query to build the
groups automatically. Maintaining them by hand will be a pain. Ideally,
you would have a provisioning system tied into HR that could populate this
data automatically from your HR system, but you said you weren't going to do
that (you should; it tends to save a lot of money in the long run and
prevent a lot of security woes).
Anyway, those are my additional thoughts. HTH,
Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"Richard Mueller" <rlmueller-NOSPAM@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:%23CoDx$c4GHA.2208@xxxxxxxxxxxxxxxxxxxxxxx
I would say that lots of groups is no problem in AD. Having users with lots
of group memberships can be a problem (the logon token gets larger). And,
if permissions are granted to the user objects, it would be difficult to
transfer these permissions to a successor (they would almost have to be
documented somewhere, as they are very difficult to discover). It would be
much easier and less error prone to change group membership.
--
Richard
Microsoft MVP Scripting and ADSI
Hilltop Lab - http://www.rlmueller.net
"nugget" <newsgroup.replies@xxxxxxxxxxxx> wrote in message
news:1159317340.139972.115740@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thanks for the reply. And your point there about as a person's job
changes, so does their role, is specifically why we did this. This is
one thing that HR does do very nicely: keep people in position numbers
and keep those position numbers constant (i.e. when someone moves jobs,
gets fired, etc. that position number is always there "reporting" to a
manager in a specific org).
As for alternatives, it's early on in the discussion, so we haven't
been offered alternatives. It appears the big problem is with the
positions; we have almost 15,000, so that means at least that many more
groups, plus the 3,000+ organizations.
Richard Mueller wrote:
Sounds like a proper use of AD to me. Permissions to resources are
granted
according to organizational role. As a person's job changes, their group
membership changes. You just have to ensure the right people have
permissions to modify group membership and permissions. What alternative
plan do the critics propose?
--
Richard
Microsoft MVP Scripting and ADSI
Hilltop Lab - http://www.rlmueller.net
"nugget" <newsgroup.replies@xxxxxxxxxxxx> wrote in message
news:1159310724.519814.229050@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hello:
My group in the company with which I work has a design for
organizational security using Active Directory. However, this design
is not being received well by the AD operations folk and information
security department. The line I have received is "this is not the
proper way to use Active Directory."
Let me explain, as succinctly as possible (with apologies if this has
been covered before ... I checked and could find nothing specifically
on this). Basically, the design consists of a group representing the
position of each user in the company as well as the organization in
which that position fits (in addition to the actual user accounts for
each person). For example, if John Smith is in position "Accountant
II" in the organization "Tax Accounting", there would be three
objects:
John Smith's user account, a group for position "Accountant II" and a
group for organization "Tax Accounting". The user John Smith would be
placed in the "Accountant II" position group and this position group
within the organization group "Tax Accounting". The design is a tad
more complex (dealing with dotted-line reporting relationships, etc.),
but this is the gist. We've got users, which are included in
positions, which are included in orgs, which then fit into higher
orgs,
etc.
We went this route because we have the following situations which will
not change:
- HR does not maintain AD (so no OU maintenance or true role/position
maintenance)
- We cannot create or maintain OUs
- We cannot make changes to User objects
- The charge from our management is to secure our applications and
files in an organizational *and* individual-role-based manner (e.g.,
"I
want Jill Brown and her entire organization, to have write access to
this file", but also "The 'Accountant III' and the 'Technical Asst 2'
in the IT department need access to...")
Taking these into account, we developed this plan, which works like a
charm on paper. My question then to the experts is, are we using AD
properly?
--
Thanks so much,
Chris
.
- References:
- Security using positions and organizations
- From: nugget
- Re: Security using positions and organizations
- From: Richard Mueller
- Re: Security using positions and organizations
- From: nugget
- Re: Security using positions and organizations
- From: Richard Mueller
- Re: Security using positions and organizations
- From: Joe Kaplan
- Security using positions and organizations
- Prev by Date: Re: NTFS Permissions
- Next by Date: Join Client PC to domain without domain admin right
- Previous by thread: Re: Security using positions and organizations
- Next by thread: Re: Security using positions and organizations
- Index(es):
Relevant Pages
|
