creating lots and lots of gorups

  • Thread starter Thread starter m0rk
  • Start date Start date
M

m0rk

For reasons ive not fathomed our network admin has decreed a set
structure of groups for all file structures on the file systems.

It involves domain local groups being set on the folders with global
groups being added into the domain local groups and members only allowed
in the global groups.

It is going to mean a huge number of groups as there are 5 groups for
domain local and 5 global groups, 1 for each domain local ... and this
is per top level folder .... quite a few.

Anyway, is there a way to automatically create groups based on the
folder names?
 
m0rk said:
For reasons ive not fathomed our network admin has decreed a set
structure of groups for all file structures on the file systems.

It involves domain local groups being set on the folders with global
groups being added into the domain local groups and members only allowed
in the global groups.

It is going to mean a huge number of groups as there are 5 groups for
domain local and 5 global groups, 1 for each domain local ... and this
is per top level folder .... quite a few.

Anyway, is there a way to automatically create groups based on the
folder names?
Click to expand...

Your best strategy would be to script something using ADSI, or write a
program in .NET.
 
8?B?Sm9zZXBoIERhaWdsZQ==?= said:
Your best strategy would be to script something using ADSI, or write a
program in .NET.
Click to expand...

..... and being a script beginner, the only things ive used scripts for
before is logon and setting printers with kixtart scripts.

this is going to be painful isnt it ... !
 
m0rk said:
.... and being a script beginner, the only things ive used scripts for
before is logon and setting printers with kixtart scripts.

this is going to be painful isnt it ... !
Click to expand...

well, to help get you started, if you want to take the pure script
route, here is some code from a sample vbs script:

***code start***

Const ADS_GROUP_TYPE_GLOBAL_GROUP = &h2
Const ADS_GROUP_TYPE_SECURITY_ENABLED = &h80000000

Set objOU = GetObject("LDAP://ou=dev,dc=sreb,dc=org")
Set objGroup = objOU.Create("Group", "cn=HR-Employees")

objGroup.Put "sAMAccountName", "HRStaff"
objGroup.Put "groupType", ADS_GROUP_TYPE_GLOBAL_GROUP Or _
ADS_GROUP_TYPE_SECURITY_ENABLED
objGroup.SetInfo

***code end***

It simply creates a new security group in the given OU, and then sets
the sAMAccountName property, and enables it.

http://www.microsoft.com/technet/scriptcenter has TONS of resources for you.
 
Sounds like your admin went to a beginning admin class and they tried to explain
the old UGLy strategy, put users in globals and globals into locals and locals
get the permission.

Quite frankly in most cases that solution is illogical. It sounds like this is
one of them. If you have a single domain you can either use global or domain
local groups in the domain and apply the permissions directly to the resource.
If you have multiple domains you will actually need 5*(# of domains that users
are in) global groups to place in the domain local groups. So if you had 5
domains and you wanted user from all of the domains to have access you would
need 25 global + 5 domain local groups to accomplish this. Also administration
of membership is a nightmare when you go that way.

Just use domain local groups if doing resource based permissioning. If you are
doing role + resource based permissioning, create roles out of global groups and
still acl the file resources with domain local.

joe
 
Sounds like your admin went to a beginning admin class and they tried to explain
the old UGLy strategy, put users in globals and globals into locals and locals
get the permission.

Quite frankly in most cases that solution is illogical. It sounds like this is
one of them. If you have a single domain you can either use global or domain
local groups in the domain and apply the permissions directly to the resource.
If you have multiple domains you will actually need 5*(# of domains that users
are in) global groups to place in the domain local groups. So if you had 5
domains and you wanted user from all of the domains to have access you would
need 25 global + 5 domain local groups to accomplish this. Also administration
of membership is a nightmare when you go that way.

Just use domain local groups if doing resource based permissioning. If you are
doing role + resource based permissioning, create roles out of global groups and
still acl the file resources with domain local.

joe
Click to expand...

the DL's are related to folder name and the 5 groups are the permissions
given for that folder such as RO, RW, Modify, List & Deny ...a DL group
for each then a GG sitting in each one of those then the users put into
the GG's.

its nuts ... its not often a need to use more than a couple of those for
most sets of folders so seems a completely pointless task just to have
all the groups there.

we've already have to add a registry change before adding a machine to
the domain as we have so many bloody groups already there's not enough
storage without the registry change!
 
I like the idea of fixed groups for resource access and have done it in the past
but there is a limit to the ACLing done. Usually if you are ACLing more than 2
or 3 layers deep in a file structure, you are making one big overly complex mess.

A setup I used in a very large financial company (billions of dollars in trades
a week) looked like this


Home directories were ACLed to administrators (FC) and the user (Change).

There was one project share per project server (with preference to have a single
project server per site or collection of closely related sites). That project
share would have a directory for each project that needed a unique set of users.

Two local groups were created for every folder, SHR_FolderName_R and
SHR_FolderName. The first was read only and the second was change. If special
permissions beyond that were need (very rare) then the group would be created
with the _perms listed. Moving those up into a domain local group structure in a
domain you simply go to SHR_SRVNAME_FolderName_perm.

There was only one folder structure that actually had permissions assigned below
the top level, that was a WEB folder structure because it contained web sites
for each of the project groups and needed to be updated or read by different
people and would get uploaded to the production web servers nightly. With that
it was

ProjShare
proj1
proj2
proj3
proj4
proj5
projn
WEB
proj1
proj2
proj3
projn

Where Proj1-Projn are names appropriate for the project or anonymous names if
preferred.


There was a SHR_WEB_R group which everyone was added to so everyone could read
all subfolders. There was a SHR_WEB for the folks who managed the web structure
as a whole. Then there were SHR_WEB_PROJ1, SHR-WEB_PROJ2, etc groups for people
to be added to that needed to update specific project web sites.

The beauty of all of this is that if something happened to the permissions, it
could all be rebuilt easily with perl scripts that looked at the groups and
looked at the shares and could put them together and correct anything that
wasn't set properly. It was extremely logical, it didn't take people long to
work out how it was set up. Mostly... it was simple.
 
well, to help get you started, if you want to take the pure script
route, here is some code from a sample vbs script:

***code start***

Const ADS_GROUP_TYPE_GLOBAL_GROUP = &h2
Const ADS_GROUP_TYPE_SECURITY_ENABLED = &h80000000

Set objOU = GetObject("LDAP://ou=dev,dc=sreb,dc=org")
Set objGroup = objOU.Create("Group", "cn=HR-Employees")

objGroup.Put "sAMAccountName", "HRStaff"
objGroup.Put "groupType", ADS_GROUP_TYPE_GLOBAL_GROUP Or _
ADS_GROUP_TYPE_SECURITY_ENABLED
objGroup.SetInfo

***code end***

It simply creates a new security group in the given OU, and then sets
the sAMAccountName property, and enables it.

http://www.microsoft.com/technet/scriptcenter has TONS of resources for you.
Click to expand...

This seems the sort of thing that would be useful but to make it work
for me is it possible to use variables of some sort ... im thinking
maybe of a form that requests the folder name, once typed in it
automatically create the 5 * domain local groups and the 5 * global
groups I need ...

Or are there any tools already written for this? ... learning to script
from basics is going to take some time which is limited with current
workloads.
 
It simply creates a new security group in the given OU, and then sets
This seems the sort of thing that would be useful but to make it work
for me is it possible to use variables of some sort ... im thinking
maybe of a form that requests the folder name, once typed in it
automatically create the 5 * domain local groups and the 5 * global
groups I need ...

Or are there any tools already written for this? ... learning to script
from basics is going to take some time which is limited with current
workloads.
Click to expand...

Ive been looking at CSVDE ... seems i'll be able to export an example of
a few groups with the -m switch to get a usable import template and then
populate it with the names of the groups I need to create and import it
in ... sounds straight forward.

I dont need to populate the groups with users yet which is good as CSVDE
cant do this anyway so i'll have a test tomorrow.
 
Back
Top