Ultimately, it's about securing the endpoint. In this case, it's site system hosting the internet facing site roles. The problem is, that because this system is on the Intranet, if it is compromised, then the rest of the systems on your Intranet are now within easy reach.
Sure there are many ways to mitigate the risks, that's up to you and your security folks though. Conceptually, you can think of ConfigMgr as a browser and the site system as a web server (in reality, it's almost exactly this). Then, design your security around this model. A reverse proxy is the common solution for this scenario btw. J ________________________________ From: [email protected] <[email protected]> on behalf of Edward Woo <[email protected]> Sent: Monday, November 10, 2014 1:43 PM To: [email protected] Subject: RE: [mssms] RE: CM 2012 Roles for DMZ Client Management Are there any recommendations to reduce the risk regarding your last point on passing traffic into the Intranet so that the security teams will accept some level of risk? Thanks, Edward From: [email protected] [mailto:[email protected]] On Behalf Of Jason Sandys Sent: Sunday, November 09, 2014 7:50 AM To: [email protected] Subject: RE: [mssms] RE: CM 2012 Roles for DMZ Client Management A handful of notes here: - Workgroup or domain joined makes no difference for IBCM clients. - If you configure one of your MPs for HTTPS, it will not respond to HTTP anymore. - It takes more than an MP to manage internet clients – depending upon your goals, you usually need a SUP and DP also. - Passing traffic directly from the Internet to a system on your intranet would give most security folks a heart attack. J From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Denzik, Josh Sent: Saturday, November 8, 2014 3:31 PM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] RE: CM 2012 Roles for DMZ Client Management All, I am also in a similar situation, I need to manage internet clients that are going to be “workgroup” computers that users will have at their house off our internal network. I know that I will have to use PKI; because the machines are not “domain members” will that have any affect? I was going to put the new site server(MP) in our DMZ, but it can’t be domain joined in our environment; and since the site server has to be joined to a domain that option is out. I have two MP’s that service all my internal clients, would the best option be what Jeff suggested below? Configure that one for certificates and publish an Internet FQDN that is tied to a VIP pointing at that site system? Thanks Josh Denzik Senior Systems Engineer From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Nash Pherson Sent: Saturday, November 8, 2014 11:33 AM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] RE: CM 2012 Roles for DMZ Client Management As DirectAccess has pretty much the same requirements as doing ConfigMgr Internet-Based Client Management, you will need to figure out what those roadblocks are. You’ll need PKI and certificates either way. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Edward Woo Sent: Friday, November 7, 2014 14:52 PM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] RE: CM 2012 Roles for DMZ Client Management For some reason I think DirectAccess was shot down as any option that we could deploy in our environment….can’t recall the reason though… From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of [email protected]<mailto:[email protected]> Sent: Friday, November 07, 2014 12:25 PM To: [email protected]<mailto:[email protected]> Subject: Re: [mssms] RE: CM 2012 Roles for DMZ Client Management Cough, DirectAccess Cough….. Way less infrastructure to setup, and then you have no client manageability differences. Sent from Windows Mail From: Edward Woo<mailto:[email protected]> Sent: Friday, November 7, 2014 3:13 PM To: [email protected]<mailto:[email protected]> Thanks for the pointers Jeff! Edward From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Krueger, Jeff Sent: Friday, November 07, 2014 11:53 AM To: [email protected]<mailto:[email protected]> Subject: [mssms] RE: CM 2012 Roles for DMZ Client Management The server must be joined to a domain, though it doesn’t necessarily have to be the same domain as your primary. Of course it still has to be able to communicate with the primary and will need the relevant accounts setup and ports opened between the two. You can set up this site system server to accept only clients from the internet, or do both internet and intranet. Remember each MP can handle 25,000 clients, so I don’t see the 10 MP limit as a problem and would locate any additional MPs (besides the one dedicated to IBCM) in your data center with the Primary server. If you have slow WAN links for remote offices you can setup a Secondary Site for though that really depends on client count as they don’t send much data, otherwise just have a local DP for content. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Edward Woo Sent: Friday, November 7, 2014 2:15 PM To: [email protected]<mailto:[email protected]> Subject: [mssms] RE: CM 2012 Roles for DMZ Client Management Hi Jeff, Given that a primary site is limited to 10 MPs, would it be sufficient to run one site system with MP, DP and SUP roles on it to handle remote sites? Is it possible to run the site system on a workgroup server or does that server have to be a member of the domain? (Trying to see if I can somehow the crossover from DMZ into our internal network.) Thanks, Edward From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Krueger, Jeff Sent: Friday, November 07, 2014 5:38 AM To: [email protected]<mailto:[email protected]> Subject: [mssms] RE: CM 2012 Roles for DMZ Client Management Secondary sites do not support Internet Based Client Management. I would setup a site system located off your primary with the MP,DP and SUP roles on that. Configure that one for certificates and publish an Internet FQDN that is tied to a VIP pointing at that site system. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Edward Woo Sent: Thursday, November 6, 2014 5:57 PM To: [email protected]<mailto:[email protected]> Subject: [mssms] CM 2012 Roles for DMZ Client Management Hi All, I tried going through my archive of e-mails regarding SCCM 2012 roles used to manage DMZ (Workgroup/external facing) systems, but I couldn’t find all the answers I wanted and was hoping people here could help clear things up for me the best ways to achieve my goals. The DMZ systems we want to manage with SCCM are workgroup systems that have some level of external facing access. We’re primarily interested in the HW/SW inventory scans and software updates and application deployment of these systems. We have DMZ systems located at some of our offices so they’re not located at one site and the number of systems can vary in number from 1 to 20 at the different locations. Initially my plan was to configure the internal domain based systems to use HTTP for communications and DMZ systems will require HTTPS communications and eventually migrate the internal systems to HTTPS as well. Deployment of an internal PKI is not going to be an issue for us. I do want to keep our internal clients communicating with a different MP than the DMZ based systems as a means of separation. It was also my understanding that client communications with MPs weren’t really location aware, except when deployed using primary/secondary sites, though one of the most recent SCCM updates supposedly addresses that issue with a registry fix. Would it make sense to deploy a single secondary site just to handle all DMZ communications from all sites or would one deploy a secondary site for DMZ clients at each of the location? Or would it be better to just deploy an MP, DP, and SUP just to manage the DMZ systems and apply the update that addresses location awareness? Is there any additional protections that I could put in place to further isolate our DMZ systems from reaching the internal network? 1. I believe you can restrict primary site communications so that it is only initiated by the primary site server down to the child sites, but does that include primary to secondary site communications? 2. Can either the secondary site or MP/DP/SUP roles be installed on a workgroup server sitting on a restricted VLAN so that only DMZ clients can contact this restricted VLAN for agent communications and only the parent primary site server can contact this restricted VLAN for SCCM communications? That way the only risk is limited to the SCCM server in that restricted VLAN and one can’t attack the AD systems through that server. Or do you have some other suggestion that would work (without building a separate independent SCCM environment for DMZ systems). Many thanks in advance! Edward Woo ________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.henryford.com&d=AAMFAg&c=aLnS6P8Ng0zSNhCF04OWImQ_He2L69sNWG3PbxeyieE&r=pQGVi_ygWZb0EWR_EeMFzgKJCQ8AFTQI7Ck6iiIPItI&m=2DPlCqP0LkqG29Bn8HPtNIDfcieyVYW5cP-fxlA8oSo&s=wEmIs-fwnuTdSqmKCKRraWZb98vo711WPUMlLrGE20w&e=> 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.
