[Pc_Support] Nested group security in Active Directory (Win2000)?

[Bryan J. Smith]

Damien McKenna <dmckenna at thelimucompany.com> wrote:
> We've got an Active Directory setup on a Windows 2000
> network.  We've got custom OUs for managing the directory
> structure.  I've tried adding some new security groups that
> in terms of the organization structure of the company are
> the superior of the next one, e.g. customer service
> manager is the parent of the customer service supervisors,
> etc.  I've got e.g. the Supervisor object and I've tried
> adding it to the Manager's "members" list but absolutely
> no user groups are shown!  Is there a flag set wrong
> somewhere to not allow me do this, or is it a limitation
> of Windows 2000?  Thanks.

Are you talking a "parent OU" or something else?

I guess what I'm trying to figure out is if you are trying to
delegate authority over an _ADS_ subtree to a user, or merely
add a user to a group so they can manage files in a
NTFS/share subtree?

If the former, you delegate authority using the appropriate
Wizard.  If the latter, you setup Domain Local groups on the
NTFS/share subtree, and then assign Users to Global groups
which are assigned to Domain Local groups.

Damien McKenna <dmckenna at thelimucompany.com> wrote:
> OK, to solve my own problem, to do this the group has to be
> created as a "domain local" group and not a "global"
> group.  Sure, that makes sense :-\

Hold on, if you don't know the difference between "Domain
Local" and "Global" groups, you should read up on them.

1.  Users should _always_ be placed in Global groups
2.  Domain Local groups should be applied to service objects
(e.g., share, filesystem, etc...)
3.  Global groups should then be assigned to Domain Local

In other words:
1.  _Never_ assign Global groups to service objects (e.g.,
share, filesystem, etc...)
2.  _Avoid_ assigning Users to Domain Local groups

Microsoft's official line revolves around the fact that
people used different "resource" and "user" groups back in
the CIFS days so you could assign access to a local domain
object for another domain's users/groups.  In reality, this
is a limitation when you have multiple domains, which "Domain
Local" now solves nicely.

Technical insight:

Domain Local group ensures SIDs are always _local_ to the
server -- i.e., the SIDs on ACL of shares/files of a NTFS
volume are _local_ domain SIDs.  If not, NTFS can be
corrupted because of its _flawed_ design (which is why
CairoFS, now WinFS, is still very much needed, even if still
quite vaporware).  That's why you _always_ assign Domain
Local groups of the local domain to the service resources of
servers local to that domain.  They you assign Global groups,
which could be from any domain, to that Domain Local group.

Again, _avoid_ directly assigning Global groups directly to
service resources such as shares and files.


-- 
Bryan J. Smith                | Sent from Yahoo Mail
mailto:b.j.smith at ieee.org     |  (please excuse any
http://thebs413.blogspot.com/ |   missing headers)