Re: Setting Audit Permissions Differently for Each User
- From: "Roger Abell [MVP]" <mvpNoSpam@xxxxxxx>
- Date: Thu, 4 Jan 2007 01:13:29 -0700
"Will" <westes-usc@xxxxxxxxxxxxxx> wrote in message
news:aJCdnelJEf8whgrYnZ2dnUVZ_t6qnZ2d@xxxxxxxxxxxxxxx
"Roger Abell [MVP]" <mvpNoSpam@xxxxxxx> wrote in message.. . .
news:OwHUSO%23KHHA.3560@xxxxxxxxxxxxxxxxxxxxxxx
Hi Will,
Jesper is quite correct in his response.
You may be able to accomplish this objective more simply than
defining a group with all accounts except System however, if
your users are members of Users (or Domain Users and hence
of Users).
Note: Actually Interactive _might_ be irrelevant, in or out of Users.for this to work, you would need to have Interactive and
Authenticated Users removed from Users (I routinely remove
Interactive and Authenticated Users from Users anyway).
I was overreaching, reverting Guests to be non-Users; here unneeded.
again, we are in agreement
I've never been crazy about Authenticated Users as a . . .
The only problem in your approach is you would need to think through what
other kinds of access were previously covered by Authenticated Users and
provide for those another way. For example, Domain Computers, Domain
Controllers, Computers from Trusted domains, etc.
True, but you see, it is not really that hard.
Needed permissions on AD objects are not what we are concerned with here.
(Remember, DCs are unique as to required entity access needs.)
For member machine access rights making Users actually be locally defined
user accounts is sufficient.
One may add domain accounts (user/comp) if and as needed (but none
is necessary). For machine / domain member health there are no further
requirements if all local accounts are provided for.
One is just reverting Users to its earlier semantics.
The very groups you just mentioned in example are effectively
collections of local machine System accounts (network imprints of).
They are mostly seen for AD object control, etc. but could feasibly
be used for local machine rights. If so, considerations would be no
different than for any other foreign principals.
For AD objects Authenticated Users takes on a whole new and
extensive presence / set of issues (mostly due to direct ACLing).
If your concern is about audit of AD methods use, then AuthUser
and its includers would need to be avoided in preference for
the defined collections you exampled (let's not get into audit of
System of the auditing DC instance differently from audit set for
EntDomControllers<g>).
Against base of Users being local user accounts (complete save admins)
one may add external principals as is needed for the machine's purpose.
The machine itself and domain membership itself, neither impose a
required external/foreign membership in the machine's Users group.
Ability to access with enterprise purposes can impose memberships
in Users, as this does DA in Admins. But, to nail it once more, none
are necessary so build from a normalized Users base per spec of box
is really all that posting was indicating.
You can probably guess that AU usage and drift from first generation
NT architect intent is something of a pet to me.
Roger
.
- Follow-Ups:
- Prev by Date: Re: Windows 2003 Domain Controller (Open Port 593)
- Next by Date: Re: prevent file deletion
- Previous by thread: Re: Setting Audit Permissions Differently for Each User
- Next by thread: Re: Setting Audit Permissions Differently for Each User
- Index(es):
Relevant Pages
|
