This is the second part of a two part post. The first part can be seen here

Now that we have SSO setup and working, we now need to create and import the application definition.

I’m not going to go into to much detail on how to create a application definition, but there are various tools available that you can use (BDC Meta Manager, Microsoft Business Data Catalog Definition Editor which is part of the SharePoint Server 2007 SDK)

Here are the key parts of the application definition you need to be aware of.

I have added the XML to a Word document which can be downloaded here (Sorry WordPress doesn’t let me upload XML files)

Below are the properties used by SharePoint to connect to the database. You need to  use the SSO ID specified in Part One when you setup SSO



<LobSystemInstance Name="Persons">
<Properties>
<Property Name="AuthenticationMode" Type="System.String">RdbCredentials</Property>
<Property Name="DatabaseAccessProvider" Type="System.String">SqlServer</Property>
<Property Name="RdbConnection Data Source" Type="System.String">MyServerName</Property>
<Property Name="RdbConnection Initial Catalog" Type="System.String">MyDatabaseName</Property>
<Property Name="RdbConnection Integrated Security" Type="System.String">false</Property>
<Property Name="RdbConnection Pooling" Type="System.String">true</Property>
<Property Name="SsoApplicationId" Type="System.String">SSOAppId</Property>
<Property Name="SsoProviderImplementation" Type="System.String">Microsoft.SharePoint.Portal.SingleSignon.SpsSsoProvider, Microsoft.SharePoint.Portal.SingleSignon, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c</Property>
</Properties>
</LobSystemInstance>


If your primary source is going to be from your Active Directory (In most cases it will be). Your identifier needs to be in the format of DOMAIN\UserName

Once you have loaded your application you need to add both the search crawl account and the user crawl account and give them execute permission . In most cases this will be the same account, but if you have followed the least privilege configuration, these will be separate accounts and both will need to be added.

To add the BDC as secondary connection, go to the following link in SSP admin;

http://myserver/ssp/admin/_layouts/MgrDSServer.aspx

Or

Shared Services Administration: My SSP > User Profile and Properties > Manage Connections    

Click on the “Create New Connection” button and enter the information as below

You need to match your UserNameFilter specified in the application definition file to the AccountName User Profile field 

Click OK and then schedule a full profile import.

Once the import has finished, check the import logs for any errors. This should always be your first port of call if it does not work.

Look for errors under the PEOPLE_DL_IMPORT content source and beginning with spsimport://$$nonmaster$$

Once the import has been run successfully, you will now be able to map the fields with the user profile properties in the “View Profile Properties” page.

I’m going to post a few articles about the process I went through to get this implemented.

There are a few things that aren’t documented that I wanted to catch in these posts, to prevent any further hair loss in the Sharepoint world.

In this first post I will detail how to install and configure SSO. You will only need to configure SSO if you are using SQL authentication to connect to SQL Server.

Initial Setup

I used multiple service accounts for my MOSS 2007 farm, to prevent a single point of failure. It can make installation a little more complex, but will provide a stable environment in the long run.

Below is a brief overview of the accounts that are needed for the SSO installation and configuration (For full details on all the accounts needed for a MOSS 2007 installation have a look here http://technet2.microsoft.com/Office/en-us/library/798aa915-7025-4adc-a210-4f6ff14c43fc1033.mspx?mfr=true)

mossuser-Setup

Used to run installs, you should use this account to log-on to your servers. It should be a local administrator of all your servers and have system administrator rights to the database.

mossuser-FarmAdmin

Used as the application pool for Central Administration and the process account for the Sharepoint Services Timer service. This account needs to a members of Logins, Dbcreator, Security Admin and DBO (for each database) roles

mossuser-SSPAppPool, mossuser-PortalAppPool, mossuser-OtherWebAppPool

All accounts that are used for web application pools will need to be able to administer SSO, this can be achieved by adding them to the mossgroup-SSOAdmin group.

mossuser-SSO

This account is used to run the SSO Service, it will need to be a local administrator of the master key server and have security  administrator rights to the database*

mossgroup-FarmAdmin

This group should be added to the “Farm administrator’s group” and should have the the mossuser-SSO account as a member. (It’s worth while adding all users that need to administer the farm to this group for ease of management)

mossgroup-SSOAdmin

This group is used for the “Single Sign-On Administrator Account” and “Enterprise Application Definition Administrator Account” settings in “Manage Server Settings for Single Sign-On” page. This will need to have the following accounts as members; mossuser-FarmAdmin, mossuser-SSO, mossuser-Setup, mossuser-SSPAppPool, mossuser-PortalAppPool, mossuser-OtherWebAppPool.

Depending on how you manage your MOSS 2007 environment I would also add the mossgroup-FarmAdmin as a member, this means that all Farm administrators will also be able to administer SSO

*If you are unable to give your SSO account security administrator rights on your database then you will need to do the following

• On a server that has MOSS 2007 installed, navigate to “C:\Program Files\Common Files\Microsoft Shared\Microsoft Office 12 Single Sign-on” and locate the sso_schema.sql file and take a copy.

• Open up “Microsoft SQL Server Management Studio” and connect to your database server.

• Create a database called SSO

• Put the mossuser-SSO in the dbo role for this database

• Make sure you have SSO selected as the database and then open the copied sso_schema.sql file.

• Run the script

Configuration

Configure the SSO Service

Locate the “Microsoft Single Sign-on Service” in Services

Right click on the service and select properties

On the “Log On” tab, select “This account” and enter the mossuser-SSO as the user in the format of Domain\User

Click the Apply button and then OK

Restart this service

Update the service account through Central Administration

VERY IMPORTANT

I haven’t seen this documented anywhere, but you need to do this otherwise you will get the following error message when trying to configure SSO. This is only applicable if you are using multiple service accounts, if you are using one account that has local administrator rights and system administrator rights on the database this doesn’t occur

You do not have the rights to perfrom this action

In the event log the following error is logged

User DOMAIN\ mossuser-Setup failed to configure the single sign-on server. The error returned was 0×800708ad. Verify this account has sufficient permissions and try again.

Go to the Central Administration site

In the Central Administration site, go to “Operations” and under “Security Configuration”, click on “Service accounts”

Select the “Windows Service” option and in the drop down, select “Single Sign-on Service”Select the “Configurable” option and enter the mossuser-SSO user and password

Click OK

Configure the SSO Server

In the Central Administration site, go to “Operations” and under “Security Configuration”, click on “Manage settings for single sign-on” and then “Manage server settings”.

Enter DOMAIN\mossgroup-SSOAdmin for the “Single Sign-On Administrator Account” in the “Account name” box

Enter DOMAIN\mossgroup-SSOAdmin for the “Enterprise Application Definition Administrator Account” in the “Account name” box

Enter the database server name and the SSO database name for the “Database Settings” in the “Server name”  and “Database name” boxes

Click OK

Click on “Manage encryption key” and then click on the “Create Encryption Key” (You can also backup your encryption key here if you need to)

Go back to the “Manage Single Sign-On” screen

Click on “Manage settings for enterprise application definitions”

Click on “New Item”

Enter a display name for the application in the “Display Name” box

Enter an application name for the application in the “Application name” box (You will use this name as the reference later on so  I would make it small and easy to remember)

In the “Field 1: Display Name” , enter “User ID” and set “Mask” to “No”

In the “Field 2: Display Name”, enter “Password” and set “Mask” to “Yes”

Click OK

Return back to the “Manage Single Sign-On” screen

Click “Manage account information for enterprise application definitions”

Enter the SQL account name in the “User ID” field

Enter the password for the SQL account in the “Password” field

Click OK

VERY IMPORTANT

This is another task that I haven’t seen documented that needs to be done every time you create an encryption key

Go to the Central Administration site

Under “Upgrade and Migration”, click “Enable features on existing sites”

Check “Enable all sites in this installation to use the following set of features” and click on OK. I think this must send out the new encryption key to the existing sites.

So I’m hoping now that you have SSO up and running!

In Part Two I will detail how to set up the BDC.

If you are getting errors when trying to configure SSO in MOSS 2007, something we discovered that solved this that is worth trying

·         In Central Administration go to Operations·         Under Secuirty Configuration, click on Service Accounts·         Select “Windows service” option and then “Single Sign-on service” in the corresponding dropdown·         Enter in the service account username and password·         Click OKEven though we had set this up through the “Services” console, doing this through the central administration screen fixed the problem.

Some of the errors we were getting was “Login failed for user: domain\user” in the event logs