The Raven Report

I have looked forward forward to Windows 2008 Remote App and Single Sign On (SSO) for some time now. Shortly after the Server 2008 release, I looked into publishing a few troublesome application to our XP SP2 workstations. Well this kind of worked. I could get the application down to the system, but dragging the application across two screens did not work and SSO did not work. At the time SP3 was in beta, so I gave it a try and with a few reg changes got SSO and dual monitors to work. Since this was beta, and it wasn’t worth pushing a beta sp to the desktops I shelved the project until SP3 released.

Along comes SP3,  and I install it on a test machine, push my Reg changes and… nothing.  Well not exactly nothing, the application  does open and it now works correctly on dual screens, but SSO doesn’t work at all. Now to the naked eye it appears Microsoft left the feature out, but after a little digging and a couple more Registry modifications SSO is working. Well mostly working SSO to a TS farm/alias from XP SP3  still doesn't work.

That little setback aside here how to do it:

First off to get SSO working, we need to enable credssp and add tspkg to the security packages on the client system.

1.       Start Regedit

2.       Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

                Double click the Security Packages and add tspkg to the bottom on the multi string value.

            

3.       Now navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders

4.       Double click the SecurityProviders and add credssp.dll to the end of the string data.

            CREDSSP.reg (1.07 kb)

Next we need to enable pass-through Kerberos authentication to our Windows 2008 Terminal Server on our client systems. This is easily done with group policy with Vista, but we have to make registry changes in XP.

1.       Navigate to: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation

2.       Create the following values:
"AllowDefaultCredentials"=dword:00000001
“ConcatenateDefaults_AllowDefault"=dword:00000001

3.       While still at: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation

4.       Create a new key  AllowDefaultCredentials

5.       Now inside your new key create as string values for each server you want to connect to.
"1"="TERMSRV/Server1.domain.com"
"2"="TERMSRV/Server2"
"3"="TERMSRV/*.domain.com"    (This will enable SSO to all

6.       Now reboot and you should be good to go

             AllowDefaultCredentials.reg (768.00 bytes)

You can also enable NTLM pass through. In general I’d recommend using Kerberos, besides it doesn’t appear that NTLM pass-through is working in XP SP3 when connecting to a TS, but if you insist here’s how:  

1.       Navigate to: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation

2.       Create the following values:
"AllowDefCredentialsWhenNTLMOnly"=dword:00000001
"ConcatenateDefaults_AllowDefNTLMOnly"=dword:00000001

3.       While still at: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation

4.       Create a new key  AllowDefCredentialsWhenNTLMOnly

5.       Now inside your new key create as string values for each server you want to connect to.
"1"="TERMSRV/Server1.domain.com"
"2"="TERMSRV/Server2"
"3"="TERMSRV/Server3"

Now if everything goes well you should be able open a RDP connection, be it full remote desktop or Remote App without having to retype your login credentials. There is one big caveat with SSO and XP Sp3 though. As mentioned above, at this point SSO does not work from XP sp3 to a TS Farm or alias, even when you allow NTLM pass through.  You can easily get this working in Vista with server certificates, but no amount of banging your head against the keyboard will get it to work in XP.  I will post an update if I ever figure out how to get it working though.

Background:

While running some reports on server hardware I realized that some of the servers were missing the serial, manufacturer, and model information. Being that I needed this information for inventory forwarding and system model counts. After identifying the systems I realized that all of these systems were Windows 2008 64Bit. So I called Altiris and they acknowledged that this is a know issue and is not likely to be resolved until NS 7.0. Well I need this data in the reports today not months down the road.

The Problem:

The issue appears to be in the aexsnplus.exe uses 16bit code and the 16bit subsystem is removed from Windows 2008 64bit, so the aexsnplus.exe ends failing to run.

The Solution:

Since the information we’re looking is available in a couple WMI classes (Win32_ComputerSystem & Win32_BIOS), I figured I could easily create a built in custom inventory task to get the data, but the stars did not appear to align, and still I returned invalid data. Not letting this minor setback get in the way of inventory, I ended up creating a quick and dirty vbscript that would generate the NSI file. Then I created a new hardware inventory ini file replace the line:

aexsnplus.exe /output xml

With:

cscript getsn.vbs

After the new ini file was created, and the vbscript placed in the following directory:

\\YourNSserver\NSCap\Bin\Win32\X86\Inventory Solution

I created a new program in the Inventory Agent Package referencing my new ini file.

AeXInvSoln.exe /s AEXINVHWSN.ini

Then created a new Inventory Task for the new program targeting only the Windows 2008 64 bit systems and let her rip.

Outcome:

I now have my Serial Number, Model & Manufacturer available for all my Windows 2008 64bit systems. I have attached the vbscript and ini file used to make this possible.

W2K8_SN.zip (1.29 kb)

UPDATE:

Altiris has released a updated AeXSNPlus.exe that appears to resolve the issue.  You can follow the instructions in  the link below.

https://kb.altiris.com/display/1/kb/article.asp?aid=43427