Tuesday, 11 January 2011

Configuring Security with the FAST Search for SharePoint Server 2010 Lotus Notes Connector

I recently had the pleasure to configure the FAST Search for SharePoint 2010 Lotus Notes Connector. An attempt had already been made to get the connector working and the connector allowed the FAST Search server to connect to Lotus Notes and crawl the content, but it seemed only anonymous content in Lotus Notes was being returned in searches.

When configuring the connector, the Content Collection created for the connector to feed was filling up as expecting, running the Get-FASTSearchContentCollection PowerShell cmdlet displayed tens of thousands of documents indexed, which suggested crawling and indexing was working just fine, but I wasn't getting anywhere near this number of documents returned in any searches.

In order to configure security trimming for the connector, you need to configure user aliasing. This involves a number of steps and running numerous PowerShell cmdlets.

You start with editing the lotusnotessecuritytemplate.xml file in %FASTSEARCH%\etc folder and set the UseSSOMapping property (Turns on or off the generation of an XML-aliasing file) to true and after which you run the Lotus Notes user directory connector, see: Start a crawl (FAST Search Lotus Notes user directory connector). This will generate an ssomapping.xml file based on the Lotus Notes user directory.

You then create a Lotus Notes User Store using the New-FASTSearchSecurityLotusNotesUserStore cmdlet, then enable the CCTK server to accept requests by running the Set-FASTSearchSecurityCCTKServer cmdlet and then create a Fast Search Security XML Aliaser by running the New-FASTSearchSecurityXMLAliaser cmdlet

The theory behind user aliasing is that SharePoint users usually authenticate with Active Directory accounts to run FAST Search queries, Lotus Notes on the otherhand handles its own security, and authorisation to content is governed by Lotus Notes users and groups. So the connector can be configured with an XML file that maps AD Users to Lotus Notes users, simple as that.

This is where the fun starts, the system I worked on had all sorts of random formats for Lotus Notes users and Active Directory users.

The following TechNet page Configure the FAST Search Lotus Notes connector describes how the ssomapping.xml file is populated.

'The Lotus Domino Administrator should make sure that all the Windows Active Directory (AD) domain names are added to the user documents in Domino to enable mapping between the Domino domain and the AD user who performs the search query from SharePoint.

This should be done prior to running the user directory connector. The AD domain names should be placed in the multi-value field called “User name” and it should be the bottom value in that field.'

I had over 5000 Lotus Notes users output in my ssomapping.xml file, updating the last value in the 'User name' field for each Lotus Notes user is a massive task :(

You run the Set-FASTSearchSecurityXMLAliaser command and specify your ssomapping.xml file to configure the XML Aliaser. Using the ssomapping.xml file with the dodgy formats didn't work, so a new ssomapping.xml file was created with only a hand full of AD accounts mapped to Lotus Notes users.

An advantage of the aliaser is I could map the account I was using for search testing to a Lotus Notes user with unrestricted access to Lotus Notes.

The Prepare FAST Search Authorization for use with the FAST Search Lotus Notes connector in TechNet lists an example of account mappings:
<user name="AD\user1">
<domain prefix="lnx" username="cn=<Domino User 1>/ou=department/o=company"/>
<user name="AD\user1">
<domain prefix="lnx" username="cn=<Domino User 2>/ou=department/o=company"/>

I tried this format for user accounts, but it didn't work. So I was stuck. After many hours of despair I came across this section in TechNet:

Troubleshooting (FAST Search Server 2010 for SharePoint)

Which links to this page in it's 'Troubleshooting item level security' section:

A FAST Search query is not returning one or more expected documents

The article title exactly describes my issue :) So following the article, I set the FAST Search Security Log Level to 'info' with the Set-FASTSearchSecurityLogLevel cmdlet

I then executed a search query and went into the %FASTSEARCH%\var\log\syslog folder on my FAST Search server and had a look at the authorisation worker log file produced, it output the folling related to my search query (edited).

[2010-11-22 09:13:39] INFO : authorization-worker@FASTSERVERNAME: systemmsg: Claims.dll:GetClaimsPrincipal - 0#.w|AD_DOMAIN\AD_USER claims info :Total Claims Count:14:1:ClaimType:http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier:Value:AD_DOMAIN\AD_USER:ValueType:http://www.w3.org/2001/xmlschema#string:Issuer:cn=sharepoint security token service, ou=sharepoint, o=microsoft, c=us:OriginalIssuer:cn=sharepoint security token service, ou=sharepoint, o=microsoft, c=us:2:ClaimType:http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid:Value:s-1-5-21-1515894698-2064606462-2977944764-22409:ValueType:http://www.w3.org/2001/xmlschema#string:Issuer:cn=sharepoint security token service, ou=sharepoint, o=microsoft, c=us:OriginalIssuer:windows:3:ClaimType:http://schemas.microsoft.com/ws/2008/06/identity/claims/primarygroupsid:Value:s-1-5-21-1515894698-2064606462-2977944764-513:ValueType:http://www.w3.org/2001/xmlschema#string:Issuer:cn=sharepoint security token service, ou=sharepoint, o=microsoft, c=us:OriginalIssuer:windows:4:ClaimType:http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn:Value:USER@COMPANYDOMAIN.com.au:ValueType:http://www.w3.org/2001/xmlschema#string:Issuer:cn=sharepoint security token service, ou=sharepoint, o=microsoft, c=us:OriginalIssuer:windows:5:ClaimType:http://schemas.microsoft.com/sharepoint/2009/08/claims/userlogonname:Value:AD_DOMAIN\AD_USER:ValueType:http://www.w3.org/2001/xmlschema#string:Issuer:cn=sharepoint security token service, ou=sharepoint, o=microsoft, c=us:OriginalIssuer:windows:6:ClaimType:http://schemas.microsoft.com/sharepoint/2009/08/claims/userid:Value:0#.w|AD_DOMAIN\AD_USER:ValueType:http://www.w3.org/2001/xmlschema#string:Issuer:cn=sharepoint security token service, ou=sharepoint, o=microsoft, c=us:OriginalIssuer:securitytokenservice:7:ClaimType:http://schemas.microsoft.com/sharepoint/2009/08/claims/identityprovider:Value:windows:ValueType:http://www.w3.org/2001/xmlschema#string:Issuer:cn=sharepoint security token service, ou=sharepoint, o=microsoft, c=us:OriginalIssuer:securitytokenservice:8:ClaimType:http://sharepoint.microsoft.com/claims/2009/08/isauthenticated:Value:true:ValueType:http://www.w3.org/2001/xmlschema#string:Issuer:cn=sharepoint security token service, ou=sharepoint, o=microsoft, c=us:OriginalIssuer:securitytokenservice:9:ClaimType:http://schemas.microsoft.com/sharepoint/2009/08/claims/farmid:Value:32ec3884-aa1c-4d68-a98a-2fafa9430b15:ValueType:http://www.w3.org/2001/xmlschema#string:Issuer:cn=sharepoint security token service, ou=sharepoint, o=microsoft, c=us:OriginalIssuer:claimprovider:system:10:ClaimType:http://sharepoint.microsoft.com/claims/2009/08/tokenreference:Value:0#.w|AD_DOMAIN\AD_USER,129348965939086857,wumemu6suqhfbvq2cnnf4p4n6zuwdap3czeptdzrfdfwyu99x0ildbj4j7fzj/pji21jdghqnjoy0uay+hzxqq3fzyip0f4dltrbx9ap4rl9kbtfa3lo/42ajoyvy+xfvbax8uqilrpevunwmqyykg3wcrf/kjuqauesxoiu1wi/dlsdxfr7qjeypd/r+ql0fwhglkoo8m7nxipzru90oo3v8/yd1ojgn24t7x3zybvauxbphohbmqow1ewdfxtvea5q==,urn:schemas-microsoft-com:sharepoint:service:ValueType:http://www.w3.org/2001/xmlschema#string:Issuer:cn=sharepoint security token service, ou=sharepoint, o=microsoft, c=us:OriginalIssuer:sharepoint:11:ClaimType:http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name:Value:0#.w|AD_DOMAIN\AD_USER:ValueType:http://www.w3.org/2001/xmlschema#string:Issuer:cn=sharepoint security token service, ou=sharepoint, o=microsoft, c=us:OriginalIssuer:securitytokenservice:12:ClaimType:http://schemas.microsoft.com/sharepoint/2009/08/claims/sidcompressed:Value:s-1-5-21-1515894698-2064606462-2977944764;513;6295;10477;15654;7542;11123;18030;6917;6631;1286;11120;6334;18122;11930;10516;2095;6349;18053;7593;22625;19911;6243;22606;1133;22437;2060;18050;13968;20135;5928;10227;10351;10478;512;11822;22332;7475;7932s-1-1;0s-1-5-21-788211482-3310490024-2036062914;1008s-1-5;11s-1-5-21-2108236516-395065666-114579206;11937;12023;12839;13852;4327;2327;11384;14459;12715;12702;2218;7828;10932;11072;2408;12735;14452s-1-5-64;10:ValueType:http://www.w3.org/2001/xmlschema#string:Issuer:cn=sharepoint security token service, ou=sharepoint, o=microsoft, c=us:OriginalIssuer:windows:13:ClaimType:http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod:Value:http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/windows:ValueType:http://www.w3.org/2001/xmlschema#string:Issuer:cn=sharepoint security token service, ou=sharepoint, o=microsoft, c=us:OriginalIssuer:cn=sharepoint security token service, ou=sharepoint, o=microsoft, c=us:14:ClaimType:http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant:Value:2010-11-22t00:49:51.846z:ValueType:http://www.w3.org/2001/xmlschema#datetime:Issuer:cn=sharepoint security token service, ou=sharepoint, o=microsoft, c=us:OriginalIssuer:cn=sharepoint security token service, ou=sharepoint, o=microsoft, c=us:

One thing stood out to me in the log was the references to claims based authentication, and a new format for specifying user accounts I could try in the ssomapping.xml file:


This is the claims based username format, reminds me of this guys blog, check out the blog title.

Claims based authentication is actually referenced in the following TechNet articles:

FAST Search Authorization (FSA) overview

FAST Search Authorization (FSA) data flow

About principal aliasing

The problem is claims based authentication isn't referenced in the Prepare FAST Search Authorization for use with the FAST Search Lotus Notes connector article, worse still it contains an incorrect ssomapping format example!

So I then tried specifying ssomapping.xml account mappings as follows:

<user name="0#.w|AD_DOMAIN\AD_USER">
<domain prefix="lnx" username="cn=<Domino User 1>/ou=department/o=company"/>

It worked!

Security trimming when performing queries conformed to the aliases I specified, and I was getting tens of thousands of secured documents returned in search results.