Re: [ActiveDir] Security-enable all your distribution lists?
Even with smaller organizations, are the IT people the ones who should be saying who needs to have access to the CFOs information or should it be the CFO? Just to be honest, there are a lot of areas within a company that the IT people aren't qualified enough to even hazard a guess as to who should and shouldn't have access to. Couldn't agree more. My opinion is that IT should NEVER manage group memberships. In that same sphere of thought, I think that users should not either. My reasoning is control. Not control in the sense that I want to dictate everything you do and micromanage. Far from it. That's not what I get paid for and I think it's degrading to want to do that to people. I am referring to control as in process controls. There should be a process control for every group modification if security is to be taken seriously. Does that mean it'll be perfect? No. does that exclude self-service? No. But it does mean that every change needs to be logged and a sanity check or some similar business logic check needs to be applied to the process. Having your IT security folks control the group administration is the same as controlling badge access in my mind. In a regulated environment, the detail is a necessary control and to me, it belongs to the information security people. My job ends when I empower them to do their job (even if that means to empower the end users that do the actual work; just that it's not my process.) AlOn 11/7/06, Matt Hargraves [EMAIL PROTECTED] wrote: I can understand your arguments, but the larger the organization, the more likelihood that the groups are controlled by users (in one way or another) anyway. When you've got 100k groups, you have someone listed as a group owner or someone authorized to approve new members of the group and the only people who even know what the group is for are either members of that group or in the direct management chain - definitely not the IT people who 'manage' the groups. Even with smaller organizations, are the IT people the ones who should be saying who needs to have access to the CFOs information or should it be the CFO? Just to be honest, there are a lot of areas within a company that the IT people aren't qualified enough to even hazard a guess as to who should and shouldn't have access to. I think that the biggest difference between security-enabling distribution lists and enabling mail on security lists is the way that users think of them. The same people are managing them and if they're going to screw up their security in a DL, they're probably going to screw it up by rubber-stamp approvals too. The Security groups that you enable mail on aren't going to be big mail usage lists and the distribution lists aren't going to be used 90% of the time for security. Personally, I'd rather keep mail/security hybrids to the RBS groups and avoid it for the ABS (access/task-based security) groups. If someone wants to enable his/her ABS group for mail though, I'm not one to say what they can/can't do with their group/data. This way, your RBS groups have a built-in e-mail group to communicate with, but the mail/security overlap isn't so extreme that your company's security is a nightmarish web of DL/security groups. One important thing though, your privileged groups that grant special access to servers should always be managed by the IT persons, never let them turn into a mail-enabled security group. On 11/7/06, Al Mulnick [EMAIL PROTECTED] wrote: You do make a strong argument, but I'm not sold. The part I can't get past is that the users have the control over adding a sec-prin to be able to pull the data. Vs. pushing the protected data via email. The subtlety is important in my opinion. The only issue I have with the convenience of adding users to sec-enabled-dg's is the lack of controls to prevent the mis-use (either intentional or unintentional). Outside of that, I'm all for the concept. :) On 11/7/06, Matt Hargraves [EMAIL PROTECTED] wrote: I don't usually think of these as security-enabled distribution lists, but as mail-enabled security groups that users can manage in the same manner as they do distribution lists. When you think of them that way, it's not quite so painfully stupid. Don't get me wrong, turning all your DLs into security-enabled DLs and then sticking resources in them isn't exactly what I'd call brilliant, as Al alluded to - just because you're turning some of your DLs into security groups doesn't mean that you should do it with all of them. Hell, I'd argue that you shouldn't do it with any of them - that you should do it the other way around, mail-enable a small portion of your security groups and have the users pick which ones while reminding them that they are still *Security* groups and they need to manage their memberships with the same diligence they did before (yeah, yeah, I know - they didn't really take that good of care of them before). If you make sure that the DLs that stay DLs have something in the name that
Re: [ActiveDir] Security-enable all your distribution lists?
I don't usually think of these as security-enabled distribution lists, but as mail-enabled security groups that users can manage in the same manner as they do distribution lists. When you think of them that way, it's not quite so painfully stupid. Don't get me wrong, turning all your DLs into security-enabled DLs and then sticking resources in them isn't exactly what I'd call brilliant, as Al alluded to - just because you're turning some of your DLs into security groups doesn't mean that you should do it with all of them. Hell, I'd argue that you shouldn't do it with any of them - that you should do it the other way around, mail-enable a small portion of your security groups and have the users pick which ones while reminding them that they are still *Security* groups and they need to manage their memberships with the same diligence they did before (yeah, yeah, I know - they didn't really take that good of care of them before). If you make sure that the DLs that stay DLs have something in the name that designate them as a DL, it will make it easier. That being said, data on a share is no less sensitive than data in an e-mail. Companies lose secrets in e-mails, get sued because of what has been said in an e-mail. The fact that the majority of us sit here going NO!! NOT MY SECURITY GROUPS!!! DON'T LET THEM HAVE SECURITY GROUPS tells me that, regardless of the fact that 99% of all leaks occur through e-mail, we still don't 'get it' that e-mail is where most of this information sneaks between the cracks and it's not the 'grunts' that have the patent-holding information, it's the higher-up muckity mucks that are leaking data (SEC sensitive information most of the time). But to summarize - I'd recommend that you don't change the role of your DLs, but change the role of your security groups to fulfill this new need. Then you're not granting access to data based upon pre-existing groups that don't have access to data, you're simply allowing groups that already have access to data to fulfill an additional task. Mail exclusive DLs serve a number of purposes, one of them being to keep the higher-up muckity mucks out of the data that there is a *very* good chance that they don't understand anyway, but still allow them to be 'in the loop' on information that they do understand (well, kinda anyway). On 10/27/06, Al Mulnick [EMAIL PROTECTED] wrote: Assume. Hmm.. That's been over done so I'll pass this time :)Harvey, I just replied to a similar thread on this with my thoughts. I won't bore you with repetition. But I'm curious what makes you want to assume anything when it comes to security issues like this? I think it's way to unpredictable to assume that users will understand that concept. That's me though. I'm not your user. On 10/27/06, Harvey Kamangwitz [EMAIL PROTECTED] wrote:Thanks for the doc, Jorge; I'd missed that in my searches. And my initial reaction was not only no, but hell no! to the request. But when I examine it logically it's harder to reject out of hand. A little while ago, we did change the default for new DL group requests to be security enabled. And it seems to me that one would implicitly assume that if one were setting access to a resource like sharepoint, they would use the same thought process as when they're sending mail: Do I want everyone in this group to get this mail | have this access? - Harvey On 10/21/06, Al Mulnick [EMAIL PROTECTED] wrote: My first reaction is, NOOO don't do that. That's silly. I absolutely abhor the concept of convenience to this level when it comes to access to secured resources. Saying that, DG's are often created by default as a security group. I'd actually be surprised, and I would applaud the person that made that choice in your organization. From my perspective, the worst thing ever done by Microsoft was to allow DG's to be security groups. Made it easier to transition PF's sure, but the layer8 contingent doesn't understand the subtle differences between a distribution list and a security-enabled-distribution-group. This loosely translates into people that want to include somebody on their regular mail lists, but don't want them to necessarily have access to the same data shares. They do NOT understand the difference in most cases. I don't know sharepoint well enough to say, but I would be completely floored if they did not have a way to revert behavior. I also would be totally surprised if your information security people were OK with this concept for the reasons I mentioned above. TokenBloat is not the only concern you have here, Harvey. On 10/20/06, Harvey Kamangwitz [EMAIL PROTECTED] wrote: Hi all, I'm interested in your opinion here, and perhaps a heads-up on requirements that may be coming your way. We have a request from the sharepoint team to security-enable all of our 18,000 distribution lists. Our concern, naturally, is token size. What will this do to Joe User's access token? The issue is tied in to Sharepoint.
Re: [ActiveDir] Security-enable all your distribution lists?
You do make a strong argument, but I'm not sold. The part I can't get past is that the users have the control over adding a sec-prin to be able to pull the data. Vs. pushing the protected data via email. The subtlety is important in my opinion. The only issue I have with the convenience of adding users to sec-enabled-dg's is the lack of controls to prevent the mis-use (either intentional or unintentional). Outside of that, I'm all for the concept. :) On 11/7/06, Matt Hargraves [EMAIL PROTECTED] wrote: I don't usually think of these as security-enabled distribution lists, but as mail-enabled security groups that users can manage in the same manner as they do distribution lists. When you think of them that way, it's not quite so painfully stupid. Don't get me wrong, turning all your DLs into security-enabled DLs and then sticking resources in them isn't exactly what I'd call brilliant, as Al alluded to - just because you're turning some of your DLs into security groups doesn't mean that you should do it with all of them. Hell, I'd argue that you shouldn't do it with any of them - that you should do it the other way around, mail-enable a small portion of your security groups and have the users pick which ones while reminding them that they are still *Security* groups and they need to manage their memberships with the same diligence they did before (yeah, yeah, I know - they didn't really take that good of care of them before). If you make sure that the DLs that stay DLs have something in the name that designate them as a DL, it will make it easier. That being said, data on a share is no less sensitive than data in an e-mail. Companies lose secrets in e-mails, get sued because of what has been said in an e-mail. The fact that the majority of us sit here going NO!! NOT MY SECURITY GROUPS!!! DON'T LET THEM HAVE SECURITY GROUPS tells me that, regardless of the fact that 99% of all leaks occur through e-mail, we still don't 'get it' that e-mail is where most of this information sneaks between the cracks and it's not the 'grunts' that have the patent-holding information, it's the higher-up muckity mucks that are leaking data (SEC sensitive information most of the time). But to summarize - I'd recommend that you don't change the role of your DLs, but change the role of your security groups to fulfill this new need. Then you're not granting access to data based upon pre-existing groups that don't have access to data, you're simply allowing groups that already have access to data to fulfill an additional task. Mail exclusive DLs serve a number of purposes, one of them being to keep the higher-up muckity mucks out of the data that there is a *very* good chance that they don't understand anyway, but still allow them to be 'in the loop' on information that they do understand (well, kinda anyway). On 10/27/06, Al Mulnick [EMAIL PROTECTED] wrote: Assume. Hmm.. That's been over done so I'll pass this time :)Harvey, I just replied to a similar thread on this with my thoughts. I won't bore you with repetition. But I'm curious what makes you want to assume anything when it comes to security issues like this? I think it's way to unpredictable to assume that users will understand that concept. That's me though. I'm not your user. On 10/27/06, Harvey Kamangwitz [EMAIL PROTECTED] wrote:Thanks for the doc, Jorge; I'd missed that in my searches. And my initial reaction was not only no, but hell no! to the request. But when I examine it logically it's harder to reject out of hand. A little while ago, we did change the default for new DL group requests to be security enabled. And it seems to me that one would implicitly assume that if one were setting access to a resource like sharepoint, they would use the same thought process as when they're sending mail: Do I want everyone in this group to get this mail | have this access? - Harvey On 10/21/06, Al Mulnick [EMAIL PROTECTED] wrote: My first reaction is, NOOO don't do that. That's silly. I absolutely abhor the concept of convenience to this level when it comes to access to secured resources. Saying that, DG's are often created by default as a security group. I'd actually be surprised, and I would applaud the person that made that choice in your organization. From my perspective, the worst thing ever done by Microsoft was to allow DG's to be security groups. Made it easier to transition PF's sure, but the layer8 contingent doesn't understand the subtle differences between a distribution list and a security-enabled-distribution-group. This loosely translates into people that want to include somebody on their regular mail lists, but don't want them to necessarily have access to the same data shares. They do NOT understand the difference in most cases. I don't know sharepoint well enough to say, but I would be completely floored if they did not have a way to revert behavior. I also would be totally surprised if your information security people were OK
Re: [ActiveDir] Security-enable all your distribution lists?
I can understand your arguments, but the larger the organization, the more likelihood that the groups are controlled by users (in one way or another) anyway. When you've got 100k groups, you have someone listed as a group owner or someone authorized to approve new members of the group and the only people who even know what the group is for are either members of that group or in the direct management chain - definitely not the IT people who 'manage' the groups. Even with smaller organizations, are the IT people the ones who should be saying who needs to have access to the CFOs information or should it be the CFO? Just to be honest, there are a lot of areas within a company that the IT people aren't qualified enough to even hazard a guess as to who should and shouldn't have access to. I think that the biggest difference between security-enabling distribution lists and enabling mail on security lists is the way that users think of them. The same people are managing them and if they're going to screw up their security in a DL, they're probably going to screw it up by rubber-stamp approvals too. The Security groups that you enable mail on aren't going to be big mail usage lists and the distribution lists aren't going to be used 90% of the time for security. Personally, I'd rather keep mail/security hybrids to the RBS groups and avoid it for the ABS (access/task-based security) groups. If someone wants to enable his/her ABS group for mail though, I'm not one to say what they can/can't do with their group/data. This way, your RBS groups have a built-in e-mail group to communicate with, but the mail/security overlap isn't so extreme that your company's security is a nightmarish web of DL/security groups. One important thing though, your privileged groups that grant special access to servers should always be managed by the IT persons, never let them turn into a mail-enabled security group. On 11/7/06, Al Mulnick [EMAIL PROTECTED] wrote: You do make a strong argument, but I'm not sold. The part I can't get past is that the users have the control over adding a sec-prin to be able to pull the data. Vs. pushing the protected data via email. The subtlety is important in my opinion. The only issue I have with the convenience of adding users to sec-enabled-dg's is the lack of controls to prevent the mis-use (either intentional or unintentional). Outside of that, I'm all for the concept. :) On 11/7/06, Matt Hargraves [EMAIL PROTECTED] wrote: I don't usually think of these as security-enabled distribution lists, but as mail-enabled security groups that users can manage in the same manner as they do distribution lists. When you think of them that way, it's not quite so painfully stupid. Don't get me wrong, turning all your DLs into security-enabled DLs and then sticking resources in them isn't exactly what I'd call brilliant, as Al alluded to - just because you're turning some of your DLs into security groups doesn't mean that you should do it with all of them. Hell, I'd argue that you shouldn't do it with any of them - that you should do it the other way around, mail-enable a small portion of your security groups and have the users pick which ones while reminding them that they are still *Security* groups and they need to manage their memberships with the same diligence they did before (yeah, yeah, I know - they didn't really take that good of care of them before). If you make sure that the DLs that stay DLs have something in the name that designate them as a DL, it will make it easier. That being said, data on a share is no less sensitive than data in an e-mail. Companies lose secrets in e-mails, get sued because of what has been said in an e-mail. The fact that the majority of us sit here going NO!! NOT MY SECURITY GROUPS!!! DON'T LET THEM HAVE SECURITY GROUPS tells me that, regardless of the fact that 99% of all leaks occur through e-mail, we still don't 'get it' that e-mail is where most of this information sneaks between the cracks and it's not the 'grunts' that have the patent-holding information, it's the higher-up muckity mucks that are leaking data (SEC sensitive information most of the time). But to summarize - I'd recommend that you don't change the role of your DLs, but change the role of your security groups to fulfill this new need. Then you're not granting access to data based upon pre-existing groups that don't have access to data, you're simply allowing groups that already have access to data to fulfill an additional task. Mail exclusive DLs serve a number of purposes, one of them being to keep the higher-up muckity mucks out of the data that there is a *very* good chance that they don't understand anyway, but still allow them to be 'in the loop' on information that they do understand (well, kinda anyway). On 10/27/06, Al Mulnick [EMAIL PROTECTED] wrote: Assume. Hmm.. That's been over done so I'll pass this time :)Harvey, I just replied to a similar thread on this with my thoughts. I won't bore
Re: [ActiveDir] Security-enable all your distribution lists?
Thanks for the doc, Jorge; I'd missed that in my searches. And my initial reaction was not only no, but hell no! to the request. But when I examine it logically it's harder to reject out of hand. A little while ago, we did change the default for new DL group requests to be security enabled. And it seems to me that one would implicitly assume that if one were setting access to a resource like sharepoint, they would use the same thought process as when they're sending mail: Do I want everyone in this group to get this mail | have this access? - Harvey On 10/21/06, Al Mulnick [EMAIL PROTECTED] wrote: My first reaction is, NOOO don't do that. That's silly. I absolutely abhor the concept of convenience to this level when it comes to access to secured resources. Saying that, DG's are often created by default as a security group. I'd actually be surprised, and I would applaud the person that made that choice in your organization. From my perspective, the worst thing ever done by Microsoft was to allow DG's to be security groups. Made it easier to transition PF's sure, but the layer8 contingent doesn't understand the subtle differences between a distribution list and a security-enabled-distribution-group. This loosely translates into people that want to include somebody on their regular mail lists, but don't want them to necessarily have access to the same data shares. They do NOT understand the difference in most cases. I don't know sharepoint well enough to say, but I would be completely floored if they did not have a way to revert behavior. I also would be totally surprised if your information security people were OK with this concept for the reasons I mentioned above. TokenBloat is not the only concern you have here, Harvey. On 10/20/06, Harvey Kamangwitz [EMAIL PROTECTED] wrote: Hi all, I'm interested in your opinion here, and perhaps a heads-up on requirements that may be coming your way. We have a request from the sharepoint team to security-enable all of our 18,000 distribution lists. Our concern, naturally, is token size. What will this do to Joe User's access token? The issue is tied in to Sharepoint. Setting permissions on Sharepoint sites has always been kind of a pain, partly because of Sharepoint itself but also because of the nature of what you're doing. (DISCLAIMER: I'm nothing more than a just-beyond-basic Sharepoint user.) When you set up a teamsite for a project, you want to enable access to the site to the project people. Typically you use an existing group of people in your org ( e.g. your work group for a weekly meeting site), or you create a new group to manage access. Most work groups have mailing distribution lists, but I'll bet most are not security-enabled. So when you set up your teamsite, you have to wait and ask for IT to security-enable your DL so you can use it on your shiny new teamsite. (Unless you're one of us, in which case you can do it yourself :) In the current version of sharepoint, you can work around this by going to the GAL and manually adding individual users to site access. Apparently the next version of Sharepoint does not allow you to do this, forcing everyone that needs group access to security-enable their group. That's why they want to enable ALL of them, not just piecemeal. Our analysis shows that the MEDIAN number of distribution lists per user is relatively small (5-6) and the MEDIAN number of groups in Joe User's token is relatively small (40-50). But we have lots of users in the 100+ groups range, and the winner for greatest number of groups is 400! So...we have to do what we can to mitigate the impact for the large--token people. Do you folks have any feel for a you really don't want to go beyond there limit on token size? Any direct experience? There's no way we can know all the apps out there that might be affected by this. Thanks, Harvey
Re: [ActiveDir] Security-enable all your distribution lists?
Assume. Hmm.. That's been over done so I'll pass this time :)Harvey, I just replied to a similar thread on this with my thoughts. I won't bore you with repetition. But I'm curious what makes you want to assume anything when it comes to security issues like this? I think it's way to unpredictable to assume that users will understand that concept. That's me though. I'm not your user. On 10/27/06, Harvey Kamangwitz [EMAIL PROTECTED] wrote:Thanks for the doc, Jorge; I'd missed that in my searches. And my initial reaction was not only no, but hell no! to the request. But when I examine it logically it's harder to reject out of hand. A little while ago, we did change the default for new DL group requests to be security enabled. And it seems to me that one would implicitly assume that if one were setting access to a resource like sharepoint, they would use the same thought process as when they're sending mail: Do I want everyone in this group to get this mail | have this access? - Harvey On 10/21/06, Al Mulnick [EMAIL PROTECTED] wrote: My first reaction is, NOOO don't do that. That's silly. I absolutely abhor the concept of convenience to this level when it comes to access to secured resources. Saying that, DG's are often created by default as a security group. I'd actually be surprised, and I would applaud the person that made that choice in your organization. From my perspective, the worst thing ever done by Microsoft was to allow DG's to be security groups. Made it easier to transition PF's sure, but the layer8 contingent doesn't understand the subtle differences between a distribution list and a security-enabled-distribution-group. This loosely translates into people that want to include somebody on their regular mail lists, but don't want them to necessarily have access to the same data shares. They do NOT understand the difference in most cases. I don't know sharepoint well enough to say, but I would be completely floored if they did not have a way to revert behavior. I also would be totally surprised if your information security people were OK with this concept for the reasons I mentioned above. TokenBloat is not the only concern you have here, Harvey. On 10/20/06, Harvey Kamangwitz [EMAIL PROTECTED] wrote: Hi all, I'm interested in your opinion here, and perhaps a heads-up on requirements that may be coming your way. We have a request from the sharepoint team to security-enable all of our 18,000 distribution lists. Our concern, naturally, is token size. What will this do to Joe User's access token? The issue is tied in to Sharepoint. Setting permissions on Sharepoint sites has always been kind of a pain, partly because of Sharepoint itself but also because of the nature of what you're doing. (DISCLAIMER: I'm nothing more than a just-beyond-basic Sharepoint user.) When you set up a teamsite for a project, you want to enable access to the site to the project people. Typically you use an existing group of people in your org ( e.g. your work group for a weekly meeting site), or you create a new group to manage access. Most work groups have mailing distribution lists, but I'll bet most are not security-enabled. So when you set up your teamsite, you have to wait and ask for IT to security-enable your DL so you can use it on your shiny new teamsite. (Unless you're one of us, in which case you can do it yourself :) In the current version of sharepoint, you can work around this by going to the GAL and manually adding individual users to site access. Apparently the next version of Sharepoint does not allow you to do this, forcing everyone that needs group access to security-enable their group. That's why they want to enable ALL of them, not just piecemeal. Our analysis shows that the MEDIAN number of distribution lists per user is relatively small (5-6) and the MEDIAN number of groups in Joe User's token is relatively small (40-50). But we have lots of users in the 100+ groups range, and the winner for greatest number of groups is 400! So...we have to do what we can to mitigate the impact for the large--token people. Do you folks have any feel for a you really don't want to go beyond there limit on token size? Any direct experience? There's no way we can know all the apps out there that might be affected by this. Thanks, Harvey
RE: [ActiveDir] Security-enable all your distribution lists?
have a look at: Addressing Problems Due to Access Token Limitation http://www.microsoft.com/downloads/details.aspx?FamilyID=22dd9251-0781-42e6-9346-89d577a3e74aDisplayLang=en#filelist http://www.microsoft.com/downloads/details.aspx?FamilyID=4a303fa5-cf20-43fb-9483-0f0b0dae265cDisplayLang=en Met vriendelijke groeten / Kind regards, Ing. Jorge de Almeida Pinto Senior Infrastructure Consultant MVP Windows Server - Directory Services LogicaCMG Nederland B.V. (BU RTINC Eindhoven) ( Tel : +31-(0)40-29.57.777 ( Mobile : +31-(0)6-26.26.62.80 * E-mail : see sender address From: [EMAIL PROTECTED] on behalf of Harvey Kamangwitz Sent: Sat 2006-10-21 01:10 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Security-enable all your distribution lists? Hi all, I'm interested in your opinion here, and perhaps a heads-up on requirements that may be coming your way. We have a request from the sharepoint team to security-enable all of our 18,000 distribution lists. Our concern, naturally, is token size. What will this do to Joe User's access token? The issue is tied in to Sharepoint. Setting permissions on Sharepoint sites has always been kind of a pain, partly because of Sharepoint itself but also because of the nature of what you're doing. (DISCLAIMER: I'm nothing more than a just-beyond-basic Sharepoint user.) When you set up a teamsite for a project, you want to enable access to the site to the project people. Typically you use an existing group of people in your org ( e.g. your work group for a weekly meeting site), or you create a new group to manage access. Most work groups have mailing distribution lists, but I'll bet most are not security-enabled. So when you set up your teamsite, you have to wait and ask for IT to security-enable your DL so you can use it on your shiny new teamsite. (Unless you're one of us, in which case you can do it yourself :) In the current version of sharepoint, you can work around this by going to the GAL and manually adding individual users to site access. Apparently the next version of Sharepoint does not allow you to do this, forcing everyone that needs group access to security-enable their group. That's why they want to enable ALL of them, not just piecemeal. Our analysis shows that the MEDIAN number of distribution lists per user is relatively small (5-6) and the MEDIAN number of groups in Joe User's token is relatively small (40-50). But we have lots of users in the 100+ groups range, and the winner for greatest number of groups is 400! So...we have to do what we can to mitigate the impact for the large--token people. Do you folks have any feel for a you really don't want to go beyond there limit on token size? Any direct experience? There's no way we can know all the apps out there that might be affected by this. Thanks, Harvey This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. winmail.dat
Re: [ActiveDir] Security-enable all your distribution lists?
My first reaction is, NOOO don't do that. That's silly. I absolutely abhor the concept of convenience to this level when it comes to access to secured resources. Saying that, DG's are often created by default as a security group. I'd actually be surprised, and I would applaud the person that made that choice in your organization. From my perspective, the worst thing ever done by Microsoft was to allow DG's to be security groups. Made it easier to transition PF's sure, but the layer8 contingent doesn't understand the subtle differences between a distribution list and a security-enabled-distribution-group. This loosely translates into people that want to include somebody on their regular mail lists, but don't want them to necessarily have access to the same data shares. They do NOT understand the difference in most cases. I don't know sharepoint well enough to say, but I would be completely floored if they did not have a way to revert behavior. I also would be totally surprised if your information security people were OK with this concept for the reasons I mentioned above. TokenBloat is not the only concern you have here, Harvey.On 10/20/06, Harvey Kamangwitz [EMAIL PROTECTED] wrote:Hi all, I'm interested in your opinion here, and perhaps a heads-up on requirements that may be coming your way. We have a request from the sharepoint team to security-enable all of our 18,000 distribution lists. Our concern, naturally, is token size. What will this do to Joe User's access token? The issue is tied in to Sharepoint. Setting permissions on Sharepoint sites has always been kind of a pain, partly because of Sharepoint itself but also because of the nature of what you're doing. (DISCLAIMER: I'm nothing more than a just-beyond-basic Sharepoint user.) When you set up a teamsite for a project, you want to enable access to the site to the project people. Typically you use an existing group of people in your org ( e.g. your work group for a weekly meeting site), or you create a new group to manage access. Most work groups have mailing distribution lists, but I'll bet most are not security-enabled. So when you set up your teamsite, you have to wait and ask for IT to security-enable your DL so you can use it on your shiny new teamsite. (Unless you're one of us, in which case you can do it yourself :) In the current version of sharepoint, you can work around this by going to the GAL and manually adding individual users to site access. Apparently the next version of Sharepoint does not allow you to do this, forcing everyone that needs group access to security-enable their group. That's why they want to enable ALL of them, not just piecemeal. Our analysis shows that the MEDIAN number of distribution lists per user is relatively small (5-6) and the MEDIAN number of groups in Joe User's token is relatively small (40-50). But we have lots of users in the 100+ groups range, and the winner for greatest number of groups is 400! So...we have to do what we can to mitigate the impact for the large--token people. Do you folks have any feel for a you really don't want to go beyond there limit on token size? Any direct experience? There's no way we can know all the apps out there that might be affected by this. Thanks, Harvey
[ActiveDir] Security-enable all your distribution lists?
Hi all, I'm interested in your opinion here, and perhaps a heads-up on requirements that may be coming your way. We have a request from the sharepoint team to security-enable all of our 18,000 distribution lists. Our concern, naturally, is token size. What will this do to Joe User's access token? The issue is tied in to Sharepoint. Setting permissions on Sharepoint sites has always been kind of a pain, partly because of Sharepoint itself but also because of the nature of what you're doing. (DISCLAIMER: I'm nothing more than a just-beyond-basic Sharepoint user.) When you set up a teamsite for a project, you want to enable access to the site to the project people. Typically you use an existing group of people in your org ( e.g. your work group for a weekly meeting site), or you create a new group to manage access. Most work groups have mailing distribution lists, but I'll bet most are not security-enabled. So when you set up your teamsite, you have to wait and ask for IT to security-enable your DL so you can use it on your shiny new teamsite. (Unless you're one of us, in which case you can do it yourself :) In the current version of sharepoint, you can work around this by going to the GAL and manually adding individual users to site access. Apparently the next version of Sharepoint does not allow you to do this, forcing everyone that needs group access to security-enable their group. That's why they want to enable ALL of them, not just piecemeal. Our analysis shows that the MEDIAN number of distribution lists per user is relatively small (5-6) and the MEDIAN number of groups in Joe User's token is relatively small (40-50). But we have lots of users in the 100+ groups range, and the winner for greatest number of groups is 400! So...we have to do what we can to mitigate the impact for the large--token people. Do you folks have any feel for a you really don't want to go beyond there limit on token size? Any direct experience? There's no way we can know all the apps out there that might be affected by this. Thanks, Harvey
