Khader SharePoint: April 2011

Create and setup Query SSA

Open SharePoint 2010 Central Administration Home Page, under Application Management and click Manage Service Applications
In Manage Service Applications page, click New –> Search Service Applications
In Create New Search Service Application page, fill in the details (here’s what I filled)
1. Name: FAST Query SSA
2. FAST Service Application: FAST Search Query
3. Search Service Account: selected the default value
4. Application Pool for Search Admin Web Service: FAST_Query_Admin_App_Pool
  I also decided to let the AppPool run under dotnetscraps\svcaccnt service account.
5. Application Pool for Search Query and Site Settings Web Service: FAST_Query_App_Pool I also decided to let the AppPool run under dotnetscraps\svcaccnt service account.
6. Refer %fastsearch%\install_info.txt on FAST Search Server for the following details|
  
  e.g.: Query Service Location (since our queries are HTTP based): http://WIN-FS.dotnetscraps.com:13287
  Administration Service Location: http://WIN-FS.dotnetscraps.com:13257
  Resource Store Location: http://WIN-FS.dotnetscraps.com:13255
  Account for Administration Service: dotnetscraps\fastuser
7. Click OK
8. When finished, you will get a confirmation that a new Content SSA is created and is added in the list of Service Applications –> click OK
Now to configure SharePoint 2010 to use FAST Search as a default search provider
1. Open SharePoint Central Administration –> Application Management and click Configure service application associations
2. Under Application Proxy Group, click default
3. Select FAST Query SSA (or the Query SSA you created earlier) and click [set as default].
  NOTE: I decided to uncheck Search Service Application as I won’t be using it for our http://win-sp site.
  
  So now, all search done on our team site will use FAST Search to perform the query.
We haven’t finished yet, SharePoint 2010 uses Claims for authentication. We will need to export a certificate from SharePoint 2010 Server and import it on the FAST Search query server(s). This does not mean your query traffic is HTTPS base.
1. On SharePoint Server 2010, Start –> All Programs –> Microsoft SharePoint 2010 Products –> right click onSharePoint 2010 Management Shell and Run as administrator
2. Type the following command
  
  $stsCert = (Get-SPSecurityTokenServiceConfig).LocalLoginProvider.SigningCertificate
  $stsCert.Export("cert") | Set-Content -encoding byte MOSS_STS.cer
3. Copy the MOSS_STS.cer on the FAST Search Server
4. On FAST Search Server, Start –> All Programs –> Microsoft FAST Search Server 2010 for SharePoint –> right click on Microsoft FAST Search Server 2010 for SharePoint shell and Run as administrator
5. Navigate to the folder %FASTSEARCH%\installer\scripts, and type the command
  
  .\InstallSTSCertificateForClaims.ps1 -certPath <"path_to_MOSS_STS.cer_file">
Finally, we will need to activate SharePoint Server Publishing Infrastructure under Site Collection Administration.
1. Open the Web Site (http://win-sp, this is a Team site I created using the Configuration Wizard).
2. Click Site Actions –> click Site Settings
3. Under Site Collection Administration –> click Site collection features
4. Scroll down and look for SharePoint Server Publishing Infrastructure and click Activate

Let us also verify the Office Web Application feature of viewing and editing Office documents directly from the browser is enabled on the server.

Open SharePoint 2010 Central Administration Home Page, under System Settings and click Manage services on server
On the Services page, verify that Excel Calculation Services, Word Viewing Service, and PowerPoint Service are Started.

Looks good now.

Open a new browser windows and hit http://win-sp, right hand top corner in the search bar type “document” (I typed “topology” as I know some of the documents I have uploaded have topology as a keyword.)

Success !! The FAST Search is working fine
Click on View In Browser in the screenshot above.

Click Edit in Browser, you can Edit the document Format it and Save it.

Done.

Synopsis: I have seen quite a bit of confusion out there regarding how to use Secure Store Service for SharePoint 2010. WhileMSDN does have interesting articles, there has been no Alpha to Omega process that shows the relationship to the LOB System, Security Groups representive of the BCS Consumers, BCS Access Account representive of the Credential Owner [Impersonated User], and how to wire it up in SharePoint Designer 2010. This blog hopefully will dispel all fears about Secure Store and answer a MSDN Forum question while at it.

The Blog is broken up into sections

Prep Work

Active Directory Users in Play

The Service Account I am selecting as the Impersonated User (Credential Owner)
The Security Group where all the people that will consume BCS Data will reside

SQL Server Security

Who has Access to What

Setup

Creating & Configuring the Secure Store Object
Creating & Configuring the External Content Type in SharePoint Designer 2010

Creating External Connection with Secure Store
Creating the External Content Type

Reviewing the External Content Type (ECT)
Reviewing the Security on the ECT

Test & Validation

Creating an External List derived from the ECT
Logging on as a User from the Security Group AND Secured in the permission setting of the ECT
Logging on as a User from the Security Group NOT Secured in the permission setting of the ECT

Part 1: Setup

Above: This represents the AD Account [appBCSUser] which I will use as the Impersonated User i.e. the Broker if you will that will connect to the LOB system on behalf of the Group of people who should have access to the data but DOES NOT have access to the database. This is something your DBA will love because he doesn’t have a flurry of people having accounts on his/her DB.

Above: This represents the AD Security Group [SecureStoreBCSUsers] that have access or should have access to LOB Systems. You can of-course have multiple of these for any number of LOB Systems. Note here that Fabian and Hardeep are in this list, we will be the test users later on.

Above: Lets look into CA now and set up our environment

Above: Click Applications Management then Manage Service Applications

Above: We are interested in the Secure Store Service so we click it

Above: We already have some there from previous Labs, but we will create a new one… click New

Above: We create a Target Application ID [note this cant be changed once committed], Display Name which can be the Same App ID, and so on.

Above: I populate the fields and choose “Group” as my Target Application Type. MSDN has a good explanation as to why you want to do that over other options. the Long and Short is that it allows me in this example to tie an AD Group FabianLab\SecureStoreBCSUsers to a single set of credentials i.e. the FabianLab\appBCSUser account. Ill show a few other options below

Above: By default it wants to know how you will collect the credential of the Impersonated User in my case it is a Windows Account so this works.

Above: I change it around a bit for kicks by adding the word Testing infront of the default text

Above: Here are a few other options that you can use. SSS is a Claims Aware SSO solution and can take in just about any Authentication Mechanism

Above: So here because I only log on to CA with the Farm Admin Account, I set that as the target App Admin, however here is where we start to make the App Work for our design. In Members, you can see that i have my AD Group Account earlier. This means that I dont have to meddle with the SSS App anymore, just add and subtract from the AD Security Group.

Above: It processes once i click OK

Above: Now i have a NEW SSS App, but wait you may ask… what about the Impersonated User.. we are coming to that…

Above: We click on the custom actions available and select SET CREDENTIALS to set the Mapping for the Impersonated Users to the Group that we will Manage of “Allowed Users”…

Above: Our trusty Silverlight App shows the progress of us opening a Dialog Pane

Above: The default look of the Credential Mapping

Above: I populated the values with my User Account previously mentioned in the AD Step

Part 2: Validation and Testing

Above: So in SQL Sever you can clearly see that the only account that has Access to the Database “FabianPlayPen” is the AD User mentioned above right…

Above: We create a new External Content Type by defining the name and Selecting External system to define our Connectivity

Above: We choose SQL from the list of choices

Above: We define our SSO connection. One note here though in full disclosure, I had tried a few times to make this work and did a typo, so I re-did my SSS App and called it FabianLABSSSMSDNForumQ from what i had it last but the steps are the same.

Above: Here you may or may not get challenged for credentials when you click OK. The credentials you put here are or should be your own; assuming that you are in that Security Group that will be mapped to the Impersonated User. If not, then you need an account in that Security Group List.

Above: Once completed you will be able to connect to your LOB System, expand it and perform any operation allowable to you

Above: In our instance lets just create a FULL CRUD operation

Above: Validation that it is complete

Above: Click the “Save” button to push the ECT up to the BDC Metadata Store.

Above: Now we can check a place where alot of Gotchas happen. Now one may assume that because they have access to the LOB system via the impersonated user and Group Mapping you are done… You’d be wrong, now you NEED to have permission to use the ECT and I already have mine set up by default under “Set Store Permission” to add myself, the search account, and my service account by default. You may need to put your security group here to make it seamless, but because i am doing demos and want it to break depending on my use case, i leave it fluid.

Above: to do that, click the custom actions and select “Set Permissions”

Above: Do your business here by adding the users you want to have access. Here note that Hardeep doesnt have access while he IS a member of the Security Group.