RE: [ActiveDir] OT: File Server Permissions Design Question
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
MulnickSent: Friday, October 13, 2006 4:36 PMTo:
ActiveDir@mail.activedir.orgSubject: 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, GuidoSent: Thursday, October 12, 2006 11:04
PMTo: ActiveDir@mail.activedir.orgSubject:
RE: [ActiveDir] OT: File Server Permissions Design QuestionABE 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 EvansSent: Thursday, October 12, 2006 1:20
AMTo: ActiveDir@mail.activedir.orgSubject:
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 ParrisSent: Wednesday, October 11, 2006 2:38
PMTo: ActiveDir.orgSubject: Re: [ActiveDir] OT: File Server
Permissions Design QuestionHave you looked at installing the Access
based Enumeration feature pack and basing the permissioning on this type of
model? Assuming W2003.Regards,Mark
ParrisBase IT LtdActive Directory ConsultancyTel +44(0)7801
690596-Original Message-From: "Steve Evans" [EMAIL PROTECTED]Date: Wed,
11 Oct 2006 12:57:52To:ActiveDir@mail.activedir.orgSubject:
[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 fold
Re: [ActiveDir] OT: File Server Permissions Design Question
The amusing part is the disparity of information. For example, if I look at the kerb troubleshooting docs, it recommends a maximum group depth of 70-120 but that's more focused on the PAC size. That's a far cry from the 1000 in that article (if memory serves Dean had a lot to say about that in a previous email as did you). But in practice, if you're a member of 1000 groups, it might be time to re-evaluate your security concepts. Unless you're joe in which case you'll say you've seen thatand done thatand it's nothing ;) If I recall correctly, this is a different issue than the token bloat issue isn't it? The question becomes which will you hit first? You *could* use a registry key (maxtokensize) to expand the buffer for the pac on every workstation, but I don't recall what the impact was of doing that or why it is what it is by default. I recall there is a performance hit on the DC's for large amounts of group membership processing, but can't recall the client side impact. Anyone? On 10/14/06, Laura A. Robinson [EMAIL PROTECTED] wrote: David's response came in blank, so I'm hopping on your reply to him, Al. A small point, but I wouldn't exactly say the token size limitation is by design so much as by limitation This is why: http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B328889 I don't know why that other KB article specifies 1000 SIDs, but as you can see, the article hasn't been reviewed since 2004, so maybe we should get that fixed. :-) Laura From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Al MulnickSent: Friday, October 13, 2006 4:36 PMTo: 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 PMTo: ActiveDir@mail.activedir.orgSubject: 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 EvansSent: Thursday, October 12, 2006 1:20 AM To: ActiveDir@mail.activedir.orgSubject: 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 ParrisSent: Wednesday, October 11, 2006 2:38 PM To: ActiveDir.orgSubject: Re: [ActiveDir] OT: File Server Permissions Design QuestionHave you looked at installing the Access based Enumeration feature pack and basing
Re: [ActiveDir] OT: File Server Permissions Design Question
Mmm- I didn't read the question properly. Sorry. Mark Mark Parris Base IT Ltd Active Directory Consultancy Tel +44(0)7801 690596 -Original Message- From: Grillenmeier, Guido [EMAIL PROTECTED] Date: Thu, 12 Oct 2006 23:04:17 To:ActiveDir@mail.activedir.org 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
Re: [ActiveDir] OT: File Server Permissions Design Question
As someone who's currently battling token size issues (migration and legacy issues), I can vouch for that approach as well. There really is no great single method that will fit everyone unfortunately. One thing that seems a pretty good idea is to ensure that resources are acl'd for the largest common group. For example, your \\server\share portion might be open to everyone for access at the share and ntfs level (don't forget about that part) and then more narrowly focused by group and then sub-group and so on until it no longer makes sense. The common variable that seems to give the best indication of success is the planning. The more you do up front the better you'll be down the road. Oh, and be sure to keep it from being any more complex than it absolutely needs to be. The more complexity you introduce ( i.e. too many groups) the more likely it will be circumvented by someone that doesn't understand it fully. My $0.04 worth. On 10/12/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: 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 EvansSent: Thursday, October 12, 2006 1:20 AMTo: ActiveDir@mail.activedir.orgSubject: 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 ParrisSent: Wednesday, October 11, 2006 2:38 PMTo: ActiveDir.orgSubject: Re: [ActiveDir] OT: File Server Permissions Design QuestionHave you looked at installing the Access based Enumeration feature pack and basing the permissioning on this type of model? Assuming W2003.Regards,Mark ParrisBase IT LtdActive Directory ConsultancyTel +44(0)7801 690596-Original Message-From: Steve Evans [EMAIL PROTECTED]Date: Wed, 11 Oct 2006 12:57:52To:ActiveDir@mail.activedir.orgSubject: [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 folderOur 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 ina 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 EvansList info : http://www.activedir.org/List.aspxList FAQ: http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx[EMAIL PROTECTED]ËŠËE¬§â²Ö«r¯zm§ÿðÃœ¶+Þv*èæ—ûa汫) List info : http://www.activedir.org/List.aspxList FAQ: http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspxList info : http://www.activedir.org/List.aspxList FAQ: http://www.activedir.org/ListFAQ.aspxList archive: http
RE: [ActiveDir] OT: File Server Permissions Design Question
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
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, GuidoSent: Thursday, October 12, 2006 11:04 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OT: File Server Permissions Design QuestionABE 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 EvansSent: Thursday, October 12, 2006 1:20 AMTo: ActiveDir@mail.activedir.orgSubject: 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 ParrisSent: Wednesday, October 11, 2006 2:38 PMTo: ActiveDir.orgSubject: Re: [ActiveDir] OT: File Server Permissions Design QuestionHave you looked at installing the Access based Enumeration feature pack and basing the permissioning on this type of model? Assuming W2003.Regards,Mark ParrisBase IT LtdActive Directory ConsultancyTel +44(0)7801 690596-Original Message-From: Steve Evans [EMAIL PROTECTED]Date: Wed, 11 Oct 2006 12:57:52To:ActiveDir@mail.activedir.orgSubject: [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 folderOur 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 ina 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 EvansList info : http://www.activedir.org
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
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])
