Security using positions and organizations

[nugget]

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

[Richard Mueller]

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" <newsgrou...@netchris.com> wrote in message
news:1159310724.5...@b28g2000cwb.googlegroups.com...

[nugget]

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]

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" <newsgrou...@netchris.com> wrote in message

news:1159317340.1...@m7g2000cwm.googlegroups.com...

[nugget]

I read that using the tokenGroups attribute on the AD user object can
be used to not only get the list of the groups of which the user is a
direct member, but also the nested groups (i.e. If I'm a member of
"Project Managers", and that group is a member of "Corporate Managers",
the tokenGroups will have both for my user object, not just PMs, the
direct group). Is this a different token or does the logon token also
carry those nested groups as well? In this case, I worry that this
design could increase that as now each user is a member of their
position group and every organization up to the CEO, in addition to
whetever groups they had before. Assuming this is the case (login
token also has nested groups), does this only affect the logon process,
or does it affect every facet of permission-requiring access (file
access, specifically)?

Indeed, what you say about users with direct permissions granted to
them is what we had in mind when we put forth positions containing one
user. As a general rule for our design, we stated that, except for the
position placing, we would give no user any direct permissions unless
absolutely necessary (i.e. "The VP of Important Organization needs
access to this file NOW!!!").

[Joe Kaplan]

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" <rlmuelle...@ameritech.NOSPAM.net> wrote in message
news:%23CoDx$c4GHA...@TK2MSFTNGP04.phx.gbl...

[Richard Mueller]

Yes, the tokenGroups attribute includes all group memberships (in the
domain), including the "primary" group and memberships due to nesting. The
logon token is similar. Still, you would have to have a lot of
organizational levels to really bloat the token. Joe probably has a better
idea how many groups would be a problem, but I believe it's much more than
100.

--
Richard
Microsoft MVP Scripting and ADSI
Hilltop Lab - http://www.rlmueller.net

"nugget" <newsgrou...@netchris.com> wrote in message

news:1159321944.8...@i3g2000cwc.googlegroups.com...

[Anthony]

I think this is an excellent way to do it. However you can make it a little
easier to operate.
1) You may not need the lowest, or even the two lowest levels of groups. The
question to ask is what resource specifically you would use the lowest group
to protect.
2) You can use the Manager/Reports To function in AD accounts to maintain
the role and check what group membership should be. If you delegate this, it
can be a non-technical task to keep up to date.
3) A web-based AD interface will enable people to maintain their own, and
possibly their department's roles
The most difficult thing is to enforce the procedure within the people
maintaining the groups, and prevent them putting people into groups just to
enable access.
Anthony

"nugget" <newsgrou...@netchris.com> wrote in message

news:1159310724.5...@b28g2000cwb.googlegroups.com...

[nugget]

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.

[nugget]

Anthony:

Thanks for the reply. We do unfortunately need the lowest level
(position) as there are countless requests to add Jim Smith and Joan
Summers to the access list for this file when they really mean they
need Jim and Joan's positions to have access. Handling security at a
higher level just wouldn't meet the need. When Jim or Joan move on to
bigger and better in the company, the original requester still needs
that security to apply to the people which have filled Jim's or Joan's
position.

I think with #2 and #3, you are talking about day-to-day HR
organizational changes. We are fortunate in that HR keeps that data
pretty well up-to-date, but only in their database. We have written an
agent which takes that data and performs the changes to the
org/positions on a nightly basis, so no need for manual intervention
there. We do plan on offering #3 for the maintenance of Ad-hoc groups,
which then would deal with positions (instead of users) at the lowest
level.

[Joe Kaplan]

This is correct. tokenGroups will contain the groups that a user would have
in their logon token if they logged on to that domain. It includes nested
groups and the primary group. It does not contain distro groups.

The Windows token has an approximate max size of 1000 groups. Once you
exceed this number, you can't log in anywhere. You don't want to get too
close to that. You will see some other side effects of having lots of
groups in the token, such as a few perf problems, but you don't hit the wall
until you get in that 1000 range.

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" <rlmuelle...@ameritech.NOSPAM.net> wrote in message

news:ek8oIue4...@TK2MSFTNGP02.phx.gbl...

[Anthony]

Well OK, its a matter of business process. The reason I ask is that the
business logic of enabling one individual at the lowest level of the org to
do something but not their peers is odd. What happens when they are not
there? Does soemone else fill in? I think it is a reasonable assumption that
at the lowest level, what one can do all can do, in the same team. So you
need only a group that they all go in. Also, the data that only the
individual has access to is personal, not shared. So by definition data that
is shared is shared at a level up from the lowest level of the org. So the
question is back to, what resource specifically you would need to secure
with the lowest level of group and not one up. It will reduce the number of
groups to administer by a factor of four or five.
I can see there may be situations where this can not be allowed, but often I
think people like demarcation too much,
Anthony

"nugget" <newsgrou...@netchris.com> wrote in message

news:1159362341.8...@i42g2000cwa.googlegroups.com...

[nugget]

Odd perhaps, but a rule for us nonetheless. And indeed, the majority
of tasks are focused at the organization level, not position.

Ultimately, going further up the chain would be a compromise here. If
we don't have to make that compromise because of performance reasons,
I'd like to have the full flexibility. The administration is really
already done for us in the HR data source and we have a tool in place
to translate that to AD, so it was mainly a question of whether this
level of granularity would be somehow *improper* in AD. From the
responses here, it seems to me we're OK.

Thanks so much for your thoughts here.