Re: AD group logon script question
From: Al Dunbar [MS-MVP] (alan-no-drub-spam_at_hotmail.com)
Date: 03/06/04
- Next message: Al Dunbar [MS-MVP]: "Re: Server-side modem connection"
- Previous message: McKirahan: "Re: Send email attachment"
- In reply to: aptrsn: "Re: AD group logon script question"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 5 Mar 2004 20:51:02 -0700
"aptrsn" <busn66@hotmail.com> wrote in message
news:sR42c.183647$jk2.667276@attbi_s53...
> 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.
Ahh, contractors, the perpetual yes-men... ;-)
> > ... 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.
I'm certainly glad that you found out about GPO filtering, because, as I
have said a few times, GPO's are not my bag.
> > 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.
I thought that, initially, your problem was getting an OU structure that met
your needs ;-) But, be that as it may, I believe that group management is
where it's at for this stuff - read on...
> 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).
Torgeir provides some good clues about determining the site the user is
logging on at through enquiring workstation affiliation of the active
directory. When we first implemented an NT4 domain, we did much the same by
including a short snippet of (kixtart) script that, when run by the logon
script, returned the name of the site and of the local server. We have since
converted the script to WSH, and now limit the information stored on the
local hard drive to defining only the site. Finding out the name of the
local server now requires a look at a file on the domain controller
corresponding to the site. Makes server replacement a lot easier! Not as
elegant as deducing all from active directory, but, it works for us, and is
manageable.
> 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.
When anyone from anywhere logs in at any of our sites, they get all of the
standard mappings of that site, most of which are on the local server (three
exceptions: user home folder, a "regional" workgroup share on the regional
server, and optionally a "national" workgroup share on a national server).
This will include organization-wide applications, but also site-specific
workgroup-related data. The guest will not have access to, for example, the
folder owned by the local finance department, but that is OK as they have no
need of it. While away from home, the user has no automatic mapping to the
workgroup share at his home site, but if absolutely necessary, he can map to
it as needed.
This is all done in the context of a single GPO, a single (but
location-sensitive) logon script, and a group structure whose maintenance is
delegated to the IT group at each site. I manage my groups in a manner quite
different from that of some of my counterparts, yet to the roving user, the
effect is the same.
I think the problem you are having stems from thinking of the logon script
as being specific to the user rather than to the workstation. Granted they
are both - you just need to consider which is their first allegiance.
> Again, thanks for your insights, much of the "madness" that I was
struggling
> with has now been resolved.
You are most welcome - as is knowing that this dialogue has helped you work
out these problems.
<verbosity alert - those not interested, stop now...>
Further to your concerns about developing an effective approach to group
management, I suggest you do a few google searches (web and newsgroups) for
things like "users in local groups". While there may be no absolute best
methodology that suits all possible environments, there are a few general
principles worth keeping in mind that are common to those practices that are
generally better than the all-too common helter-skelter approach. Our
current approach goes along these lines:
- Each resource needing permissions different from its parent has a local
group created for each possible type of permission, typically read and
change in most cases. Once these "resource permission groups" are created
and permitted to the resource, ALL subsequent access changes are made ONLY
by changing group memberships, NOT by modifying permissions on the resource.
It is as if the access controls inherent in NTFS permissions have been
"patched" to an equivalent set of controls that happen to be housed within
MMC - ADU&C, rather than windows explorer - kind of a wireless remote
control, as access rights can be changed even when the server housing the
resource is unavailable.
- These permission groups have a one-to-one relationship to the
corresponding resource/access type, having names that are suggestive of the
resource and a suffix of -W or -R to indicate the access type. As such these
groups are each permitted to only their corresponding resource, they contain
only global groups (not individual users), and they are not members of any
other groups.
- Users are added to global groups, in as generic a manner as possible (i.e.
not specific to resource access requirements - that comes later). There are
groups representing, say, all members of a department or a division (the
division group would likely contain only the individual departmental groups,
not individual accounts), or a committee (which could be cross-departmental,
and might contain individual users plus other groups), and so on. The
purpose of such groups is to aggregate users along functional lines.
- In between the "user aggregate" groups and the "resource permission"
groups we have groups that link the two together so that actual users
finally get the access they need to the resources. Even this layer is made
generic, so you might have a group called "App users - XYZ", which would
represent everyone authorized to use application XYZ. This group might
contain some individual users plus some groups, for example a financial app
needed by all staff of the finance department plus budget managers of all
other departments plus two auditors. It would be a member of a number of a
number of resource permission groups, for example the "XYZ application
program-R" group and the "XYZ application data-W" group. By assigning a user
to either the finance department group or the budget manager group or
directly to the "app users - XYZ" group, that user will be given the
appropriate access to any and all resources required by that application.
The beauty of this is that this application/resource dependency is
determined once, and the account/group administrator need not even remember
the details to give someone access to the application.
This approach may seem complicated, but the complexity is managed through
its logical structure, which can be adapted to model the functional
relationships of an organization with a quirky structure. This method tends
to result in a larger number of groups than the helter skelter method, but
this is offset by its two advantages:
- while there is a large number of groups, the number of individual group
memberships that need to be managed for the average user is actually
relatively small. Note that, after the initial configuration of the group
hierarchy it will remain relatively stable, whereas user access requirements
change constantly.
- it can usually be adapted to changes in functional relationships and
organizational structure by (carefully) adding new groups, typically without
having to make significant changes to the existing group membership
hierarchy. Even when structural changes become necessary, they are easy to
make because none of the groups serve multiple purposes. For example, if the
members of the chess club just happen to all be in the finance department,
and you decide this only needs one group, then a new club member from the
personnel department will have access to financial information. This can be
fixed, of course, but it requires changing permissions on the resource.
Pop quiz: suppose that that XYZ application needed to give a higher level of
access to those individuals providing application support, what changes
would be required?
ans:
- create a resource permission group called "XYZ application program-W"
- permit the resource containing the application code write to this group
- create a group called "app support - xyz"
- populate it with the individuals and/or groups of individuals that do the
support
- add it as a member of the "XYZ application program-F" group and of the
"App users -XYZ" group.
I will excuse my own verbosity on the subject because I remember looking for
this information myself a while ago...
/Al
<snip - for sanity' sake>
- Next message: Al Dunbar [MS-MVP]: "Re: Server-side modem connection"
- Previous message: McKirahan: "Re: Send email attachment"
- In reply to: aptrsn: "Re: AD group logon script question"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
