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:
- Client computer communication is about securing end points. The two end points in this case are the client and the site system roles that the client talks to.
- A client can communicate by using either the HTTP or HTTPS protocol. HTTPS requires the client and site system roles to be configured with valid PKI certificates for mutual authentication.
-
Intelligent client behavior
: This enables the client to select the most secure communication option available:
- If the client is configured with a valid PKI certificate and there are HTTPS site system roles available, the client uses HTTPS.
- If the client is configured with a valid PKI certificate and there are NO HTTPS site system roles available and the client is configured to use HTTP, the client uses HTTP to communicate with site system roles.
Let’s take a couple of example scenarios to see how this new model works.
Scenario 1: Extending Client Management to the Internet without Installing a New Site
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.
Scenario 2: Transitioning a Site from HTTP Communication to HTTPS
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:
-
On the site properties,
Client Computer Communication
tab, he selects
HTTPS or HTTP
:
This allows the site system roles to use either HTTP or HTTPS communication. -
He then configures the following to enable the intelligent client behavior:
This check box allows clients that are PKI-enabled or not PKI-enabled to co-exist and be managed in the same site at the same time. - He can start moving one site system role at a time from HTTP to HTTPS, and do a gradual rollout of PKI certificates for client computers. This provides a safe opportunity to check whether the site system roles and clients work with the HTTPS configuration. Because the site system roles still accept HTTP connections, all the clients remain managed:
- If a client has a valid PKI certificate and there are HTTPS site system roles available, these clients communicate over HTTPS.
- If a client does not have a valid PKI certificate, the client falls back to HTTP communication.
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:
- The Planning for Internet-Based Client Management section of the Planning for Communications in Configuration Manager topic
- The Planning for Certificates (Self-Signed and PKI) section of the Planning for Security in Configuration Manager topic
- PKI Certificate Requirements for Configuration Manager
- Step-by-Step Example Deployment of the PKI Certificates for Configuration Manager: Windows Ser...
This posting is provided "AS IS" with no warranties and confers no rights.