Recently I`ve published a few articles on the Norwegian website ITPro.no which might be of interest for the Norwegian readers:
Administrasjon av Active Directory med Windows PowerShell
Recently I`ve published a few articles on the Norwegian website ITPro.no which might be of interest for the Norwegian readers:
Administrasjon av Active Directory med Windows PowerShell
Single sign-on is an authentication method that allows users with a domain account to log on once to a client computer by using a password, and then gain access to remote servers without being asked for their credentials again. See more details here for Windows Server 2008 and here for Windows Server 2008 R2.
On the client-side SSO are currently available for Windows XP with SP3, Windows Vista and Windows 7.
Configure SSO on the server-side
To configure SSO on the server-side (Windows Server 2008 Terminal Services or Windows Server 2008 R2 Remote Desktop Services), set the option “Security layer” to either “Negotiate” or “SSL (TLS 1.0)”:
Best practice would be to configure this in a common GPO for all Remote Desktop Services servers in the domain:
This setting resides under Computer Configuration->Policies->Administrative templates->Windows Components->Terminal Services->Terminal Server->Security.
Configure SSO on the client-side
Using a common GPO would also be the best practice to deploy the client settings needed for SSO to work.
The “Allow Delegating Default Credentials” resides under Computer Configuration->Policies->System->Credentials Delegation:
Enable “Allow Delegating Default Credentials”, press the “Show”-button and either specify the domain pre-fixed with * to allow delegation to all servers in the domain, or specify specific servers:
Next, create a RDP-file and deploy this file to the client computers.
Before deploying the file, open it in a text editor, e.g. Notepad, and add the following line: enablecredsspsupport:i:1
This will enable SSO for the RDP-file.
I would also recommend to sign the RDP-file with a Code Signing certificate. This can be accomplished using the utility rdpsign.exe:
Sample signing:
When a RDP-file are signed, the following will be added to the bottom of the file:
signature:s:AQABAAEAAADBCgAAMIIKvQ……..
For Windows Vista and Windows 7 clients, the configuration would now be completed when the RDP-file are deployed.
For Windows XP clients the following would be necessary in addition to the steps above:
-Service Pack 3 needs to be installed
-At least version 6.0 of the Remote Desktop Client
-Turn on the CredSSP Security Provider
The steps to turn on the CredSSP Security Provider are described in this kb-article.
I would recommend deploying these registry settings using Group Policy Preferences:
Also the RDP-file may be deployed in the same way:
I`ve covered the usage of Group Policy Preferences in a previous post.
Also, SSO can be combined with Remote Desktop Services Web Access. The Remote Desktop Services Team has posted an excellent post describing how to set up SSO in RDS Web Access.
Recently I had the need to automate the process of installing Excel Add-ins in a terminalserver (or more correctly Remote Desktop Services environment since this was Windows Server 2008 R2) environment.
Since Excel Add-ins are per-user based, this was in the first place a manual setting. Of course we wanted to automate this process, so I researched a bit on the internet and found mostly VBScripts. I`ve used this KB-article as a template.
Although this worked very well, I`m trying to leverage the use of PowerShell as much as possible. Many would say that VBScripts load much faster, and are more effecient as logonscripts.
Even though PowerShell v1 was a bit slow due to the lack of assemblies not being ngen`ed, as described on the PowerShell Team`s Blog, this bug is fixed in v2 and I`m quite happy with the loading time now.
I basicly re-wrote the sample VBScript in the KB-article, the result are uploaded to PoshCode.org and available from here.
I used an if-statement to check if the Add-in are already installed, to avoid installing it on every logon.
When tested and ready for production, the script may be distributed as a traditional logonscript, or alternatively with Group Policy: