Print - Remote Install and Cluster support for Web Services on Devices (WSD) Printers What is WSD Remote Install and Cluster Support?
Remote Install support for WSD printers allows an administrator to associate and install a WSD-based print device on a remote print spooler. The mechanism used to install the WSD print device will vary depending on whether the remote print spooler is running on a standalone server or a virtual print spooler running on a cluster.
On Windows Vista, there is no way to remotely add a WSD print device to a computer. The only way to work around this is to use the Remote Desktop Client to access the remote desktop and add a device through the Network Explorer or Add Printer Wizard. This solution is not acceptable for server based printer developments. Enterprise administrators are used to using the Print Management Console to manage the print folder on remote servers. The purpose of this feature is to enable the Print Management Console and remote administration for WSD printers in a seamless manner using tools that server administrators use today.
Key Scenarios
Terminology
Local Computer – Windows Vista or Windows Server 2008 computer the administrator is sitting at for the printer installation.
Remote Computer – Windows Server 2008 computer on which the print queue will be installed.
Add Network Printer Wizard – Set of pages in the Add Printer Wizard that is used to install printers directly connected on the network. Also known as the ANPW.
Print Management Console (PMC) – An MMC snap-in that simplifies the management of printer queues, printer drivers, and printer ports on remote print server. Also known as the PMC.
WSDAPI – A system component that supports the Devices Profile for Web Services (DPWS). Also called the Web Services for Devices API.
WSD Print Port Monitor – A spooler component that supports the Print WDP and uses WSDAPI to communicate with WSD print devices.
Scenario 1 – Add a WSD printer on a remote standalone server Goal
Add a WSD printer on a remote standalone server.
Prerequisites or specific configuration for the scenario
1. You must have a WSD based printer available for installation.
2. You must have a standalone server with the “Print Server” role installed. The WSD Print Port Monitor will not function properly without this role. This system is the Remote Computer.
3. You must have a separate Windows Vista or Windows Server 2008 system that has the PMC installed. This system is the Local Computer.
4. The user that runs the PMC on the on the Local Computer must also be an administrator on the Remote Computer.
Step-by-step scenario description
1. Launch the Print Management Console (PMC) on the Local Computer.
2. Add the Remote Computer to the list of servers managed by the PMC.
3. Launch the Add Network Printer Wizard (ANPW) on the Remote Computer via the PMC.
4. Select Add a TCP/IP or Web Services Printer by IP address or hostname and click the Next button.
5. Enter the hostname or IP address of the WSD Printer in the Printer name or IP address box and click the Next button.
6. If the printer has an inbox driver, then the driver will be auto-selected and you will be taken to the Printer Name and Sharing Setting page. If the printer does not have an inbox driver, you will be prompted for the driver install point. Once the driver is installed, you will be taken to the Printer Name and Sharing Setting page. Click the Next button to complete the installation.
7. Once the wizard is done, the installation is complete and the printer is ready to accept jobs.
Expected results
Printer accepts print jobs without error.
Known Issues for scenarios
None.
Goal
Add a WSD printer on a cluster print server.
Prerequisites or specific configuration for the scenario
You must have a WSD based printer available for installation.
You must have a Windows Server 2008 Cluster with the “Print Server” role installed. The WSD Print Port Monitor will not function properly without this role. This system is the Remote Computer.
You must have a separate Windows Vista or Windows Server 2008 system that has the PMC installed. This system is the Local Computer.
The user that runs the PMC on the on the Local Computer must also be an administrator on the Remote Computer.
Step-by-step scenario description
1. Launch the PMC on the Local Computer.
2. Add the Remote Computer to the list of servers managed by the PMC. Note that the cluster print spooler has a unique hostname.
3. Launch the Add Network Printer Wizard (ANPW) on the Remote Computer via the PMC.
4. Select Add a TCP/IP or Web Services Printer by IP address or hostname and click the Next button.
5. Enter the hostname or IP address of the WSD Printer in the Printer name or IP address box and click the Next button.
6. If the printer has an inbox driver, then the driver will be auto-selected and you will be taken to the Printer Name and Sharing Setting page. If the printer does not have an inbox driver, you will be prompted for the driver install point. Once the driver is installed, you will be taken to the Printer Name and Sharing Setting page. Click the Next button to complete the installation.
7. Once the wizard is done, the installation is complete and the printer is ready to accept jobs.
Expected results
Printer accepts print jobs without error.
Known Issues for scenarios
None.
Terminal Server What Is Remote Desktop Protocol (RDP) File Signing?
Before RDP 6.1 client, there was no way to help prevent users from opening or running potentially dangerous RDP files from unknown sources. The problem can be compared to Excel if it allowed macros to be used without providing both security levels for blocking and signing mechanisms to verify contents and the originator.
An example of an attack which would exploit this weakness is an RDP file placed on a file share and pointed at Server A, with the program listed to start upon connection as “malice.exe”. When a user uses this RDP file to connect to Server A (which he/she trusts), malice.exe is launched. malice.exe is a program which deletes c:\ or initiates some other attack.
What’s New in RDP File Signing?
The proposed solution is to provide administrators the ability to only allow trusted RDP files to be run by end users. This solution will eliminate a large number of potential spoofing, information tampering, and data loss attacks.
Trusted RDP files would be implemented by using PKI-based digital certificates to digitally sign RDP files. Administrators would sign RDP files using a signing tool we provide and distribute them through the same distribution channels as today. The security level for an environment would be set by the administrator through Group Policy (GP).
There are 3 settings that can be configured through GP, and are part of User Group Policy (HKCU). These are registry settings, and hence can also be modified by a savvy user with admin privileges on non-domain clients. The behavior of these settings is described in the next section.
Trusted publishers List (Comma-separated List of Certificate Hashes that are trusted by the administrator)
Allow user to decide to accept un-trusted publishers (default Enable)
 Note
Un-trusted means that the certificate hash is not present in the Trusted Publishers list. The certificate still goes through standard checks like trusted chain verification, expiry status, revocation status and so on.
Allow user to accept unsigned files (default Enable for backward compatibility).
Who Should Use RDP File Signing feature?
This feature is targeted at the following audiences:
IT planners and analysts who are evaluating the product.
nterprise IT planners and designers.
Early adopters.
Security architects who are responsible for implementing trustworthy computing.
System Administrators maintaining a Terminal Server with lot of Published applications.
Benefits of new features in RDP File Signing
The benefits of providing administrators with the ability to secure RDP files in this way are:
Gives administrators control over the RDP files users are allowed to use.
Reduces the number of user prompts. When signed RDP files are run by users they will not be prompted to allow/deny actions such as resource redirection.
Provides an umbrella solution that grows as the number of client options grows. By signing the entire RDP file we provide the flexibility to add additional client options (such as USB redirection) without having to change the securing solution.
Provides a solution that adapts to future RDP deployment methods.
Prerequisites or specific configuration for the scenario
None of the scenarios have any specific hardware requirements.
All the scenarios assume that you are a domain admin controlling the Group Policy for the domain.
Key Scenarios
How to Deploy RDP Signed Files:
You will need Windows Server 2008 to run these scenarios.
Install the Terminal Server Role through the RMT Tool.
Select the Certificate you want to sign RDP Files using TS RemoteApp Manager.
Set the Group Policies specified to disable the use of unsigned files, third party signed files.
Make sure that the issuer of the certificate you are signing with is trusted on all client machines. This can be done through standard CA Certificate Publishing mechanism.
Scenario 1 – Allow Trusted Files Only: Goal:
To verify whether only Trusted RDP Files are allowed.
Step-by-step scenario description:
1. Select the Certificate you want to sign RDP Files with.
2. Add the Certificate Hash to the trusted publishers List Group Policy.
3. Disallow Unsigned Files by setting the appropriate Group Policy.
4. Disallow Third Party Signed Files by setting the appropriate Group Policy.
5. Launch TS Client with the signed file (for example, using a command line such as: “mstsc.exe filename.rdp“).
6. Launch TS Client with the signed file not in Trusted Publisher List.
7. Launch TS Client with an unsigned file.
Expected results:
Connection Sequence goes through and the standard TS Client redirection dialog is not shown up for a trusted signed file (Step 5)
Connection Sequence does not go through and the standard TS Client BlockUI dialog is not shown up for a third party signed file (Step 6)
Connection Sequence does not go through and the standard TS Client BlockUI dialog is shown up for a unsigned file (Step 7)
Exceptions:
If there is some problem with the certificate such as it is expired or revoked, the file is classified as blocked and TS Client never allows it to be used.
Note: A user can easily delete the sign hash from the RDP File thorough a standard text editor and in that case the file becomes unsigned and is treated that way. Only savvy users would know of this method.
Scenario 2 – Allow Signed Files Only Goal:
To verify whether only Signed RDP Files are allowed.
Step-by-step scenario description:
1. Select the Certificate you want to sign RDP Files with.
2. Disallow Unsigned Files by setting the appropriate Group Policy.
3. Disallow Third Party Signed Files by setting the appropriate Group Policy.
4. Launch TS Client with the signed file (Command line would look like: “mstsc.exe filename.rdp“.
5. Delete the Certificate Hash from the trusted publishers List Group Policy if it is present.
6. Launch TS Client with unsigned file.
Expected results:
Connection Sequence goes through and the standard TS Client redirection dialog is shown. The name of the publisher is seen in the UI for the signed file (step 4).
Connection Sequence does not go through and the standard TS Client BlockUI dialog is shown up for a unsigned file (step 6).
Exceptions:
If there is some problem with the certificate such as it is expired or revoked, the file is classified as blocked and TS Client never allows it to be used.
Note
When Mstsc.exe is launched without any file name, a special file called Default.rdp in USER Directory (On Windows Vista: C:\Users\\Documents) is used for connection. This is a special file that is made an exception for backward compatibility reasons. This file is treated as Third Party Signed instead of unsigned as an interactive user is using it.
Also, the Redirection Warning UI is only shown if you are actually redirecting something, e.g., if you decide to launch a program on connection. It won’t be shown for the default case.
Scenario 3 – Allow Unsigned Files if policy permits: Goal:
To verify whether Unsigned RDP Files are allowed if policy permits.
Step-by-step scenario description:
Launch TS Client with the unsigned file.
Expected results:
Connection Sequence goes through and the standard TS Client redirection dialog is shown. The name of the publisher is seen as “Unknown Publisher” in the UI.
Exceptions:
None.
Scenario 4 – Disallow Blocked Files: Goal:
To verify whether Blocked RDP Files are disallowed at all times.
Step-by-step scenario description:
1. Sign a file with a good certificate.
2. Tamper with one of the signed fields.
3. Launch TS Client with the signed file (for example, the command line would be: “mstsc.exe filename.rdp“)
Expected results:
Connection Sequence does not go through and the standard TS Client BlockUI dialog is shown with the reason for signing verification specified such as “Certificate Checks Failed” or “One of the signed fields are tampered”. The name of the publisher is seen as “Unknown Publisher” in the UI.
Exceptions:
None.
Known Issues for scenarios
None.
Notes:
Group Policy for Trusted Publisher List:
Reg Key: HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services
Type: REG_SZ
Name: TrustedCertThumbprints
Values: <20 bit Cert1 Hash>,<20 Bit Cert2 Hash>…
Group Policy for Third Party Signed Files:
Reg Key: HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services
Type: REG_SZ
Name: AllowSignedFiles
Value: 0 or 1 to Disable or Enable respectively, Not Configured = Enabled
Group Policy For Unsigned Files
Reg Key: HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services
Type: REG_SZ
Name: AllowUnsignedFiles
Value: 0 or 1 to Disable or Enable Respectively, Not Configured = Enabled
| 