Re: AD group logon script question

From: aptrsn (busn66_at_hotmail.com)
Date: 03/05/04 

Date: Fri, 05 Mar 2004 19:49:44 GMT

Thanks again Al for continuing this,

> What did he/she say?

He did ask about my purpose of creating so many OU's, but once I explained
the purpose of each OU he was supportive of the design.

> ... but here you seem to get carried away a little bit ...

Seem's to typical of much of what I get involved in ;-P

Since your last post I have experimented with a simpler AD structure and
found that with GPO filtering I can apply policies without having to have a
whole seperate OU for the group. This, in itself is/was part my perception
problem with understanding OU's.

> 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?

Yes, it's limiting the access (or denying altogather ) the people belonging
to a specific site, from another site's resources.

> If the latter, a well-defined group management
> methodology should be all you will ever need.

It's coming up with that "well-defined group management methodology" that I
seem to be having some difficulty with.

In my case, it's the not the access to resources, but determining based on
site that is throwing me for a loop. If a user is at Site 1, then I want
them to be mapped to the resources of that site (default printers, group
shares, etc.) If they are at Site 2 the next day, then I want them mapped to
the resources of Site 2. If they don't belong to a group at either site 1 or
2, the access to certain resources at either of those sites is denied
altogather (which is why I believe you are stressing the importance of group
membership).

I can see your point of having a single drive mapping for all groups, but is
there a way to define what site the user is logging in at so that it maps to
the 'group share' at that site? I have to deal with limited bandwidth
between sites so I prefer that all mapped resources remain on the LAN where
they are attached. Our replication is going to be scheduled for only
specific times of the day to prevent network congestion.

Again, thanks for your insights, much of the "madness" that I was struggling
with has now been resolved.

"Al Dunbar [MS-MVP]" <alan-no-drub-spam@hotmail.com> wrote in message
news:eR9I5BoAEHA.212@TK2MSFTNGP12.phx.gbl...
>
> "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
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Relevant Pages

  • Re: AD group logon script question
    ... like I described our logon script: ... If individuals need special access to certain resources, ... and each group must be protected from the administrators of the other. ... membership as required. ...
    (microsoft.public.scripting.vbscript)
  • Re: Use login control to limit access to certain pages
    ... Membership Database to store your users and want unauthenticated users to ... The resources are scattered as you said, ... I want to confirm which authentication type you are using? ... without validation when request path is in this XML file. ...
    (microsoft.public.dotnet.general)
  • Re: User account without login right?
    ... Membership in "Domain Users" is not required to logon to the domain. ... The access of all the resources in domain depends on the ACL setting of ... I have some user accounts ...
    (microsoft.public.windows.server.active_directory)
  • Re: semi-pro ultimate long term planning: Cities
    ... ok so you tell me......whats the proper formula for when the ... upa put resources towards ANY program that its membership favors. ...
    (rec.sport.disc)
  • Re: NASAs vision lost on Web generation
    ... Your great concern for the taxpayers is noted. ... Wasting resources doesn't contribute to the greater good. ... contributed to resourced management. ... the books to make the case for shuttle. ...
    (sci.space.shuttle)