Certificate Requirements Planning
Configuration
Manager requires a properly configured Public Key Infrastructure for
native mode operations. Mixed mode sites can also use certificates for a
limited set of functions without a PKI implementation. The next section (“About PKI”)
briefly introduces basic PKI concepts. It then discusses how ConfigMgr
uses PKI and how you should plan to deploy a PKI solution or leverage
your existing PKI for ConfigMgr.
About PKI
Public key cryptography, is currently the principal cryptographic standard for secure
communications on the Internet and on private networks. The algorithms
behind public key cryptography allow messages to be encrypted and
decrypted using a key pair. The keys in the pair are numbers that are
mathematically related such that a message encrypted with one of the
keys in the pair can only be decrypted with the other key. Each user (or
system) that uses public key cryptography has a unique key pair. One of
the keys in the pair is kept secret. This is the private key. The other
key, the public key, is published to make it available to other users.
You can use key pairs in two different ways:
You can encrypt a
message with a user’s public key and send it to the user. Only the user
with the matching private key can decrypt and read it.
You
can sign a message by encrypting it with your private key. Users who
have your public key can decrypt and read the message. Because the
recipients know that the message was encrypted with your private key,
they can be confident that you are the sender and the message has not
been tampered with.
On a small scale, it
would be possible for all users to know each other’s public keys. This
is not practical on a larger scale. To allow the use of public key
cryptography in large environments, including the Internet, PKI
technology was developed. PKI provides a framework for securing both
session-based and messaging communications using a hierarchy of
Certificate Authorities (CAs). At the top of a PKI hierarchy is the root
CA, a system whose public key is known and trusted by all parties who
will participate in that PKI. A CA is used to issue binary objects known
as certificates
to other systems or users. Certificates can be issued for specific
purposes and validate the identity of the certificate holder. Because a
compromised root CA would compromise the integrity of an organization’s
entire PKI, the root CA is generally kept offline and not used to issue
certificates directly to users and systems. A set of subordinate CAs
receive certificates from the root, which allow them to also issue
certificates.
Planning to Use PKI with Configuration Manager
In native mode,
most client-to-server communications are mutually authenticated, signed,
and encrypted using the HTTPS protocol. Here are the principal types of
certificates used by native mode sites:
Client certificates, used by the client to authenticate to site systems
Web server certificates, used by site systems to authenticate to clients
The document-signing certificate, used by the site server to ensure the integrity of client policy and content
All native mode ConfigMgr systems that communicate by HTTPS require PKI certificates. These systems include the following:
Each server supporting
HTTPS requires a certificate based on the Microsoft web server template
or equivalent. All computer client systems require a computer or
workstation certificate. Mobile device clients require an authenticated
session certificate. Detailed descriptions of the required certificates
can be found at http://technet.microsoft.com/en-us/library/bb680733(TechNet.10).aspx.
All communications with Internet-based clients and Internet-based
device clients require PKI certificates on the clients and site systems,
except for sending status messages to the FSP. Status messages sent to
the FSP are essentially a call for help when a client is having problems
contacting the site, so HTTP is used in case certificate-related issues
are causing the problem.
Note: About Encrypting Communications Between Servers
Server-to-server
communication is not encrypted in either native mode or mixed mode
sites.
PKI and Native Mode Sites
In addition to
supporting HTTPS communications between clients and site systems, native
mode ConfigMgr sites use PKI to support OSD for signing policies and
task sequences, and for client certificate deployment. Here are some key
points:
To sign policies, the site server must have a document-signing certificate installed.
For
OSD task sequences, you must install a client authentication
certificate to provide authentication to the management point
temporarily until the client is fully provisioned with its permanent
certificate.
A
root certificate from each root CA supporting ConfigMgr site systems
must be imported into the site configuration for certificate signing.
For Configuration
Manager clients and site systems to operate successfully in native mode,
all systems must trust the CAs that issue the certificate, as well as
any root and intermediate CAs in the certificate hierarchy. Certificates
issued by certain well-known public authorities are trusted by default
on all Windows computers and many mobile devices. If you
use your own PKI, however, you will need to make sure that your CA
certificates are added to the trusted store on all systems. In an Active
Directory forest, you can use AD services to achieve this. You also
need to deploy the certificates themselves to all site systems and
clients. Using Microsoft Certificate Services with an Enterprise
Certification Authority simplifies many of these operations; however,
you can use any PKI supporting x.509 version 3 certificates.
Certificates and Mixed Mode Sites
You
can configure mixed mode sites to use self-signed server certificates
to secure client communications with the management point and state
migration point only. Mixed mode sites can also use certificates to sign
policy and sign content. Clients will verify the signature if the
option to download content from the distribution point and run locally
is selected in the advertisement properties. Configuration Manager 2007
manages certificates used by mixed mode sites, and you cannot use these
certificates outside ConfigMgr operations. Using certificates in mixed
mode sites does not require a PKI infrastructure.
Windows Server 2008 Planning
Support
for Windows Server 2008 clients or site systems require Configuration
Manager 2007 SP 1. There are no special considerations for Windows
Server 2008 client support on servers running full installations of
Windows Server 2008. Microsoft supports the client on Windows Server
2008 core installations; however, Desired Configuration Management and
Out of Band Management do not work with the Core build. There are
several items to note regarding Windows Server 2008 site systems:
You cannot install site systems on Windows Server 2008 Core installations.
Site
servers, management points, distribution points, branch distribution
points, and reporting points require options not enabled by default on
Windows 2008 servers.
The article at http://technet.microsoft.com/en-us/library/cc431377(TechNet.10).aspx
provides step–by-step instructions on how to configure Windows Server
2008 for site system roles. Here are some specific features and settings
you must enable:
IIS, BITS,
and WebDAV are required for management points and BITS-enabled
distribution points. WebDAV is not an included component in Windows
Server 2008. You can download and install WebDAV from http://go.microsoft.com/fwlink/?LinkId=108052.
After
installing WebDAV, use IIS Manager to enable WebDAV and to create and
enable an authoring rule to allow read access to all content for all
users. You also need to configure the following WebDAV settings:
Allow anonymous property queries
Allow property queries with infinite depth
Allow access to hidden files (on BITS-enabled distribution points only)
Disallow custom properties
You must modify the requestFiltering options on BITS-enabled distribution points. Edit the configuration file %windir%\System32\inetsrv\config\applicationHost.config as follows:
Locate the <requestFiltering> section.
For
each file extension that will be included in packages on that
distribution point, change the value of the allowed attribute from False
to True.
|
If you have a set of
existing packages in a source folder or on a distribution point, you
can use PowerShell to obtain a list of the file extensions in your
packages. Enter the following at the PowerShell prompt:
Get-ChildItem <pkgshare> -recurse | Select-Object Extension | Sort-Object Extension | Get-Unique -asString
Here, <pkgshare>
is the local or UNC path of your package folder. For example, if your
packages were stored on \\Mineola\SMSPKGE$, you would enter the
following:
Get-ChildItem \\Mineola\SMSPKGE$ -recurse | Select-Object Extension | Sort-Object Extension | Get-Unique –asString
Windows PowerShell is
a powerful and flexible scripting and shell language included on the
installation disk for Windows Server 2008. PowerShell is also available
for download for Windows XP, Windows Vista, and Windows Server 2003 SP
1. PowerShell offers numerous enhancements over both the MS-DOS-style
command and batch file language and VBScript, and it’s rapidly becoming
an essential tool for administering Windows and Microsoft server
applications. Microsoft has added extensions to support functionality in
applications including Operations Manager 2007, Exchange Server 2007,
and Virtual Machine Manager.
You can visit the Windows PowerShell Technology Center at http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx for additional information about PowerShell. The article at http://www.windows7th.com/?p=22028 includes a nice description of using PowerShell V2 with the ConfigMgr provider.
|
Site
servers and branch distribution points use remote differential
compression (RDC) to generate package signatures and perform signature
comparison. RDC is not installed by default on Windows Server 2008 but
can be installed through Server Manager.
Finally,
you must add ASP.NET on reporting points. This can be done through
Server Manager. You should choose the Windows Authentication security
option for ASP.NET.
Configuration
Manager also takes advantage of the Windows Deployment Service (WDS) in
Windows Server 2008.
