aptrsn
Thu Mar 04 11:00:58 CST 2004
Thank you for your reply Al,
In regards to the AD structure, your correct in seeing it organized from an
ORG chart perspective. The idea is (or was) that our security and
accessability would be managed by group policies linked to the specific
OU's. The idea of organizing the AD structure this way came from Microsoft
(don't laugh) in their Deployment Kit for Windows Server 2003. I will fess
up and claim responsibility for the current design, however since we are
still in that design stage I'm more than willing to redefine the structure
if there is a better way to do so. The bummer is that we had all of this
done ahead of time and had a consultant come in and review our (my) layout
to determine whether or not it was correct in what we were looking to
accomplish.
Anyway, let me give an example as to why I designed it the way I did. We
have several remote sites (each connected by a WAN) that need to be managed
and originally we were going to create seperate domains for each site or
group of sites. However, the most users that we would have that login at
any one site would be no more than 20 (in fact most of them average between
5-10 people). It was recomended to us that instead of trying to manage each
site by domain, that we create a single domain and manage the sites (users,
computers, shares, resources, etc.) by OU's, as shown below:
Site1 (Parent OU)
Computers S1 (child OU of Site 1)
Servers S1 (child OU of Site 1)
Groups S1 (child OU of Site 1)
Customer Service (child OU of Groups S1 )
-contains group "CSR"
Human Resources (child OU of Groups S1 )
-contains group "HR"
User Accounts S1 (child OU of Site 1)
-contains all user objects for Site 1
Site 2 (Parent OU)
Computers S2 (child OU of Site 2)
Servers S2 (child OU of Site 2)
Groups S2 (child OU of Site 2)
Marketing S2 (child OU of Groups)
-contains group "MKRT"
Customer Service S2 (child OU of Groups S2 )
-contains group "CSR"
User Accounts S2 (child OU of Site 2)
-contains all user objects for Site 2
Site3 (Parent OU)
Computers S3 (child OU of Site 3)
Servers S3 (child OU of Site 3)
Groups S3 (child OU of Site 3)
Customer Service S3 (child OU of Groups S3)
-contains group "CSR"
Human Resources S3 (child OU of Groups S3 )
-contains group "HR"
User Accounts S3 (child OU of Site 3)
-contains all user objects for Site 3
Once setup, the management of each site (users, groups, computers, security,
etc) could be controlled by a GPO linked to that specific OU (my example was
from the "Designing a managed enviroment" from the MS Deployment kit, see
page 71). However, I started running into problems because in certain cases,
I have users that not only belong to more than one group (thus my
predicament with mapping G: as the "group" directory), but they also
sometimes travel from site 1 to site 2. I know that as far as user access
and management, the best thing to do is organize your users by group
membership, but to link a specific policy to a group you have to have an OU
to link it too (at least that is how I understood Group Policy management).
To add to this mix, Site 3 is to have only limited access to Sites 1 & 2
since they are completely different organizations. Hopefully this gives some
understanding as to the method of my madness (for it driving me mad indeed).
"Al Dunbar [MS-MVP]" <alan-no-drub-spam@hotmail.com> wrote in message
news:ug3FIUZAEHA.1548@TK2MSFTNGP12.phx.gbl...
>
> "aptrsn" <busn66@hotmail.com> wrote in message
> news:6s51c.444114$I06.4949941@attbi_s01...
> > > I believe you are confusing OU's and groups.
> >
> > Actually, it's my poor choice of terms that tend to cause the confusion.
> Yes
> > your right, the user object is contained in an OU, not a member of it.
In
> my
> > case, I have structured AD in such a way that my group objects are
> > contained in seperate child OU's.
>
> The first question that comes to mind is: "why?".
>
> > ie.
> >
> > Test (parent OU)
> >
> > Site 1 (child OU of Test)
> > ' Contains the group object "Site 1 Users" which ALL users belong to.
>
> Is that *all* it contains?
>
> > Groups (child OU of Site 1 - contains all dept OU's of that Site)
>
> Why is it called "groups" if it contains OU's? Do all departments have
their
> own OU's?
>
> > CUSTSERV (child OU of Groups)
> > ' Contains the group object "Customer Service" which only SOME users
> belong
> > to.
>
> What *else* does it contain? And where are your user accounts located?
>
> As Richard says: "the purpose of OU's is to group objects for your own
> convenience". Do you find the above OU structure convenient to administer?
>
> In most cases the "convenience" refers to ease of administration. OU's
> therefore most often define the boundaries of administrative authority. If
> all of the groups you mention are administered by the same IT group, then
> having them in different (and nested) OU's does little to simplify
> administration or the proper configuration of administrative privileges.
>
> It almost seems to me that whoever developed the structure you are dealing
> with had in mind that it should model the hierarchical structure (ORG
chart,
> reporting relationships, etc) of the company or organization. As Richard
> suggests, group memberships are easily changed, and this is something
> typically done more often than moving a user from one OU to another. But
if
> you model the company hierarchy with the OU structure, you are setting
> yourself up for one heck of a mess when the company does a bit of
> restructuring. Instead of changing group memberships (and possibly
creating
> new groups and/or renaming old ones), you will need to create new OU's to
> model the new structure and then move the users (and groups and
computers).
> This is a lot of work for little benefit, and it also will introduce
> potential security and/or policy issues should the new OU's not inherit
> policies as you might expect.
>
> > > I need to read your post more carefully, but in the mean time I have
> > sample
> > > logon scripts linked on this page:
> >
> > I'm familiar with your site (it's outstanding!!) from previous post that
> you
> > have replied to and I have already experimented with some of your
scripts.
> > However, I have run into the same problem if I have a user who belongs
to
> > more than one departement/group.
>
> Hence Richard's point that the flexibility of group membership makes it
more
> appropriate to handle complicated relationships. An account belongs to
only
> ONE OU. Sure, it could be thought of as also belonging, in a sense, to the
> OU that contains its OU. But this is a highly structured arrangement, and
it
> is not possible for one to belong, in that sense, to two OU's where one is
> not a parent (or grandparent, etc) of the other.
>
> Even then, there is no specific security ramifications to OU membership.
You
> could simulate it in script, but you cannot permit a resource to an OU.
> Therefore, if a user in OU site1 needs access to a resource that users in
> site2 are not allowed to have, this cannot be based on the OU's in which
> they exist, but must be done through group membership.
>
> > I hope this clarifies what I am asking.
>
> I still find your OU structure puzzling. As Richard says, you should leave
> the primary group as originally assigned, and use groups and group
> membership testing to determine the drive mappings to be applid by the
logon
> script.
>
> If you still feel the need of a "primary" group concept, you could create
a
> set of groups that, by convention, each user would be a member of exactly
> one.
>
> Another area where I think you are setting yourself up for a really big
> headache is in having "several different small scripts", which your
example
> seems to indicate to be "one script for each user". We have about 20,000
> users located in one or two hundred sites, but we only have one logon
> script. When a change needs to be made for all users, we only need to edit
> one file.
>
> You might wonder at the script doing the same thing for everybody, but it
> doesn't. The script determines which site the person is located at, and
maps
> shares appropriately (we have a common share naming/mapping convention
that
> helps here).
>
> I would recommend that you reconsider exactly what it is you want to
> achieve, and then go about achieving it in a simple, structured manner.
> Don't create additional, nested OU's except where needed to control
> adminstrative access. I am an admin of one OU representing a site
containing
> 300 staff in different departments: security, administration, finance,
food
> services, and etc. All of our user accounts are in one child OU of the
site
> OU, all groups in another child of the site OU, and all computers in a
third
> OU. We never have to guess what OU to find a particular group in, as they
> are all in the same one. Of course, this is not the only valid structure
one
> could develop...
>
>
> /Al
>
> >
> >
> >
> >
> >
> > "Richard Mueller [MVP]" <rlmueller-NOSPAM@ameritech.NOSPAM.net> wrote in
> > message news:egiZjmIAEHA.2180@TK2MSFTNGP09.phx.gbl...
> > > Hi,
> > >
> > > I believe you are confusing OU's and groups. A user object is
contained
> in
> > > an Organizational Unit. The OU is the parent container of the user
> object,
> > > but the user should not be considered to be a member of the OU. The
user
> > can
> > > have but one parent. However, a user can be a member of an unlimited
> > number
> > > of groups. Permissions are generally granted to security groups. Then,
> > when
> > > users are made members of the group, they get the permissions of the
> > group,
> > > such as permission to a share. Group membership can be easily
modified.
> It
> > > should be rare to move a user from one OU to another.
> > >
> > > It is straightforward to test for group membership. The best way to
> check
> > > for which OU the user is in is either to parse the Distinguished Name
> (DN)
> > > of the user, or use the Parent method to retrieve the DN of the parent
> > > container.
> > >
> > > The purpose of OU's is to group objects for your own convenience, plus
> to
> > > apply group policy. Group Policy can assign a logon script to all
users
> in
> > a
> > > domain or OU. Then, the logon script should check group membership to
> > decide
> > > things like which drives to map.
> > >
> > > It must be noted that the "primary" group of a user requires special
> code
> > to
> > > reveal. I said that group memberships are straightforward to test, but
> > LDAP
> > > does not reveal memberhips in the "primary" group, unless you add more
> > code.
> > > For this reason, I would strongly recommend not changing the "primary"
> > > group. The only time you might alter "primary" group membership is if
> you
> > > support Macintosh clients.
> > >
> > > I need to read your post more carefully, but in the mean time I have
> > sample
> > > logon scripts linked on this page:
> > >
> > >
http://www.rlmueller.net/freecode2.htm
> > >
> > > Most of the programs map drives according to user group membership.
Some
> > > also connect to printers according to computer group membership. I
also
> > have
> > > sample programs to check group membership linked on this page:
> > >
> > >
http://www.rlmueller.net/freecode1.htm
> > >
> > > Clarence Washington also has sample logon scripts on his site at:
> > >
> > >
http://cwashington.netreach.net
> > >
> > > --
> > > Richard
> > > Microsoft MVP Scripting and ADSI
> > > HilltopLab web site -
http://www.rlmueller.net
> > > --
> > >
> > > "aptrsn" <busn66@hotmail.com> wrote in message
> > > news:Hn41c.23594$ko6.217414@attbi_s02...
> > > > I'm new to scripting for an AD enviroment, so please bear with me if
> I'm
> > > off
> > > > in my logic. What I currently have in the AD architecture is a
"Test"
> > > Parent
> > > > OU that contains a number of sub OU's that represent sites. These
> sites
> > > then
> > > > contain sub OU's that represent groups, resources, etc and under the
> > > groups
> > > > OU's are several OU's that represent various departments. For
example
> > > > purposes, the top-down heirarchy would look like the following:
> > > >
> > > >
> > > > Test (OU)
> > > >
> > > > Site 1 (OU)
> > > >
> > > > Groups (OU)
> > > >
> > > > CUSTSERV (OU)
> > > >
> > > > My original idea was to create several different small scripts and
use
> > the
> > > > GPM to assign them to various groups. The user would have a login
> script
> > > > that would assign him/her to a primary group, for example "TestUser"
> > will
> > > > have the primary group set to "CUSTSERV":
> > > >
> > > >
> > > > ' USER LOGIN SCRIPT
> > > >
> > > > Const ADS_PROPERTY_APPEND = 3
> > > >
> > > > Set objUser = GetObject _
> > > > ("LDAP://cn=TestUser,ou=Site 1,dc=mydomain,dc=com")
> > > >
> > > > Set objOU1 = GetObject("LDAP://ou=Test,dc=mydomain,dc=com")
> > > > Set objOU2 = objOU1.GetObject("organizationalUnit", "ou=Site 1")
> > > > Set objOU3 = objOU2.GetObject("organizationalUnit", "ou=Groups")
> > > > Set objGroup = objOU3.GetObject("organizationalUnit", "ou=CUSTSERV")
> > > >
> > > > objGroup.GetInfoEx Array("primaryGroupToken"), 0
> > > > intPrimaryGroupToken = objGroup.Get("primaryGroupToken")
> > > >
> > > > objGroup.PutEx ADS_PROPERTY_APPEND, _
> > > > "member", Array("cn=TestUser,ou=" & objGroup)
> > > > objGroup.SetInfo
> > > > objUser.Put "primaryGroupID", intPrimaryGroupToken
> > > >
> > > > objUser.SetInfo
> > > >
> > > >
> > > > Then because they are a memeber of the group "Customer Service"
which
> is
> > > > contained in the OU CUSTSERV, the logon script assigned to that OU
via
> > GPM
> > > > would process their mapped drive to G:
> > > >
> > > >
> > > > ' GROUP LOGIN SCRIPT
> > > > Dim WshNetwork
> > > > On Error Resume Next
> > > > Set WshNetwork = WScript.CreateObject("WScript.Network")
> > > > WshNetwork.RemoveNetworkDrive "G:",0,true
> > > > WshNetwork.MapNetworkDrive "G:", "\\root\CUSTSERV"
> > > >
> > > >
> > > >
> > > > The issue I am running into is that I have some users that belong to
> > > > multiple groups, and what I want to do is add something to the above
> > > script
> > > > that verifies the user's primary group, and if it's not, than the
> drive
> > is
> > > > mapped to the next open drive letter in sequence.
> > > >
> > > > i.e.
> > > >
> > > > If J: is mapped then map K: to \\root\CUSTSERV
> > > > If K: is mapped then map L: to \\root\CUSTSERV
> > > > if L: is mapped then map M: to \\root\CUSTSERV
> > > > and so on.
> > > >
> > > > My guess is that I would need to define the following:
> > > >
> > > > intPrimaryGroupID = objUser.Get("primaryGroupID")
> > > >
> > > > and then test against the value of "intPrimaryGroupID" to determine
if
> > G:
> > > > gets mapped or some other drive letter.
> > > >
> > > >
> > > > I would appreciate any suggerstions as to how I could re-write the
> above
> > > > script.
> > > >
> > > > Thanks
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>