As all Configuration Manager customers know, security is challenging and often requires complex setup configurations. Setting up a Certificate Authority, issuing certificates, and maintaining them can be a herculean task, and in most cases involves interacting with multiple teams in an organization.
It is the price we pay to have a highly secure environment, where the administrators, executives, and employees don’t have to worry about their data being compromised.
Configuration Manger leverages an existing PKI infrastructure to enable secure communication between clients and site system roles.
Before System Center Configuration Manager 2012, Configuration Manager 2007 had concepts called native mode and mixed mode: The philosophy behind native mode was to secure the site server and all its site systems, in addition to securing all site-to-site communication. This involved configuring a site signing certificate on all installed sites, plus there was an added restriction that a native mode site must always report to a native mode site.
During the planning phase for System Center 2012 Configuration Manager, we listened to customer feedback and revisited this native and mixed mode model, and debated our previous concept of securing the site. The result was client computer communication.
Key concepts for client computer communication:
Let’s take a couple of example scenarios to see how this new model works.
Woodgrove Bank currently has 20,000 intranet clients. These clients never leave the corporate network. Management recently made some changes in corporate policy to address the employee concerns about work life balance and the request for more flexible working arrangements. With the new policy in effect, 30% of the task force will be issued new laptops and they are allowed to work from home.
When the Configuration Manager administrator first read this memo, his first thought was “I have a lot of extra work to do before I can manage these laptops on the Internet!”
Currently all the clients are managed by a single System Center 2012 Configuration Manager primary site (PR1). All the site system roles are configured to communicate over HTTP.
Being aware of how native mode and Internet-based client management worked in Configuration Manager 2007, the administrator’s first assumption was that he would have to install a new native mode primary site. He doesn’t currently have a central administration site, so he thought this would mean either having two hierarchies to manage, or redesign his existing hierarchy.
However, when he investigates the changes in System Center 2012 Configuration Manager, he realizes that he does not need an additional site. Instead, all that’s needed are a few Internet-based roles that are configured for HTTPS communication:
Here’s a comparison of how the two solutions might look for this scenario, to support Internet-based client management in Configuration Manager 2007 and System Center 2012 Configuration Manager:
*Red halo around the site system roles represent sites and roles that are capable of HTTPS communication.
The next challenge is to how to manage Internet clients when they move back into the intranet. Our administrator does not want to change the existing hierarchy and does not want to configure all the clients and site system roles on the intranet to have PKI certificates. The answer to this is enabling intelligent client behavior, one of the new key concepts mentioned previously.
To enable this behavior, simply select this check box from the property page in the previous screenshot:
When selected, Internet clients on the intranet can communicate with HTTP site system roles on the intranet.
Trey Research has 5,000 clients that are managed by a single primary site (PR1). After the recent security push, the Configuration Manager administrator was instructed that all clients must communicate over HTTPS by using PKI certificates for mutual authentication.
If the site had been running Configuration Manager 2007, this would require migrating the whole site from mixed mode to native mode. This would involve checking that all clients had a PKI client certificate, reconfiguring IIS for all the site system roles, configuring the site to use the site server signing certificate, automatically reinstalling site system roles to operate in native mode, and waiting for the site server to resign all the client policies. This “big bang” approach requires a lot of careful planning to make sure that clients are not unmanaged after the migration, with the recommendation to make this change during a quiet period.
Because Trey Research has System Center 2012 Configuration Manager, the administrator doesn’t have to take this risk and work over the weekend. Instead, he does the following:
I hope that this information and example scenarios throw some light into the changes we made for System Center 2012 Configuration Manager, and how you can benefit from the flexibility they provide to manage clients over HTTPS – whether this is to manage client on the Internet or to provide greater security on the intranet.
For more information, see the following in the System Center 2012 Configuration Manager Documentation Library:
-- Abhishek Pathak
This posting is provided "AS IS" with no warranties and confers no rights.
Linked to this post, see "Where are the supported scenarios and network diagrams for Internet-based client management that you had for Configuration Manager 2007?" in the Sites and Hierarchies section of Frequently Asked Questions for Configuration Manager.
Though there is enormous information on Native Mode sorts in CM2007 and CM2012...but Abhishek made it much simpler to understand/implement. Good one !!!
Can I Use a Public CA (No internal PKI) for Configuration Manager 2012?
In response to "Public CA with Configuration Manager 2012 - Can I Use a Public CA (No internal PKI) for Configuration Manager 2012?" :
Yes, the following blog post applies equally to System Center 2012 Configuration Manager: blogs.technet.com/.../can-i-use-a-public-ca-for-native-mode.aspx
If I have a SCCM 2012 Primary Site Server that is configured with WSUS,DP and the SUP role and deploys Updates fine to users on the internal network.
When I deployed OS, the site system settings from HTTP to HTTPS , could OSD be deployed using HTTPS?
What needs the most attention.
This looks like a good improvement, but there is a new problem: All internet based connections are now identified by Microsoft as fast connections. How do you manage applications distribution to your users who are mostly connected by slow Internet connection but can sometime bring their computers to the fast corporate LAN?