If you modify a query-based collection though, couldn't that impact the whole environment?
I guess the only way to secure that further would be to make use of limiting collections, then the query they modify could only grab all of the systems/users from within the limiting collection. On Wed, Jan 15, 2014 at 10:56 AM, Jason Wallace <[email protected]> wrote: > Hi Stephen > > I hope not to be corrected but my understanding is that once an object has > been scoped and you cannot see it then it will not appear in queries or > reports either. > > I am on a slightly similar project where we have several companies sharing > infrastructure and needing to run compliance reports > > On 15 Jan 2014, at 15:26, "Stephen Owen" <[email protected]> wrote: > > Alright guys, thanks for your help. I have one more question > > Let’s say that I have users and computers in Germany and I want German > IT to only be able to deploy software to computers and users in their > regions. I set up my geographic collections and security scopes and roles > so that to German IT, only computers and users in their region are visible. > > > > What happens if IT then makes a query-based collection, which could > include computers and users outside of their region? Seems to me that the > query would still function and could include users I don’t want them > including on a deployment. > > > > Is this the way it works in that case? Any thoughts about how to get > around this if so? > > > > > On Wed, Jan 8, 2014 at 3:18 PM, Robert Marshall <[email protected]>wrote: > >> There’s limitations either way, Kerberos or fast collection evaluation, >> as long as the client knows the limits this is a simple way to get things >> going. >> >> >> >> *From:* [email protected] [mailto: >> [email protected]] *On Behalf Of *Miller, Todd >> *Sent:* 08 January 2014 18:09 >> >> *To:* [email protected] >> *Subject:* RE: [mssms] RBAC, is this possible? >> >> >> >> If you start adding users to a bunch of new security groups to manage >> application deployments, make sure you keep an eye on your Kerberos token >> size. Once a user is in 70ish AD groups you may start encountering >> problems with systems that use Kerberos authentication. The buffer size >> for Kerberos can generally be increased, but it has to be done via Registry >> changes on each server and webserver config (header size limits)where users >> authenticate with a Kerberos ticket. Not all systems that use Kerberos >> auth can have their buffer size increased either. If it were me, I would >> tread very carefully thinking you can just use AD groups for everything >> under the sun. There is a hard limit to the number of groups that a user >> can be part of. This limit is not exactly sky high either – Kerberos >> tokens reach a hard limit at 64k which is the equivalent of 900ish groups. >> If you are in a group that is in a group, both groups count towards that >> limit. 900 sounds like a lot, but if you start using AD for everything, it >> is not that difficult to reach it – especially the 70ish limit where you >> need to start making adjustments on your systems. >> >> >> >> >> >> >> >> *From:* [email protected] [ >> mailto:[email protected] <[email protected]>] *On >> Behalf Of *Robert Marshall >> *Sent:* Wednesday, January 08, 2014 11:09 AM >> >> *To:* [email protected] >> *Subject:* RE: [mssms] RBAC, is this possible? >> >> >> >> I just setup a client with their first ConfigMgr installation, CM12R2, I >> mapped their deployment collections to AD Security Groups as Jason >> mentioned, the onus is on AD administration using well-known and securable >> tools that support engineers are often use too. You’ve effectively >> displaced the administrative burden away from the ConfigMgr product. AD >> Delta discovery and fast evaluation can help accelerate deployments that >> need to be rapid, from those that can be deployed at a slower pace. The >> only negative is that you need to keep an eye on how many collections you >> have enabled for fast evaluation, as this can have a serious impact on the >> site server if it’s usage grows out of hand. >> >> >> >> *From:* [email protected] [ >> mailto:[email protected] <[email protected]>] *On >> Behalf Of *Jason Wallace >> >> *Sent:* 08 January 2014 16:27 >> *To:* [email protected] >> *Subject:* RE: [mssms] RBAC, is this possible? >> >> >> >> Correct. >> >> >> The granularity of RBAC is very good but does not go down as far as the >> methods for populating a collection. >> >> There was a good suggestion for deploying a modified SCCM console to >> those users who will be using the SCCM console and this might work for you >> >> >> ------------------------------ >> >> Date: Wed, 8 Jan 2014 11:14:15 -0500 >> Subject: Re: [mssms] RBAC, is this possible? >> From: [email protected] >> To: [email protected] >> >> Security Group based collection membership? I actually love to go that >> method, but this client doesn't want to do that. >> >> >> >> It seems the consensus is that one cannot easily prohibit others from >> modifying the queries used in a query based collection. >> >> >> >> On Wed, Jan 8, 2014 at 11:02 AM, Jason Sandys <[email protected]> wrote: >> >> Why not use AD Security groups for this? >> >> >> >> J >> >> >> >> *From:* [email protected] [mailto: >> [email protected]] *On Behalf Of *Krueger, Jeff >> *Sent:* Wednesday, January 8, 2014 8:55 AM >> *To:* [email protected] >> *Subject:* RE: [mssms] RBAC, is this possible? >> >> >> >> I did this for some of our IT staff, gave them the ability to just add >> direct memberships to a collection and remove devices from a collection. >> Had our Citrix team publish the console and I modified the xml files to >> take away the collection properties from the context menu and force them to >> just use the add resource menu item. >> >> >> >> Unfortunately with RBAC you have to give the modify right for users to be >> able to add devices to a collection which also includes the ability to >> create query rules, it would be nice to have those rights broken down a bit >> in future updates >> >> >> >> *From:* [email protected] [ >> mailto:[email protected] <[email protected]>] *On >> Behalf Of *Stephen Owen >> >> >> *Sent:* Wednesday, January 8, 2014 9:29 AM >> *To:* [email protected] >> >> *Subject:* Re: [mssms] RBAC, is this possible? >> >> >> >> >> >> We did this in 2007 but in 2012, they're wanting to go all Console. >> >> >> >> I think I'll be rolling a PowerShell GUI to help facilitate all of this. >> >> >> >> Thanks, >> >> >> >> On Wed, Jan 8, 2014 at 9:21 AM, Sherry Kissinger < >> [email protected]> wrote: >> >> Once someone has create or modify on a collection, they can change >> anything. >> >> I suggest have a "front end" -- either a web page, or a powershell gui >> (something like that) which those regional staff can use; you could keep it >> simple "input computer names here" (and a separate one for usernames), and >> trust they've already confirmed the exact computer name and the exact >> username, or your could get as complex as you like on >> verification--confirming the computer or user exists, confirming that the >> user running the "add a computer" has the correct "rights" to manage that >> particular computer or user. >> >> The web page does the actual adding using a service account--which has >> rights to that collection. Basically, a "roll your own shopping". >> >> You could also look at all the various shopping addons for CM12--that's >> pretty much what you are looking for. >> >> >> >> Sherry Kissinger >> Microsoft MVP - ConfigMgr >> [email protected] >> >> >> ------------------------------ >> >> *From:* Jason Wallace <[email protected]> >> *To:* "[email protected]" <[email protected]> >> *Sent:* Wednesday, January 8, 2014 7:32 AM >> *Subject:* Re: [mssms] RBAC, is this possible? >> >> >> >> I really don’t think that you would be able to do this. >> >> >> >> http://gallery.technet.microsoft.com/Matrix-of-Role-Based-d6318b96<https://urldefense.proofpoint.com/v1/url?u=http://gallery.technet.microsoft.com/Matrix-of-Role-Based-d6318b96&k=DRaZFQufJSh%2Bz2CJu01vGA%3D%3D%0a&r=G7Rp/yVEkz9AB1xRQWzmh1E0dbzzZxlFIY6QTWSRqzc%3D%0a&m=R7wAk66h%2BnO0g4iv7QL29mDiVRLN9Z7pPyfAwCNmOZM%3D%0a&s=aa86d8c2e0e6562753b5c8c1e05d14fa1597678744ec747532ae3606d8280e5f>is >> a very useful resource on RBAC, as is Chris Nacker’s blog >> >> >> >> Sent from Windows Mail >> >> >> >> *From:* Stephen Owen <[email protected]> >> *Sent:* Wednesday, 8 January 2014 13:27 >> *To:* [email protected] >> >> >> >> Hi all, >> >> >> >> My client would like to setup RBAC so that regional IT users are able >> to add individual computers or users to a collection, but not create or >> modify query-based collection membership queries, which I will be creating. >> >> >> >> >> I've not spent a lot of time with RBAC, do you know if this is >> possible? >> >> >> >> Thanks! >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ------------------------------ >> >> >> CONFIDENTIALITY NOTICE: This email contains information from the sender >> that may be CONFIDENTIAL, LEGALLY PRIVILEGED, PROPRIETARY or otherwise >> protected from disclosure. This email is intended for use only by the >> person or entity to whom it is addressed. If you are not the intended >> recipient, any use, disclosure, copying, distribution, printing, or any >> action taken in reliance on the contents of this email, is strictly >> prohibited. If you received this email in error, please contact the sending >> party by reply email, delete the email from your computer system and shred >> any paper copies. >> >> Note to Patients: There are a number of risks you should consider before >> using e-mail to communicate with us. See our Privacy & Security page on >> www.henryford.com for more detailed information as well as information >> concerning MyChart, our new patient portal. If you do not believe that our >> policy gives you the privacy and security protection you need, do not send >> e-mail or Internet communications to us. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ------------------------------ >> >> Notice: This UI Health Care e-mail (including attachments) is covered by >> the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is >> confidential and may be legally privileged. If you are not the intended >> recipient, you are hereby notified that any retention, dissemination, >> distribution, or copying of this communication is strictly prohibited. >> Please reply to the sender that you have received the message in error, >> then delete it. Thank you. >> ------------------------------ >> >> >> >> > > >
