C
Cary Shultz
Peter,-----Original Message-----
Hi Folks, can anyone help me out here?
In our current NT4 multi-Master Domain environment we have traditionally
assigned Global Groups defined in the accounts domains directly to ACLs; in
other words we follow a Accounts -> Global Groups -> Permissions (AGP)
strategy.
This differs somewhat from the Microsoft recommended strategy of Accounts ->
Global Groups -> Local Groups -> Permissions (AGLP).
As we are migrating to Windows 2000 and Active Directory, I've proposed to
my colleagues that as we are starting with a clean slate, that we consider
going with the Microsoft recommended AGLP strategy.
The response has been along the lines "Why introduce another layer (Local
Groups) into the equation when the current system has worked perfectly for
years - What benefits will introducing Local Groups give us"?
Most shamefacedly I must admit that I'm stumped here
Can anyone help or point me to any references on the topic? Will using AGLP
give us any benefits over our current system?
Best Wishes
--
Peter <X-Files Fan>
Please Note: Emailed replies cc'd / bcc'd , containing HTML or attachments
auto-binned as spam
.
Usually you can get away with the method that you
currently employ. Where I used to work we did it the way
you do. My higher ups had essentially the same reaction.
In fact, I bet that most places do it the way that you
currently do.
It makes simply more sense to me to do it the MS way. I
mean, think about it. You work in an environment where
there are 300 users ( like I used to ). You have about 30
Global Security Groups. Each Global Security Group has at
least 25 users ( a few have all 300 ). You assign
permissions to resources where the Global Security Group
is the determining factor. It seems to me that there
could be abit of confusion somewhere down the line. Plus,
think about when you need to change permissions. Or when
you need to give other users permissions to a resource.
You now need to add a user from the "Accounting"
department to the GSG_Finance GSG??? This user/these
users in the Accounting Department now have access to
EVERYTHING that the Finance people do!!! Maybe this is
not so bad. But what if it were a few users from the
Customer Service Department????
What I do - where possible - is create the Domain Security
Groups as "normal". I almost always do this based on
Department ( or the equivilent ). I call them GSG_Finance
( for Global Security Group ). I make each user in the
Finance department a member of this group. Now, if you
are thinking along with me, I do not mail-enable this
Security group...I create a Global Distribution List for
this ( called, naturally, GDG_Finance - play with the
Display Name so that it is "#Finance" and the alias so
that the "GDG_" is not part of the e-mail address ).
Now, when I create on the File Server a Departments Folder
( not shared ) and then each individual departments folder
( shared ) I create a corresponding Local Security Group (
naturally called LSG_Finance, for this example ) for each
shared folder. I can then put the GSG_Finance group
inside this LSG_Finacne folder and apply the proper
permissions to the LSG_Finance group.
This makes it exceedingly easy to know exactly what is
what. I can walk into your environment, look at your file
servers and know immediately what is going on.
From a logical point ( or am I being 'anal' again? )
doesn't this make more sense? Sure, you are creating one
more layer. But isn't it worth the extra minute per group
to have this extra layer. Consider this front-end work
that pays huge dividends on the back-end.
Also, if you are going to continue with the current way of
doing things and you start making use of Universal
Security Groups or Universal Distribution Groups it would
seem logical to me that you would simply create the
Universal Group, throw the users in it and then apply
permissions to resources to the Universal
Security/Distribution Group. BAD! Your poor Global
Catalog Server(s)....You see, doing it the way that you
are currently doing it lends itself to this mistake. You
could experience token explosion....
I always suggest: break it down as much as possible. It
might seem like a lot of extra work but it will pay for
itself rather quickly.
HTH,
Cary