Re: AD group logon script question
From: Al Dunbar [MS-MVP] (alan-no-drub-spam_at_hotmail.com)
Date: 03/05/04
- Next message: Al Dunbar [MS-MVP]: "Re: Server-side modem connection"
- Previous message: name: "Re: Please help! How do I download a binary file from URL when link needs to be launched from inside browser after authentication?"
- In reply to: aptrsn: "Re: AD group logon script question"
- Next in thread: aptrsn: "Re: AD group logon script question"
- Reply: aptrsn: "Re: AD group logon script question"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 5 Mar 2004 00:07:03 -0700
"aptrsn" <busn66@hotmail.com> wrote in message
news:ehJ1c.112868$Xp.498973@attbi_s54...
> 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.
GPO's are not my specialty, however, that is another area where one can run
into trouble making things too complicated. Our GPO structure is somewhat
like I described our logon script: one size fits all. The main function of
our GPO is to apply a consistent set of restrictions and restraints to every
workstation.
If individuals need special access to certain resources, we do that by
managing security groups.
> 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.
What did he/she say?
> 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,
Exactly right! ...
> as shown below:
... but here you seem to get carried away a little bit ...
> 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"
You have at least three different OU's for site 1 that contain groups. Two
of these OU's seem to contain only one group each. Who has administrative
access to the "customer service" and "human resources" OU's? If both are
administered by the same person or group of people, there seems little
reason for the CSR and HR groups to be in their own separate OU's - I would
move them down into the "groups s1" OU. This will be more convenient for the
admins, and it also reduces the depth of nesting of OU's.
As I said, GPO's are not my strong point. I take it that you have a
different security policy on the "customer service" and "human resources"
OU's - what kinds of things do these policies do? Are the users that are
members of the CSR group getting the access to resources that is appropriate
for them because their group is in an OU getting a special policy? Or are
they getting at the resources simply because they are members of that group?
> User Accounts S1 (child OU of Site 1)
> -contains all user objects for Site 1
<snip sites 2 and 3 having equivalent structure>
> Once setup, the management of each site (users, groups, computers,
security,
> etc) could be controlled by a GPO linked to that specific OU
So then a single GPO is directed at the site 1 OU and inherited by all child
OU's? Still seems to beg the question as to why each group needs to be in
its own child-of-child OU. The only way I could understand this structure is
if the individuals who manage the CSR and HR groups are not one and the
same, and each group must be protected from the administrators of the other.
> (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
The whole *point* of groups is that, unlike OpenVMS, membership of users in
groups is not mutually exclusive. This is a better model of business
relationships, in which someone could be a finance officer, a supervisor, a
supervisee, a member of the company squash club, and anything else.
> (thus my
> predicament with mapping G: as the "group" directory), but they also
> sometimes travel from site 1 to site 2.
IMHO, and with deference to the MS resources you have quoted, I think you
have done this inside out. Defining first the structure, based on the
company org chart, and then trying to figure out what you need to do to it
to accommodate irregularities such as you mention.
I think it is easier to look first at the effects you are trying to achieve.
If there are twenty groups and each has a share that group members should
have mapped, you will most certainly go bonkers, as you will run out of
drive letters. Better in that case to have one drive mapped to one share,
and have a root folder in this share permitted exclusively to the
corresponding group of individuals. We currently have about forty such
"workgroup folders" all cohabiting one drive letter. The logon script is
simple: everyone gets the same mapping. The permissions are setup on the
folder at time of creation. Access is managed simply by changing group
membership as required. Note that I have simplified - you should read up on
the Microsoft strategy of putting users in global groups, global groups in
local groups, and permitting resources to the local groups.
> 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).
That is not how I understand it, however, GPO's are not my specialty. Our
GPO's basically put restrictions on computer objects in our OU's - I'm not
sure what kind of policies would apply to groups, or how that would affect
the members of the groups.
> 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).
Not so sure of the method, but I think I know the cause ;-)
When you say site 3 (you mean the people belonging to that site?) is only
allowed limited access to sites 1 & 2, what is the nature of the
restrictions that are placed on them? Are you speaking of rights, like being
able to logon to a server, or do you mean access to resources? If the
latter, a well-defined group management methodology should be all you will
ever need.
People coming to our site from others will have access to whatever resources
it is decided that they need. It does not matter what OU they are from, just
that they are not in our groups that give access to sensitive, site-specific
information. In fact, since I do not control the OU's that others come from,
I am poorly positioned to manage their access to/restriction from our
resources by managing their OU, because I cannot do that.
I think you may be missing the point somewhat because of your original
concept of group membership being mutually exclusive. Because it is not, it
is completely flexible - not like the OU structure hierarchy.
/Al
>
>
>
>
>
> "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
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
- Next message: Al Dunbar [MS-MVP]: "Re: Server-side modem connection"
- Previous message: name: "Re: Please help! How do I download a binary file from URL when link needs to be launched from inside browser after authentication?"
- In reply to: aptrsn: "Re: AD group logon script question"
- Next in thread: aptrsn: "Re: AD group logon script question"
- Reply: aptrsn: "Re: AD group logon script question"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
