Whoops, I forgot to also add that because local group SIDs count towards the limit, you will not experience "can't log on, period". Rather, you may be able to log on to machines that aren't adding enough local group SIDs to your access token to exceed the ~1015 group limit if you are a member of less than 1015 AD groups. For example, if your token had the 9 base SIDs plus 1000 domain local/global/universal group SIDs, you would be able to log on successfully to any machine that didn't add more than 15 local groups to your token.
 
Laura


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick
Sent: Friday, October 13, 2006 4:36 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] OT: File Server Permissions Design Question

Good point but not always the case, for what it's worth.  The problem can also manifest itself as not able to logon to some (random) resources as well.  Very tricky when in that state. Topology and architecture make a big difference here as well.
 
There's also some tools such as ntdsutil (Brett?)(newer version has some help in there) that help with this as does tokensz if you're patient. There's also an entire document dedicated to discussing the troubleshooting of kerberos authentication problems if you need it.
 
But for my money, this is a problem better handled through avoidance because once the toothpaste is out of the tube.......
 
-ajm


 
On 10/13/06, McClure, David (MED US) <[EMAIL PROTECTED]> wrote:

The magic number (ie, the number of unique SIDs that a token can hold) is limited to 1000 by design ( http://support.microsoft.com/kb/275266/).  Once you get above 1000, you can't logon at all, period.  The best way I can think of to evaluate the complexity and nesting of your group structure is to experiment in a lab using " mytoken.exe", which is downloadable from the MS site.  When logged on, run mytoken to count and list the unique SIDs.  Find the right balance through trial-n-error.


-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Grillenmeier, Guido
Sent: Thursday, October 12, 2006 11:04 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] OT: File Server Permissions Design Question

ABE won't necessarily reduce the number of groups you need to control access, although it certainly controls the visibility for those that don't have any rights to specific data in your shares.

Your approach is a very common approach and certainly nothing unusual. Not sure how you get from 15 departments to 60 groups (a more concrete sample of your group structure would help understand). But whatever it is, a user will likely be a member of quite a few groups either directly or through nesting - I wouldn't worry too much about the number of groups you create (if they have good structure that makes sense), but more about the number of groups a user will have to be a member of.

At some point you have to think about the kerb token size the users will get at logon and if that is going to cause issues. You can obviously influence this by choosing to create some of your groups locally on the FS, but this has it's own downsides.

/Guido

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Steve Evans
Sent: Thursday, October 12, 2006 1:20 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] OT: File Server Permissions Design Question

We're actually using ABE (or will be once we start migrating to this box).  It helped me a ton with a couple situations (home folders being the big one because of something called FERPA, if you don't know what it is you don't ever want to know).  However I don't see how that helps me here specifically.


Steve Evans

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Mark Parris
Sent: Wednesday, October 11, 2006 2:38 PM
To: ActiveDir.org
Subject: Re: [ActiveDir] OT: File Server Permissions Design Question

Have you looked at installing the Access based Enumeration feature pack and basing the permissioning on this type of model?

Assuming W2003.

Regards,




Mark Parris

Base IT Ltd
Active Directory Consultancy
Tel +44(0)7801 690596


-----Original Message-----
From: "Steve Evans" < [EMAIL PROTECTED]>
Date: Wed, 11 Oct 2006 12:57:52
To:<ActiveDir@mail.activedir.org>
Subject: [ActiveDir] OT: File Server Permissions Design Question

I've had difficulty finding a better forum in which to ask this.  And since it involves AD Security Groups I thought I could get away with it.


We're in the process of migrating to a new file server.  Our shared drive has a basic structure of:

Shared\Department\Sub-Department\<one public folder & one private folder>

Our original thought was to have one Read and one Read/Write group for each public and private folder.  Those groups would then be populated by role based groups (department groups, position groups (ex all management)).  I've

written a script that you can point to a directory structure and it creates the appropriate groups and assigns the security permissions.

However I end up creating a lot of groups.  Just in ITS (for example) we have 15 sub-departments so that will produce 60 groups right there.  On the other hand everything is very structured and in theory you can mange file security permissions from within AD.  Since everything is scripted you never

need to go and look at folder permissions (except for the file server admin guys when troubleshooting).

I'm also concerned that users will end up being in groups that are nested in

a substantial number of groups.  For instance most of the public-read groups for ITS will contain the group "ITS - All Staff".  That means any given ITS employee will have 30 security group tokens just from this.


Any thoughts or opinions?

Steve Evans

List info   : http://www.activedir.org/List.aspx
List FAQ    : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx

[EMAIL PROTECTED]­æ±«)

List info   : http://www.activedir.org/List.aspx
List FAQ    : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
List info   : http://www.activedir.org/List.aspx
List FAQ    : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx

-------------------------------------------------------------------------------
This message and any included attachments are from Siemens Medical Solutions
USA, Inc. and are intended only for the addressee(s).
The information contained herein may include trade secrets or privileged or
otherwise confidential information.  Unauthorized review, forwarding, printing,
copying, distributing, or using such information is strictly prohibited and may
be unlawful.  If you received this message in error, or have reason to believe
you are not authorized to receive it, please promptly delete this message and
notify the sender by e-mail with a copy to [EMAIL PROTECTED]

Thank you

Reply via email to