Group Policy Central

There is currently a Cross Site Scripting issue with SharePoint 3.0 and 2007 which could allow someone to maliciously run an arbitrary script that could allow elevation of privilege in the SharePoint site. There is currently no hotfix out for this issues  however you can mitigate this issue by enabling the XSS Filter in Internet Explorer 8. Unfortunately this is not turned on by default for the Intranet Zone which is how the majority of SharePoint sites are accessed. So if you are an IT administrator and you want to protect against this issue before Microsoft releases a hotfix then below are the instruction showing how to enable this via Group Policy.

Step 1. Edit the Group Policy object that applies to all the user accounts you want to migrate this issue.

Note: If you want complete coverage of all users in your organisation then make this change the the default domain policy or another policy link to the top of the domain.

Step 2. Navigate to User Configuration > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Intranet Zone and enabled the “Turn on Cross-Site Scripting (XSS) Filter” then ensure you set the drop down menu to “Enabled” then press OK.

To confirm the setting is applied you should now see that the “Enable XSS filter” option is configured to “Enabled” and it is greyed out as the setting has now been configured by group policy.

Unfortunately this setting cannot be enabled via Group Policy Preferences as you can see if does not have the XSS filter option.

To keep up to date with this issue and for more information on this issues see http://blogs.technet.com/msrc/archive/2010/04/29/security-advisory-983438-released.aspx and http://www.microsoft.com/technet/security/advisory/983438.mspx

Just a single new hot fix has come out this week that affects group policy…

981704 The file name of an ADM file is displayed incorrectly in the GPMC report in Windows Vista or in Windows Server 2008

This hotfix resolves a problem with a GPO report in the Group Policy Management Console showing as “Extra Registry Settings” if you have imported a ADM file and then moved it to another location. For more info see http://support.microsoft.com/kb/981704

I have decided to start posting about some specific group policy related KB’s that I have found useful in my time. I will make these posting whenever I come across them so they I will only post them on a semi regular basis.

This KB Focus is KB274274 which talks about a problem you will encounter if you are trying to deploy a machine targeted application from install source that is on a server in another Forest that you have an external trust configured. The problem is that all authentication traffic that goes via an external domain trust is only NTLM based, however computer account authentication is only Kerberos based. This will present as a access denied in the event log whenever the computer tries to install an application no matter how much permission you try to apply to the source files. What’s even more confusing about this problem is when you are logged on as a user you will probably be able to access the file share fine which makes this all the more confusing to troubleshoot.

Unfortunately if you are in this situation you are pretty much left with no alternative other than to move the file share to a serve that is located in the same forest as the computer to install the software as “this behaviour is by design”.  While it is not mentioned in the article you might be able to get away with enabling guest access on the file server however this would require some pretty serious security relaxations which is why it is definitely not recommended.

My second daughter (Charlotte Joanne Burchill) was born today at 8lb7o… and Mum and Bub are doing well… so you’ll excuse me if I don’t do as many post over the next few weeks.

This weeks setting is a little bit different as this is the first time that I have selected a non-managed policy setting, but I have chosen this one as it is probably a setting that will be used in a lot of organisations as they start to rollout Exchange 2010. This setting is called “Enable RPC Encryption” and it is a Outlook 2003 specific setting that enables encrypted RPC communication with the exchange server. The reason why this setting is now so important is that starting with Exchange 2010 all RPC communication with the server requires encryption by default. This setting can be found under User Configuration > Policies > Administrative Templates > Classic Administrative Templates > Outlook 2003 RPC Encryption > Exchange Settings however remember as this is a non-managed policy you may need to enable option to see non-managed settings.

For more information on how to install this custom adm see  Outlook connection issues with Exchange 2010 mailboxes because of the RPC encryption requirement and for more information about making Outlook 2003 with with Exchange 2010 then see Common Client Access Considerations for Outlook 2003 and Exchange 2010 .