Re: Rid AD of Circular Group Membership

2nd thoughts; under assumption everyone is admin all ways.

The quess is each has an account and uses it, rather than two
with the empowered used selectively. ??

So, if so, you have an educational, as well as the policital,
issue(s) to resolve - not just the restructuring if/as included.

For a larger environment we would sketch out the roles
in groups: adm on any station (non-svr), adm on subset or one,
server adm(s) similarly, gprs for delegations off of dom adms,
etc. and have gpo inject the more broadly used (adm on some
part of stations) into the machine local Administrators group.
The Users group has memberships appropriate for account(s)
that ought be able to log into each (subset/individual) machine.

The users who might answer "yes" if asked "do you do things
regularly other than install stuff? things that need admin?"
are candidates for a machine local account that is in that
machine's Administrators group. Their daily-use account
being just a Users member.

The idea is, get them reduced. The plan is then upgrade
them to Vista, that their reduced empowerment is then
constrained.

Even with environment some 50 or 100 times smaller by
machines, 200-300 by users, use of the few needed groups
can be used for "political" leverage. It is just a correct
design approach generally, and from that falls out some
flexibilities that can help to resolve the "issues" mentioned
previously. Notice that when groups are used through-out
to the local machine level, some of those groups can be
usefully present when empty, example: no one having
Administrators membership on a machine via domain
accounts other than the lightly used dom admins, but if one
needs, the whole crew has their dom user account elevated
to an admin on all of the stations until the upgrade is done.

Craft in the empowerments with the group design elected,
parallel current rights by populating these groups (can be
in two parts - what stays, what is just for now), find out
what IS commonly used, provide for it, transition from the
original empowerments to "the used" provisions.
Providing the grease entails some AD delegations, some
group control on the local machines - plus a local admin
where needed (local account).

Domain Admins should be little used in the size system you
mentioned if but a few key delegations are made. Those that
access DA, for config change or more likely monitoring AD,
scanning stations, etc. should be few; those that can DA use
a Domain Users acct for normal login.
Normal, is normal; their most common login.
Dancing to one's own drum aids the "educational" and the
"political" (perhaps better called the "owner's concerns")
issues to flex out their ultimate balances.

That's some real late night hand waves. But think of it this
way. If there is sensitive info, and it can flow, machine to
machine, at some point one may have to account for all
accounts with accessibility, perhaps account even tighter.
As a design can allow, ask how important is controlling the
"random domain account" sampling of any machine's store
of files now enabled by the existing. Etc. You need some
clarity on importance of key factors to the ownership.
Addressing what might be your political and educational
issues flows from there.

Good luck,
ra

"savvy95" <savvy95@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:2AF54D66-CE39-4369-A373-1422ED5AFE8E@xxxxxxxxxxxxxxxx
I took over AD from the previous admin (and you'll see why) and ask for
comments and suggest how I can back out of this:

Administrators Group has a members:
Domain Admins
Workstation Administrators (this was created so users can be admins of
their own machine)

Domain Admins Group has as members
Workstation Administrators

Workstation Administrators has as members
Domain Admins

Plus he added to the Restricted Groups on the Default Domain Policy GPO,
Administrators and Power Users Group.

Now Everyone who's a Workstation Administrator is a Domain Admin; and
there's over 30 people, including the CEO and other executives

I think simply removing the Workstation Administrators group will cause
utter riot; because then users who were administrators of their machine
will
no longer have that role. And some (silly) people ran services under
their
account.

Can anyone help me back out of this, with minimal impact on user's ability
to
control their own machine.

Thank you, thank you, thank you in advance.


.

Relevant Pages

  • Re: Security Breach in AD! Help!
    ... For the domain check the membership of the administrators group, ... on every user account in any of those ... success and failure in Domain Controller Security Policy. ... admin credentials on. ...
    (microsoft.public.win2000.security)
  • Re: Bad XP problem
    ... no way he can re-create the account that owns them. ... OTOH, the files probably *are* readable by administrators, so your advice is ... >> This has to do with a lost admin password in XP. ... The PC won't boot, it ...
    (sci.electronics.repair)
  • Re: Trouble with admin access after creating trust.
    ... Situation still exists - on the 2000 domain, I log on with an account ... from the 2003 domain yet I recieve no admin permissions. ... domain group called Administrators, which is a local built in group. ... into the 2000 local administrator group, but when I log on the 2000 ...
    (microsoft.public.windows.server.active_directory)
  • Re: Incoming E-Mail - cant create contact in OU
    ... central admin pool different than the web app. ... that account a little (if the web app is compromised or something, ... So I started with giving the app pool account domain admins permissions then ...
    (microsoft.public.sharepoint.windowsservices)
  • Re: Security Breach in AD! Help!
    ... > about 5 minutes the user was removed from the built in admin group. ... > changed the default domain policy, the default domain controller policy, ... >> auditing of account logon for success and failure and account management ... >> success and failure in Domain Controller Security Policy. ...
    (microsoft.public.win2000.security)