I agree that having it in "a" book doesn't always means it right, that's why I said it was in "my" book which is entirely different :D.
And in regards to your MS quote, whenever a vendor of a piece of software recommends something I like to threat it as best practice until I come up with evidence that doing it in another way is better. Sent from my Windows Phone ________________________________ From: Roland Janus<mailto:[email protected]> Sent: 9/06/2014 15:17 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] Permissions on systems management container Yes, it’s a practical reason, accepting the imo added minor risk. After all, the usual reason for an infection is not having proper access with service or user accounts, much less with a computer account. Pretty much of a stretch believing that a virus might actually deploy XP to systems using SCCM. And having it in a book doesn’t mean it’s always right :) That’s like saying what MS recommends is always best practice. -R From: [email protected] [mailto:[email protected]] On Behalf Of Kim Oppalfens Sent: Montag, 9. Juni 2014 14:54 To: [email protected] Subject: RE: [mssms] Permissions on systems management container I don't think I'll ever see it that way. I don't feel it is more convenient to add a system to a group where it isn't needed, seems more inconvenient than anything else. I also don't agree with the minor reduction quote. You've, at best, doubled your security risk, and that's for one remote site system, its times 3 for 2 dp's and so on. This is a systems mgmt solution you're talking and as such when compromised you basically lost the keys to the kingdom. Let's assume one of your dp's is attacked and is used to compromise the site server minutes later. At which point a hacker decides to put windows XP on all your systems. Would you still feel comfortable explaining after the fact that your setup was best practice as it was more convenient? You're free to do it that way, but this doesn't satisfy the 100% accepted and recommended statement in the original post, in my book. But there's clearly no technical discussion here, more a practical one, and that's a matter of personal preference I guess. Sent from my Windows Phone ________________________________ From: Roland Janus<mailto:[email protected]> Sent: 9/06/2014 11:59 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] Permissions on systems management container Convenience vs. security ? In this case I’m not worried about the minor reduction in security, but prefer the simplicity in managing it. -R From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Johns, Damon (DoJ) Sent: Montag, 9. Juni 2014 01:46 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] Permissions on systems management container This discussion is spot on. I was leaning towards adding the DP computer accounts to a group which already contains the primary's computer account and has been applied with full permission to the systems management container. But then again I wasn't sure if doing so was against best practice even though a standard DP doesn't require explicit access to AD. Roland Janus <[email protected]<mailto:[email protected]>> wrote: I feel it’s hassle to distinguish. Remember, the same group having access on the container also grants the servers admin access to each other. Having all servers in that group grants CM all the access on all the servers. Having a few (DP’s) with access to the container is not an issue, but the process is simple and for all servers the same: Add the group once to access the container Add always any server name to the group, add that group to local admins. Admin and container access solved for all. Simple? To risky? -R From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Kim Oppalfens Sent: Sonntag, 8. Juni 2014 09:12 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] Permissions on systems management container Not sure I get what you are saying. You feel it's less of a hassle to add dp's to a group to grant them rights they don't need? Sent from my Windows Phone ________________________________ From: Roland Janus<mailto:[email protected]> Sent: 8/06/2014 8:53 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] Permissions on systems management container That’s what I meant with simple: Don’t bother, just add them all. Through adding them to local admin, grants them access to install (remote) roles. That there are a few to many having access to the container isn’t really any issue, but much less hassle and always the same process. -R From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Kim Oppalfens Sent: Samstag, 7. Juni 2014 16:03 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] Permissions on systems management container Indeed, but only add the site servers (primary and secondary) to this group. Although mp's are published it's the hierarchy manager component and the site component mgr component that do all the publishing not the mp itself Sent from my Windows Phone ________________________________ From: Roland Janus<mailto:[email protected]> Sent: 7/06/2014 13:30 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] Permissions on systems management container I’d prefer to stick with simple: Add all servers into an AD group, add that group to local admin group on all servers and grant the same AD-group access to the container. Just adding any new server to the same group grants whatever access is needed and CM has all the access it needs also. -R From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Johns, Damon (DoJ) Sent: Samstag, 7. Juni 2014 05:07 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] Permissions on systems management container Thanks, That’s what I thought however I’m stuffed if I could find confirmation easily on TechNet – I’m sure it’s there somewhere…. Cheers Damon From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of CESAR.ABREG0 Sent: Saturday, 7 June 2014 10:43 AM To: [email protected]<mailto:[email protected]> Subject: Re: [mssms] Permissions on systems management container No DPs are required, only site servers and MPs I believe which are the only ones publishing info to AD. Cesar A. Meaning is NOT in words, but inside people! Dr. Myles Munroe My iPad takes half the blame for misspells. On Jun 6, 2014, at 2:51 PM, "Johns, Damon (DoJ)" <[email protected]<mailto:[email protected]>> wrote: Can I just get clarification on this, SCCM 2012 R2 with 1 Primary, SQL on box. When setting up stock standard DP the installation is failing due to the primary’s computer account not being a member of the local administrators group on that system. I can fix this issue but my question is: Q: In setting up a DP, do you need to add the computer account of that server to your ‘SCCM Site Systems’ AD Group which has full control over the Systems Management container in AD? The TechNet documentation is unclear: http://technet.microsoft.com/en-us/library/gg712264.aspx#BKMK_SetSMContainer I know it probably won’t matter in terms of the overall configuration etc however in this case I need to be 100% correct that the changes I’m making are the recommended, accepted method. Cheers Damon ________________________________ CONFIDENTIALITY NOTICE AND DISCLAIMER The information in this transmission may be confidential and/or protected by legal professional privilege, and is intended only for the person or persons to whom it is addressed. If you are not such a person, you are warned that any disclosure, copying or dissemination of the information is unauthorised. If you have received the transmission in error, please immediately contact this office by telephone, fax or email, to inform us of the error and to enable arrangements to be made for the destruction of the transmission, or its return at our cost. No liability is accepted for any unauthorised use of the information contained in this transmission. ________________________________ CONFIDENTIALITY NOTICE AND DISCLAIMER The information in this transmission may be confidential and/or protected by legal professional privilege, and is intended only for the person or persons to whom it is addressed. If you are not such a person, you are warned that any disclosure, copying or dissemination of the information is unauthorised. If you have received the transmission in error, please immediately contact this office by telephone, fax or email, to inform us of the error and to enable arrangements to be made for the destruction of the transmission, or its return at our cost. No liability is accepted for any unauthorised use of the information contained in this transmission. ________________________________ CONFIDENTIALITY NOTICE AND DISCLAIMER The information in this transmission may be confidential and/or protected by legal professional privilege, and is intended only for the person or persons to whom it is addressed. If you are not such a person, you are warned that any disclosure, copying or dissemination of the information is unauthorised. If you have received the transmission in error, please immediately contact this office by telephone, fax or email, to inform us of the error and to enable arrangements to be made for the destruction of the transmission, or its return at our cost. No liability is accepted for any unauthorised use of the information contained in this transmission.
