UAG 2010 excels at providing authenticated remote access to internal applications. It can even be used to add authentication to internal applications. Where you will run into limitations is when you have public web properties being published through it.

Consider this scenario: You have two websites you want to publish: www.mysite.com and www.myothersite.com. The first thing you will notice when publishing www.mysite.com is that you can only publish three part names. If you want users to be able to reach your site by going to http://mysite.com, UAG will not be listening for that. You cannot create a host header on the UAG because every time you change the UAG configuration and save it, your IIS site will be overwritten. In order to allow people to type in alternate names in their browsers, you will need to run a separate web server that hosts redirect sites.

Another interesting thing happens when you decide to publish www.myothersite.com. Since it doesn’t share the last two parts of the name with your other site, you’ll need another trunk. This will need another IP address. If you want that load balanced, you’ll need another VIP.

I’m not saying UAG shouldn’t be used as a reverse proxy for public websites, but you should be aware of these limitations before you get started.

Businesses with wifi networks should have policies in place that state under what conditions, if any, smart phones are allowed to connect to its network.  It would be wise to include a specific reference to disabling the “Backup my data” setting, usually found in the Settings/Privacy menu on Android phones.

All administrators using this tool to manage HP hardware over the network should upgrade HP SMH to the latest version in which the flaw has been resolved.

In two independent SharePoint 2010 farms, I’ve encountered errors after changing passwords via the Managed Account functionality. The symptom is that after the change, services will fail to start due to invalid credentials, and you may see errors in the Windows Application Event Log indicating access denied failures.

Each time I’ve seen this problem, there were Windows Services that were set to run as the login with the recently changed password, but at least one of those services was stopped. The solution is that when you are preparing to automate the password change for a service account, ensure that only those services intended to be running are set to run as the managed login, and ensure that those services are in a started state at all times. Your alerting and monitoring system should be configured to watch these services and ensure they are restarted if they stop.

Installing SharePoint 2010 from the GUI installer off the CD is fine if you will only be doing it once and if you don’t need to be able to replicate the settings precisely later.  If you will potentially need to replicate the exact same farm settings a second time, you should automate the installation with PowerShell.  CodePlex has created an automated installation script that requires you to gather all the necessary information up front, create all the accounts you will need, and create at least one web application.  While this requires more up-front organization, it pays off in the long run.

The CodePlex project is called AutoSPInstaller: http://autospinstaller.codeplex.com/
The Version 2 beta is being updated regularly.  It worked for a basic two-server farm (WFE + separate SQL backend).

The set of scripts works great, but there are very few instructions for the beginner, so I have compiled some here.

Before you run the scripts:

1. Create domain accounts and configure the WFE and the SQL server per this article: http://technet.microsoft.com/en-us/library/cc678863.aspx
2. You will also most likely want to create the object cache user accounts: http://technet.microsoft.com/en-us/library/ff758656.aspx
3. Ensure PowerShell v2 is installed.  It is included with Windows Server 2008 R2.
4. Edit the xml file(s) being read by the script.
- Config.xml needs to be updated with the product ID (license key).
- The AutoSPInstallerInput.xml file (that is its name as of build 67032) needs to be updated with all the actual account names and other settings you would like to use.
5. Make sure that if you decide to create the initial portal web app, use the application pool account you defined within managed accounts.
6. Determine whether you want Claims (Kerberos) or Classic authentication and specify that when creating the first web application: http://technet.microsoft.com/en-us/library/cc262350.aspx. The script defaults to claims.  To use classic/NTLM, change useClaims to False.

<WebApplication type=”Portal”
name=”Portal Home”
applicationPool=”PortalHome”
applicationPoolAccount=”DOMAIN\portalacc”
url=”http://localhost”
port=”80″
databaseName=”PortalHome_Content”
useClaims=”False”>

When you are ready to run the installer:

1. Temporarily disable UAC.
2. Disable any anti-virus active scanner.
3. Run PowerShell as Administrator then run the following commands
- Set-ExecutionPolicy -executionpolicy unrestricted for scopes: LocalMachine, Process, and CurrentUser.
- “Add-PSSnapin Microsoft.SharePoint.PowerShell”
4. Use the FolderStructure.txt as a guide to where to put the installer files and the scripts.  Basically, you should put all the installer files (usually extracted from a CD or ISO) into a folder called SP2010.  Inside that folder at the top level, drop the AutoSPInstaller script folder with its files.
5. Create the accounts that you configure as managed accounts in the xml file.  Every service you tell it to create (such as the Managed MetaData) needs a managed account, or you will get an error and will have to create the service later.
6. If you are working with a virtual machine, take a snapshot at this point before you kick off the Launch.bat.
7. Log in as the setup user (local admin), and kick off the batch.
8. By default the log will be placed on the logged in user’s desktop.  This will have any errors that scrolled by on the screen.  If there is an error, the log will show the line number in the script that produced it.  Fix the error and run the script again – it will just skip the parts that are already done.

After the installation completes:
1. You will need to change the loopback check setting.
2. Install the patch mentioned in the log if you will be using claims based (Kerberos) authentication.
3. Watch the application and system error logs for at least 24 hours and resolve any issues you find there.
4. Complete security hardening steps for the farm servers.

I welcome comments and suggestions about how to make this process even more complete.  The folks working on this CodePlex project are actively updating the scripts and taking suggestions to make it better, as well.

Most of the time, Windows 7 client would get an error in SharePoint when opening Explorer View from a document library: “Your client does not support opening this list with windows explorer.”  Restarting the Web Client service on the Windows 7 computers temporarily resolved the issue but did not offer any explanation why it worked or any clues about what on the server was causing the incompatibility.

This week, the client got an answer to the “what” but not the “why.”  As it turns out, there must be a root site in order for Explorer View to work properly for all clients.  In this case, two sites had been set up at the default “/sites/” because no portal page was needed.  The client created a blank page at “/” to resolve the issue.  Why this works has not been clearly explained, but if you run into this scenario, where there is no root site and some clients get errors when trying to open Explorer View, try creating a root site.

Organizations may not have to work hard to initially develop this trust relationship with their customer.  What an organization may not be doing is working hard to maintain this trust relationship.  If the integrity of these assets are challenged, there is a potential risk of destroying this trust relationship, which could be cause for a costly recovery attempt of this customer trust, or complete customer loss.  Ensuring the integrity of your organization’s digital assets should be considered a foundational component of any organization’s security practice.

When we speak of digital assets, we not only include the traditional media data types including images, audio, and video, but all other content produced by your company that exists in a persistent state on disk.  In a web server environment we would most likely be dealing the with following types of data:

• Html, Javascript, CSS, and embedded web objects
• PHP, Perl, .NET, and other application code
• Non-HTML Document types such as PDF or Office files
• Images, Audio, and Video

We were recently employed to review the state of a customer’s environment following a recent intrusion.  As with a portion of the environments we work in today, the services provided included web content and application delivery provided by Apache running on Linux.  While Apache does provide access logging for files requested from it, it does not maintain state regarding the integrity of the files it serves. Following an intrusion, identifying the the attack vector is extremely important in providing future security of this environment but should not be the only consideration.

The following questions need to be asked concurrently:

• What organizational or customer data was exposed?

• Was any data modified and what is the potential impact to our customers?

In high traffic environments, it can be extremely difficult to answer both of these questions quickly, which in turn can prolong the delivery of customer communication or notification for external entities that may have a stake in the exposed data.  To speed up the time to derive an answer to both of these questions, there are two methods that are available to expedite this process.

First, the majority of server operating systems in production today have kernel facilitated auditing capability bundled with the operating system.  Linux provides the Linux Audit Subsystem.  Microsoft Windows Server including 2003 and 2008 provide auditing capability.  Solaris, MacOS X, and the BSD family of operating systems also implement audit facilities.  Each of these respective implementations provide the ability to monitor file access and modification events and produce audit trail which can be used to quickly determine which critical assets were accessed or modified.  Although the deployment of auditing policy is not trivial, the benefit can easily be measured if file integrity is violated and you are able to effectively determine the targeted assets and the associated scope of exposure.

Secondly, organizations should deploy a file integrity monitoring system such as Tripwire or Samhain.  These systems utilize one way cryptographic functions (also known as message digest algorithms) such as MD5, SHA1, SHA2, or Tiger, to create a catalog of computed hashes of  files covered by the monitoring software’s defined policy.  Following the a baseline definition process, these systems monitor filesystem changes against prior hash calculations, and in some cases, against known bad hash values associated with exploit, rootkit code, and other potential malware.   When a change event is discovered, notifications can be delivered to those accountable.

The data generated by each of these tools should be streamed via encrypted transport to a centralized syslog server.   This centralized server should exist in a logically distinct network segment from all other nodes in the environment.   Because this server essentially becomes the gold copy record for file integrity in your environment as related to file assets, extreme care should be used to ensure the validity of logs captured.  This includes utilizing file integrity monitoring and limiting access to those who have a need to know.

The employment of these systems do not provide protection against intrusion but can ease the burden of cleaning up the mess and help organizations identify impact.  While this does not completely mitigate potential loss of trust with your customers, it allows you to effectively measure whether or not their trust was violated and the overall level of exposure.  In the future, we will be providing direction on how these logs can be utilized to provide real-time alerting of an attack in progress, and what you can do to decrease your time to react.

I have been asked that question many times, and I wish the reply I had to deliver was one with a better message.  Unfortunately we often find vulnerable components embedded in commercial products.  Vulnerabilities that can lead to the compromise of the system they are installed in.  We have seen this in both software products that companies are actively shipping, as well as in software and appliances other clients have purchased and installed.  When we request that the vulnerable components be upgraded, the change request very rarely makes it very far up the chain.  The reasoning (when one is actually given) is other “feature enhancements” and new functionality for customers and sales are a higher priority.

While performing security audits against organizations this is an issue that comes up frequently.  What we have seen is that unless the client represents a significant source of revenue or other opportunities for the company shipping vulnerable products, getting them to change can be a very difficult and time consuming process that may not yield major results in any workable time frame.  Baring being a significant revenue source, being a potentially good or bad publicity source could also be a way to get them to be a little more helpful.  For instance having a large scale outage caused by an exploit of one of the vulnerably pieces of software they are using.  However I do not really recommend waiting to be exploited as a viable option.

I am not suggesting that you do not open a support ticket with the company when you do find an issue; however receiving an unworried/unconcerned response is something you should expect.  Having a proof of concept attack against their software that you can show them would be one way to help get their attention, but that can be time consuming and costly.

Instead most organizations are forced to mitigate the issue themselves.  While waiting for the software companies to upgrade or fix the issues you have found, you need to mitigate and create controls around all of the known issues.  In general this can be accomplished through a six step process.

1. Segment your network into different zones based upon function, confidentiality and importance of data, etc.
2. Deploy host based and network based firewalls to restrict access to specific ports, sources, and/or destinations.  The firewalls should restrict both what connections can be made in an attempt to exploit a vulnerability, as well as to limit what damage or access a compromised computer can create.  You do not want a compromised server downloading tools or initiating more attacks if you can help it.
3. Deploy and USE an operational Alerting and Monitoring system, configured to detect outages, error conditions, and anomalies, .  This includes traffic flows, service and device uptime, and SLA measurements, as well as the gathering of syslog data and appropriate snmp-traps.
4. Deploy a network and/or host based IDS to watch for any attempts at exploiting known vulnerabilities or traffic anomalies.
5. Deployment of an event correlation system (such as Cisco’s MARS, RSA’s enVision, or Splunk) to help manage the massive amounts of server, firewall, and IDS logs.
6. Continually monitor, maintain, and manage your environment.  There are no easy “place it and forget it” solutions to security issues.

This is how to change the categories:
1. Go to the calendar web part from the browser.
2. Under the Calendar Tools tab, click the Calendar tab.
3. Choose List Settings.
4. Scroll down to the Columns heading.
5. Click Category.
6. Under the Additional Column Settings heading, there is a text box with the categories, and above the box reads: “Type each choice on a separate line.”
7. Add or remove categories, then click OK.

If you have any information about the features available in Server versus Foundation, let us know.

Update: 5/12/2010: The official comparison page has been posted: http://sharepoint.microsoft.com/en-us/buy/Pages/Editions-Comparison.aspx