Single Sign On for RD Web Access (WS2012)

By default, form-based authentication is enabled on Web access portal for VDI. I was googling around on how to do SSO authentication. Most sites would advise the editing of the Web.config file of the RD web host that couldn't work well. Finally, I found one post that works. Here's the extract:

OK, here are my results so far.

1) You should not edit web.config file manually. Using comment symbols corrupts this file, so IIS cannot interpret it properly (this is the cause of 'HTTP 500 Internal server error' message). Instead, you should use IIS Management Console to do the task.

Start this console and go to Sites -> Default Web Site -> RDWeb -> Pages (left-click on 'Pages' in the left column). In the right part of the console under 'IIS' section double-click 'Authentication' icon. Disable both the Anonymous and Forms authentication methods. Enable 'Windows Authentication'.

If you try to access the web interface now, you'll get popup window which asks for your login and password. This is expected behavior.

2) On the endpoint (user PC) set Internet Explorer options to allow pass-through authentication. It could be done via IE settings for each user personally, but if you have many users you should use group policy:

* Add your Desktop Broker server to Trusted Sites zone: go to User/Computer Configuration -> Administrative Tools -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security. Open 'Site to Zone assignment list' setting, enable it and map Broker server FQDN to zone 2.

* Enable automatic logon: go to User/Computer Configuration -> Administrative Tools -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security -> Trusted Sites Zone. Open 'Logon options' setting, enable it, and make sure that the following option is selected in the drop-down list: 'Automatic logon with current username and password'.

3) In addition, the actions mentioned above should be executed (I repeat the description here for readers of the thread to have the full list):

* Enable SSO on the RDS clients.
 ---- In the group policy applied to RDS client, edit Administrative Templates -> System -> Credentials Delegation -> Enable the policies "Allow Delegating Default Credentials" and “Allow Delegating Default Credentials with NTLM-only Server Authentication”
--- Set both with value to "termsrv/*" allows the delegation for all terminal servers, you may also specify the server FQDN.

* Open the RDWeb page. Before clicking a pool name make sure the below check box is checked: 'I am using a private computer that complies with my organization's security policy.'

After that single sign-on works nice if I access client PC by entering my login and password manually. However, if I login to the workstation using smart card, I still can access web interface seamlessly. However, after I click on a pool name, RDP client asks for login and password (or smart card PIN). I tried to enable Kerberos authentication provider in Windows Authentication in IIS, but it did not change the situation.

I begin to wonder whether the task has a solution at all. I've found the following article:http://blogs.msdn.com/b/rds/archive/2007/04/19/how-to-enable-single-sign-on-for-my-terminal-server-connections.aspx It's said there that 'Single Sign-on only works with Passwords. Does not work with Smartcards'. The article was last modified four years ago. Is this statement still valid?

3rd Party Software Patching with Solarwinds Patch Manager

Microsoft did an excellent job by providing highly scalable and relatively simple software patch management system called "Windows Server Update Services" or WSUS in short. However, only Microsoft updates are supported. Well, 3rd party software patching for Windows OS have always proved to be challenging. You need another product called Microsoft product called System Center Updates Publisher (SCUP). However, it has to be deployed in conjunction with another System Center Configurations Manager (SCCM) - another complex product. You probably just need something simpler to add on to your existing WSUS infrastructure for patching the outdated Sun Java or Adobe Flash in your environment.

I came across this Solarwinds Patch Manager that claims to support 3rd party patching with just WSUS server - no SCUP or SCCM needed. Hence, I decided to give its free 30-day eval a try. Since it claims to be so easy, I just tried to install without reading the manual. Soon after, I realized it's a bait to get you started and I've to go start reading the admin guide from scratch.

I won't repeat the entire setup procedure. I would just summarize the steps:

1. Install the Patch Manager and follow the wizard.
2. Add some service accounts that have admin rights over your WSUS servers to the credential ring
3. Add the existing WSUS servers and other AD information into the Patch Manager using "Managed Resource Enterprise Configuration Wizard"
4. This is for signing 3rd party patches. Generate WSUS self-signed publishing certificate using Server Publishing Setup Wizard. The security folks may not like it  - I tried using a code signing pfx from the enterprise PKI but it just simply refused to accept.
5. Since the digital signature certificate is self-signed, it has to be distributed to the "Trusted Root CA" store for all update clients. You can distribute the self-signed cert using either the "Client Publishing Wizard" in Solarwinds or the Group Policy. 
6. Remember to enable "Allow signed updates from an intranet Microsoft update service location" on the "Windows Components/Windows Update" of the GPO settings. Otherwise, the update clients would only accept Microsoft signed updates by default.

For 3rd party software patching, here are the high level steps (all within the Solarwinds Patch Manager console):

1. Download the 3rd party patches - usually in exe format
2. Convert and transform the file into *.cab file, which would be signed with the WSUS self-signed cert.
3. Publish the updates to WSUS server

There is also a demo video guide on it.

Now, I tried updating the outdated Java on my first update client. Excitedly, I saw this when I clicked on the "Check for updates" on the security control panel. I thought it was going to succeed.

Alas, there was error 0x800b0004 in installing. Going to the "WindowsUpdate.log" on the "C:\Windows" folder. I saw the following logs:
Validating signature for C:\Windows\SoftwareDistribution\Download\898736be7c675a750734920f38c55636\66b811b903ecd87fef17e4dc58d2aaa52688917b:
Misc Microsoft signed: No
Trusted Publisher: No
WARNING: Digital Signatures on file C:\Windows\SoftwareDistribution\Download\898736be7c675a750734920f38c55636\66b811b903ecd87fef17e4dc58d2aaa52688917b are not trusted: Error 0x800b0004

Using the certificate mmc, the self-signed WSUS certificate is on the trusted Root CA store. But why Windows refused to trust the digital signature? I looked at the error again and noticed that the digital signature was not from a Trusted Publisher.

I manually added the self-signed cert to the "Trusted Publisher" store to the update client. After retrying to install the update, the success message appeared: