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.

After following the basic configuration instructions, he was seeing the following error when trying to create a personal site:

“Your personal site cannot be created. Contact your site administrator for more information”

(These steps assume you’ve configured Profile Synchronization.  Setting up user profile synchronization has several steps that are outlined here: http://technet.microsoft.com/en-us/library/ee721049.aspx.  This blog article has a friendlier version of how to accomplish this (with screenshots): http://sharepointgeorge.com/2010/configuring-the-user-profile-service-in-sharepoint-2010/)

Configuration Settings:
Database:  MySite_ContentDB
Web Application:  your.host.here:80
Managed Paths:  my (explicit inclusion); personal (wildcard inclusion)
My Site Host location:  http://your.host.here/my/
Personal Site location:  personal (do NOT enter the full URL here!)

Procedure
1.       Create a MySites database for separation:  MySite_ContentDB
2.       Create a new Web Application connected to the database:  your.host.here:80
3.       Delete the existing Managed Paths for the newly created Web App
4.       Add three Managed Path entries the Web Application to be used for configuring My Sites
a.       “my” – explicit inclusion
b.      “personal” – wildcard inclusion
c.       / – (root) explicit inclusion
5.       Create a new site collection at http://your.host.here/my/ choosing the My Site Host template from the Enterprise templates
6.       Create a new blank site collection at the root location http://your.host.here (this is to allow enabling of Self-Service Site Creation)
7.       Select the MySite Web application and click Self-Service Site Creation to turn the feature on
8.       Finish configuring My Sites:
a.       Go to Application Management > Manage Service Applications
b.      Select the User Profiles Service Application (not the proxy) > Click Manage
c.       Click Setup My Sites
Note:  The information in the two fields My Site Host and Personal Site Location must follow these rules:
i.   The My Site Host Location must be the location where you installed the My Site collection above:  http://your.host.here/my
ii.  The Personal Site Location must be the wildcard inclusion managed path created above:  personal (do NOT use the full URL here!)
iii.  Make sure the Preferred Search Center is a valid path

To test, click your user name in the top right corner of the window, click My Site.
Your My Site will be created on the first visit to the site.

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.

Many organizations have balked at implementing TFA due to the high cost and complexity, and the lack of flexibility of the solutions available.  The landscape is changing quickly – there are new vendors and a better array of options from vendors that have been in the space for ten or more years.

For many years, commercially available TFA solutions meant carrying around a token that displays a number, which is combined with a PIN to produce two factors (something you have: the token, and something you know: the PIN).  Many new, more flexible solutions are becoming available with the recent entry of new participants in the TFA market.  Credit card form factor tokens are easier for some to carry than a traditional key fob.  Grid cards remove the electronic components bringing the price down, and electronic format grids reduce the need for replacement.  Software tokens that uniquely identify a particular phone or computer remove the need to have a user-accessible token altogether.  Out-of-band one time password (OTP) delivery via email, voicemail, or SMS is one of the latest developments in this new move toward flexibility.  Many vendors even support multiple factor types across a single user base, such that one type of user could have hardware tokens, while another set uses grid cards.

Possibly more important to the slow adoption of TFA than lack of flexibility has been the expense of hardware tokens – up to $50 per user every three to five years – on top of the related software licensing costs.  Many TFA vendors have added lower cost options, such as grid cards, software tokens, and hardware tokens that cost less than $10.  There are even lower cost options if you get away from dedicated hardware tokens entirely, for instance, by using out-of-band solutions.

Some of these new solutions are also decreasing the complexity of rollout as well as the time required.  User self-service portals and simplified provisioning are making it a more reasonable proposition to get TFA rolled out to larger numbers of users.

With increased competition in the TFA market, we’re seeing better options at lower costs.  As a result, implementing TFA to protect critical assets is becoming more feasible by the day.

UPDATE 2-11-11:

With Google’s announcement of the coming availability of second factor authentication for its general population of users, it looks like two-factor is hitting the mainstream. Other vendors will have to follow suit or be left behind.

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.

Does your organization currently employ a strong password policy?  Does your organization currently enforce this strong password policy? A strong password should be 14 characters long and should utilize numeric, upper and lower case alphabetical, and symbol characters such as “!@#$%^&*()”.    Most every modern operating system or directory service (LDAP) implementation supports enforcement of strong password complexity.  Administrators should ensure they are utilizing the password history function of their directory service if available, to minimize the potential for password reuse by end users.  For Linux users not utilizing a directory, you can utilize the PAM module provided by the Openwall project, passwdqc, which provides password complexity enforcement.

If your environment allows, utilize password-less authentication using public key encryption provided by either the RSA or DSS.  Most SSH clients and servers support one or both of these methods.  Finally, Ensure that your SSH server does not allow root or Administrator logins.

If your environment already has a firewall in place to facilitate network access control, you should ensure that TCP port 22 is only available to those networks that need access.  If your environment does not have a firewall, OS level packet filtering is available in all modern operating systems.  When thinking about the SSH surface area in your environment, ensure you include devices that are manageable via SSH including routers, firewalls, switches, and other network appliances.

You should really ask yourself why your SSH service is available to the public if you aren’t explicitly providing a shell service to end users.

The documentation is divided into two parts, web and SQL, and together they provide the big picture for a secure environment.  I’ve recently used the documentation to design the security for a SharePoint farm that needs to provide access to multiple outside agencies/partners.  It was much easier to use this documentation than what was provided for the previous version.  I did find a few areas where the documentation could have been more clear, so I wanted to share my findings and see if anyone else has feedback to make the recommendations stronger.

Web Front-End

I found that in a standard Windows network, NetBIOS over TCP/IP could be disabled, according to Microsoft’s recommendation.  The article did not include instructions, but I did find a response on TechNet that describes how it’s done.

The web.config settings could have been described a little more clearly.

• The PageParserPaths should be empty by default.
• Remember that whenever you create a new web application, a new web.config file is created for it, so you will need to verify the settings are still secured.
• I couldn’t find any information about this one, and I’d love it if someone who knows could share their thoughts on how to accomplish this suggestion: “Ensure that Web Part limits around maximum controls per zone is set low.”  Where is this set, and what would be considered low?

I wish this documentation had listed the minimum required permissions for each service, as I’m having to discover these myself.  For instance, the web analytics service is the one that writes diagnostic logs, and that service account needs access to write to the diagnostic logs directory.  It would be great to see a definitive list beyond what was offered in the service accounts documentation.

SQL Back-End

Unless you are using named instances on SQL, it is safe to block access to port UDP/1434.  One measure that the documentation did not mention but is critical to protecting SQL servers in general is that the firewall rules should use a default deny for all inbound access to the SQL servers.  Only the application server(s), Domain Controllers, and the workstations of the DBAs should be able to reach the SQL servers at all.

Please share any other insights you might have or other resources that can help us secure our SharePoint environments better.