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]] >> 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]] >> 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]] >> 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 is a very >> useful resource on RBAC, as is Chris Nacker’s blog >> >> >> >> Sent from Windows Mail >> >> >> >> From: Stephen Owen >> 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. >> > >
