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. > ------------------------------ > > > >
