Server 2008 R2 Certificates

How do you determine which roles use certificates is not really tricky. The real answer to “What service needs a Cert?” is “all of them.” It is important to understand where to use certificates in Remote Desktop Services (RDS) deployments, and why you use them.

Most roles need to be configured, but some of them won’t like the RD License Server. By default, you’ll need SSL (x.509) certificates at every stage of connecting to a session or hosted virtual machine (VM). There are three main purposes for this: to secure communications between client and server, to confirm the identity of the server or Web site to which the client is connecting, and to sign Remote Desktop Protocol (RDP) files so your users know the RDP file comes from a trusted source and hasn’t been altered.

These are examples of how RDS uses certificates:

  • RD Session Host servers use certificates to prove their identity. This is called server authentication.
  • RD Session Host servers and RD Virtualization Host servers use certificates to set up a secure link between client and server with TLS 1.0.
  • RD Session Host Servers use certificates for client authentication required for Network Level Authentication (NLA), Single Sign-On (SSO) and implementing Web SSO.
  • RD Session Host servers and RD Connection Broker both use an SSL certificate to sign RemoteApps and VM RDP files, assuring users they’re launching a trusted file.
  • RD Gateway servers use certificates to encrypt communications with clients using TLS 1.0.
  • You can secure the RD Web Access site with an SSL certificate to ensure that people are going to a trusted site (HTTPS).

Enabling RDS functionality relies on specific technologies to support the use of certificates

How to Secure the Channel

TLS is the Internet Engineering Task Force (IETF) standard based on SSL version 3, published by Netscape. Some of the enhancements to TLS include new message alerts, the ability to chain certificates to an intermediary Certificate Authority (CA) certificate instead of the root CA certificate, and slightly different encryption algorithms from SSL.

Although TLS is based on SSL, the two are incompatible. TLS can, however, implement a mechanism by which it can fall back to SSL version 3 if necessary. To establish a secure communication channel between a client and server using TLS, the client and server go through a process of messaging, response and encryption.

There are two requirements for this process to work properly.

  • The client must trust the CA that signs the server’s SSL certificate.
  • The connection between server and client must use high-level (by default) or Federal Information Processing Standard (FIPS) encryption. Low-level encryption only encrypts the traffic from client to server, not server to client, so it’s not a secure way to send security capabilities or shared secrets.

If the connection and encryption level meets those two requirements, the client and server establish communication as follows:

  1. The client sends a hello message along with a random fixed-length value. The server responds with a random fixed-length value. During this exchange, the client tells the server the compression methods, ciphers and hashes it supports. It also sends its protocol version and a session ID to the server. The session ID identifies the communi­cation channel—this is not the Session ID on an RD Session Host server.
  2. The server picks the highest encryption method they both support and a cipher and hash function from the client’s list. Then it tells the client which one it has cho­sen. If there’s a minimum level set for the server and the client can’t meet this minimum, the connection will fail.
  3. The server sends its digital certificate to the client. This certificate contains the server’s name, the trusted CA that signed the certificate and the server’s public key.
  4. The client verifies the certificate is valid and trusted. The certificate used to sign the server certificate will be in the client’s Trusted Root Certification Authorities store. Then it creates a pre-master secret, encrypts it with the server’s public key and sends it to the server.
  5. The server receives and decrypts the pre-master secret with its private key. This server is the only one that can do this because it’s the only server with the matching private key.
  6. Both the server and client have the pre-master secret and random numbers exchanged at the beginning of the process. They use these values to generate the 48-byte master secret (also known as the shared secret). After generating the master secret, they delete the pre-master secret.
  7. Both client and server then hash the 48-byte master secret and use it to generate the MAC secret (the session key used for hashing) and the WRITE key (the session key used for encryption). These keys encrypt and decrypt communication for this session. After the session is over, the keys are discarded.

If any step of this sequence doesn’t work, the connection hasn’t been fully secured. What happens then depends on the Advanced tab settings on the Remote Desktop Connec­tion (RDC) client. In the case of authentication failure, a user can choose to do any one of the following:

  • Connect anyway without notifying the client there was a problem authenticating the server.
  • Warn the client, but still allow the connection (the default setting).
  • Deny the connection if it can’t be verified.

The exception is if the server requires a minimum security level. If that’s the case and the client can’t meet the minimum level, the connection will fail. By default, the client and server will negotiate and use the most secure connection settings they both support.

Credential Caching with CredSSP

Credential caching was introduced with Windows Vista and Windows Server 2008. This enables two features—one that helps the user and one that helps protect the server.

Credential caching helps users by storing credentials for a particular connection so they don’t need to provide them every time they connect to that server (this is SSO). This speeds up the connection. Otherwise a brokered connection must be checked at each step.

On the server side, credential caching provides credentials to the server before it establishes a session. This avoids the overhead of a session if the user isn’t authorized (this is NLA).

The piece that makes credential caching work is the Credential Security Service Provider (CredSSP). This is supported by Windows 7, Windows Vista, Windows Server 2008 and Windows XP SP3. It isn’t linked to the version of RDC being used because CredSSP is part of the OS. CredSSP performs the following functions:

  • For NLA, CredSSP provides the framework that authenticates a user to an RD Session Host server before fully establishing the connection.
  • For reconnecting to a session within a farm, CredSSP speeds the process of passing the connection to the correct server by letting the RD Session Host server see who’s logging on without having to create an entire session. This uses NLA in a slightly different scenario.
  • For SSO, CredSSP stores user credentials and passes them to the RD Session Host server to automate logon.

CredSSP enables mutual authentication of the server and client.

This authentication process takes the following steps.

  1. The client initiates a secure channel with the server using TLS. The server passes back the certificate with its name, CA and public key. Only the server is identified. The client remains anonymous at this point.
  2. When the session is established and a session key created, CredSSP uses the Simple and Protected GSS-API Negotiation (SPNEGO) protocol to mutually authenti­cate the server and client. Basically, this mechanism lets the client and server agree on an authentication mechanism they both support, such as Kerberos or Windows NT LAN Manager (NTLM).
  3. After mutual authentication is finished, CredSSP on the client side encrypts the server’s certificate with the session key created during step 2, and sends it to the server. The server receives the encrypted certificate, decrypts it with its private key, and then adds one to the most significant bit of the certificate number. It then encrypts the result and sends it back to the client. The latter operation ensures that no one can intercept the exchange between client and server and spoof the server.
  4. The client reviews the encrypted certificate received from the server and com­pares it to its own certificate.
  5. Assuming the results match, CredSSP on the client side sends the user credentials to the server.

Authenticating Server Identity

One danger of communicating with a remote computer that requires you to supply your credentials is that the server might not be what you think. If it’s a rogue server impersonating a trusted one, you could inadvertently type your credentials into the wrong server. This would give attackers everything they need to connect to your domain or server.

RDP includes encryption, but the protocol doesn’t have any means to authenticate the server. That’s where TLS and CredSSP come in. Server Authentication checks the name you enter in the RDC client (or RDP file) against the name issued in the certificate specified in the RD Configuration Tool on the RD Session Host server to which it’s connected.

Signing RDP Files

You can use certificates to digitally sign RemoteApp files, as well as RDP files used to connect to a pooled or personal VM (VDI). Signing these files assures the user they were created by a trusted source. It also secures the RDP file from tampering.

Signing RemoteApp files is also required for implementing Web SSO. This lets users sign in once to the RD Web Access Web site. Then they can launch RemoteApps from any farm without having to provide their credentials again.

CredSSP can’t pass credentials to RD Web Access. The user must first log in to the Web site to store their credentials. Then they won’t need to authenticate again to start RemoteApp programs. For this to work, the RemoteApps must be signed and the user must trust the certificate used to sign the RemoteApp.

RDP files created when a user launches an RDP connection from the RD Web Access Desktops tab are created on the fly. The files aren’t signed. Therefore, Web SSO won’t work when connecting to desktops. The user will have to log in to the endpoint once the connection is established. Web SSO also won’t work for connections to pooled or personal VMs.

Contact PSS Enterprises today for a free evaluation of your server.  1-800-285-2448 or mail@pssenterprises.com to get more information about Win Server 2008.

 

 

Application Server Role

Application Server is an expanded server role in the Windows Server® 2008 operating system. The new version of Application Server provides an integrated environment for deploying and running custom, server-based business applications. These applications respond to requests that arrive over the network from remote client computers or from other applications. Typically, applications that are deployed and run on Application Server take advantage of one or more of the following:
• Internet Information Services (IIS) (the Hypertext Transfer Protocol (HTTP) server that is built into Windows Server)
• Microsoft® .NET Framework versions 3.0 and 2.0. (If you have applications that are built with the .NET Framework 3.5, you can download and install the .NET Framework 3.5 onto the operating system.)
• ASP.NET
• COM+
• Message Queuing
• Web services that are built with Windows Communication Foundation (WCF)
We recommend that you use the Application Server role when Windows Server 2008 runs applications that depend on role services or features that are part of the integrated Application Server role and that you select during the installation process. An example might be a specific configuration of Microsoft BizTalk® Server that uses a set of role services or features that are part of the Application Server environment.
Typically, the Application Server role is recommended when you are deploying a business application that was developed within your organization (or developed by an independent software vendor (ISV) for your organization) and when the developer has indicated that specific role services are required. For example, your organization may have an order-processing application that accesses customer records that are stored in a database. The application accesses the customer information through a set of WCF Web services. In this case, you can configure one Windows Server 2008 computer as an application server, and you can install the database on the same computer or on a different computer.
Not every server application benefits from the installation of the Application Server role. For example, the Application Server role is not necessary to support Microsoft Exchange Server or Microsoft SQL Server on Windows Server 2008.
To determine if the Application Server role is useful for running your organization’s business applications, have your administrators work closely with the application’s developers to understand the requirements of the application, for example, whether it uses the .NET Framework 3.0 or COM+ components.
What does Application Server do?
Application Server provides the following:
• A runtime that supports effective deployment and management of high-performance server-based business applications. These applications are able to service requests from remote client systems, including Web browsers connecting from the public Internet or from a corporate network or intranet, and remote computer systems that may send requests as messages.
• The .NET Framework 3.0, which provides developers with a simplified programming model for connected server applications. Developers can use the built-in .NET Framework libraries for many application functions, including input/output (I/O), numerical and text processing, database access, XML processing, transaction control, workflow, and Web services. For system administrators, the .NET Framework provides a secure and high-performance execution runtime for server-based applications, as well as a simplified application configuration and deployment environment.
• Windows Server 2008 installation by means of a new, user-friendly Add Roles Wizard that helps you choose the role services and features that are necessary to run your applications. The Add Roles Wizard automatically installs all features that are necessary for a given role service and makes it easier for you to set up and provision a computer as an application server for your business applications.
Who will be interested in this role?
This information about the Application Server role is primarily for information technology (IT) professionals who are responsible for deploying and maintaining an organization’s line-of-business (LOB) applications. LOB applications are typically developed in your organization or for your organization.
An application server environment consists of one or more servers running Windows Server 2008 that are configured with the Application Server role. This includes servers that do the following:
• Host applications that are built with the .NET Framework 3.0
• Host applications that are built to use COM+, Message Queuing, Web services, and distributed transactions
• Connect to an intranet or to the Internet to exchange information
• Host applications that expose or consume Web services
• Host applications that expose Web pages
• Interoperate with other remote systems running on disparate platforms and operating systems
An extended Application Server environment can also include the following:
• Domain-joined client computers and their users
• Computers that are used primarily for management of the application servers
• Infrastructure servers that run resources, such as Active Directory Domain Services (AD DS) or other Lightweight Directory Access Protocol (LDAP) repositories, Certificate Services, security gateways, process servers, integration servers, application or data gateways, or databases
What new functionality does this role provide?
The new, expanded version of the Application Server role is installed through the Add Roles Wizard in Server Manager. Administrators who have LOB applications that are built with the .NET Framework 3.0 may discover that setting up a hosting environment for these applications is simpler with this server role. The Add Roles Wizard guides the administrator through the process of selecting the role services or supporting features that are available in this role and may be necessary to run specific LOB applications.
Application Server Foundation
Application Server Foundation is the group of technologies that are installed by default when you install the Application Server role. Essentially, Application Server Foundation is the .NET Framework 3.0. (If you have applications that are built with the .NET Framework 3.5, you can download and install the .NET Framework 3.5 onto the operating system.)
Windows Server 2008 includes the .NET Framework 2.0, regardless of any server role that is installed. The .NET Framework 2.0 contains the Common Language Runtime (CLR), which provides a code-execution environment that promotes safe execution of code, simplified code deployment, and support for interoperability of multiple languages, as well as extensive libraries for building applications.
The key components of Application Server Foundation are installed as a set of code libraries and .NET assemblies. The following are the key components of Application Server Foundation:
• Windows Communication Foundation (WCF)
• Windows Workflow Foundation (WF)
• Windows Presentation Foundation (WPF)
WCF is the Microsoft unified programming model for building connected applications that use Web services to communicate with each other. These applications are also known as service-oriented applications (SOA), and they are becoming increasingly more important for business. Developers can use WCF to build SOA applications that employ secure, reliable, transacted Web services that communicate across platforms and interoperate with existing systems and applications in your organization.
WCF enables developers to compose or combine the various technologies that are available today for building distributed applications (COM+ and .NET Enterprise services, Message Queuing, .NET Remoting, ASP.NET Web Services, and Web Services Enhancements (WSE)) in ways that make sense for your organization’s business needs and computing environment.
WF is the programming model and engine for building workflow-enabled applications quickly on Windows Server 2008. A workflow is a set of activities that describe a real-world process, such as an order-purchasing process. A workflow is commonly described and viewed graphically—something like a flowchart. The description of the workflow is often called “the model.” Work items pass through the workflow model from start to finish.
Work items or activities within the model can be executed by people or by systems or computers. While it is possible to describe a workflow in traditional programming languages as a series of steps and conditions, for more complex workflows or workflows that support simpler revisions, designing the workflow graphically and storing that design as a model is typically much more appropriate and flexible.
WF supports system workflow and human workflow across a variety of scenarios, including the following:
• Workflow in LOB applications
• The sequential flow of screens, pages, and dialog boxes as presented to the user in response to the user’s interaction with the user interface (UI)
• Document-centric workflow, for example, the processing of a purchase order or a medical record
• Human workflow interaction, such as sending e-mail to a business client and receiving e-mail from the client
• Composite workflow for SOA
• Business-rule-driven workflow, for example: “On a Monday at 17:00, send an update catalogue request to business partners.”
• Workflow for systems management
What works differently?
Although there is an Application Server role in Windows Server 2003, the new, expanded Application Server role that is available in Windows Server 2008 is not simply an upgrade from the application server configuration tool that is included in Windows Server 2003 or an earlier operating system. Because the role functionality is completely new, administrators should be aware that there is no migration path for the Application Server configuration tool from Windows Server 2003 or earlier operating systems.
How do I resolve these issues?
If you upgrade your server to Windows Server 2008 from Windows Server 2003 or an earlier operating system, and you want to use the capabilities of the Application Server role, you must reinstall the Application Server role by using the Add Roles Wizard in Server Manager. As long as you configure Windows Server 2008 with the correct application services by using the Add Roles Wizard in Server Manager, you can easily move your applications from Windows Server 2003 to Windows Server 2008.
When should I use the Application Server role?
If the server-based LOB applications that you need to deploy and manage require one or more of the following technologies: Microsoft .NET Framework 3.0, Message Queuing, COM+, or distributed transactions, consider configuring your server in the Application Server role.

PSS Enterprises offers full evaluation and consultation on all server operating systems, migrations, and upgrades. Call today for a full evaluation at 1-800-285-2448 or email us at mail@pssenterprises.com for an appointment.
https://www.pssenterprises.com

**Article reprint with permission**

Important Updates Regarding Microsoft Server 2000

July 13, 2010 is the date to mark down on your calendar for the following changes:

* Extended Support for Windows 2000 Server will end and thus will no longer be publicly supported by Microsoft. Windows 2000 Server will continue to have Self-Help Online Support, which includes Knowledge Base articles, FAQs, troubleshooting tools, and other resources, for a minimum of 12 months after the product reaches the end of its support.

* Windows Server 2003 and Windows Server 2003 R2 (at a supported service pack level) will move from the Mainstream Support phase to the Extended Support phase, which will end July 14, 2015. Extended Support means that:
o Microsoft will continue to provide security updates and paid support
o Customers will continue to have access to all security updates and Self-Help Online Support options
o Non-security hotfixes developed during the Extended Support phase are only provided to customers who enroll in Extended Hotfix Support (EHS), though program and per fix fees may still apply. Customers must already have a Premier Support contract to get EHS and must enroll within the first 90 days of the Extended Support phase. Customers with Software Assurance can enroll in EHS at any time.

This upcoming date affects the only version of Windows 2000 Server as well as all the many versions of Windows Server 2003 and Windows Server 2003 R2 (including 32-bit, 64-bit, and Itanium flavors): Datacenter Edition, Enterprise Edition, Standard Edition, and Web Edition.

PSS Enterprises is committed to making sure all Microsoft users are taken care of. If you have Windows Server 2000 or 2003, and are not sure what this means or how it will effect you, call 1-800-285-2448 to speak with a solutions specialist. Questions? Email us at mail@pssenterprises.com and we will get back with you in less that 12 hours.

 

Take a moment to check out our favorite company: MVP-Graphics!  They make us look good!

http://www.mvp-graphics.com