Re: Security using positions and organizations

Tech-Archive recommends: Fix windows errors by optimizing your registry

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" <newsgroup.replies@xxxxxxxxxxxx> wrote in message
news:1159362341.829505.279830@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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.

Anthony wrote:
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" <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




.

Relevant Pages

  • Re: Security using positions and organizations
    ... at the lowest level, what one can do all can do, in the same team. ... that security to apply to the people which have filled Jim's or Joan's ... However, this design ... if John Smith is in position "Accountant ...
    (microsoft.public.windows.server.active_directory)
  • Re: Security using positions and organizations
    ... We do unfortunately need the lowest level ... as there are countless requests to add Jim Smith and Joan ... if John Smith is in position "Accountant ...
    (microsoft.public.windows.server.active_directory)
  • Re: field validation (was Re: COBOL/DB2 Date edit question)
    ... when you're down at the lowest level in a nested-nested- ... nested-nested table having all that font stuff around just becomes ... What really beefs me is that if you correct (in DESIGN ...
    (comp.lang.cobol)
  • Re: Bug with Microsoft Publisher and VBA (it seems)
    ... I just return to window without warning ... I have ticked the security to the lowest level. ... I have installed SP2 with no more success:( ...
    (microsoft.public.publisher)
  • Windows Update
    ... security to lowest level. ... Canon ... Prev by Date: ...
    (microsoft.public.windowsupdate)