Jorge's Quest For Knowledge!

All about Windows Server, ADDS, ADFS & FIM (It Is Just Like An Addiction, The More You Have, The More You Want To Have!)

Archive for the ‘Sharepoint Server’ Category

(2012-09-23) Claims Based Authorizations For Sharepoint Through ADFS (Part 10)

Posted by Jorge on 2012-09-23


-

For the previous part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 9)

-

Now I’m going to log on with the user “ADCORP\Claims.UserR1.C” which has been configured with the role “ROLE_adcorp.app.ADFSAppClaimsContributor” through the group membership of a group called “GRP_R1_ADCORP-ADFS-Claims-App-Contributors”. So ADFS extracts, the user’s group memberships and tranforms the group “GRP_R1_ADCORP-ADFS-Claims-App-Contributors” into a role “ROLE_adcorp.app.ADFSAppClaimsContributor” along the way. So, let’s have a look at this!

image

Figure 1: The User Leveraging Forms Based Authentication

-

image

Figure 2: The Claims Issued To The User And Processed By Sharepoint

-

With regards to sign-out from both Sharepoint and ADFS, you might want to have a look at the following

-

With regards to Claims Based Authorization you might also have a look at the following:

-

Other explanation of configuring Sharepoint 2010 to leverage claims from ADFS v20:

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Federation Services (ADFS), Sharepoint Server | Leave a Comment »

(2012-09-22) Claims Based Authorizations For Sharepoint Through ADFS (Part 9)

Posted by Jorge on 2012-09-22


-

For the previous part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 8)

-

At this point everything is in place for at least the primary site collection administrator to be able to logon against the SP2010 claims based web application. This way I’m able to configure roles within the SP2010 claims based web application to use roles to assign permissions. This allows other (federated) users to access the SP2010 web application based upon their assigned role.

SP2010 knows of three permissions and for each permission I have configured a role. If you have the role, you also get the corresponding permission.

ROLE: ”ROLE_adcorp.app.ADFSAppClaimsOwner” –> PERM: ”Full Control”

ROLE: ”ROLE_adcorp.app.ADFSAppClaimsContributor” –> PERM: ”Contribute”

ROLE: ”ROLE_adcorp.app.ADFSAppClaimsViewer” –> PERM: ”Read”

So, now lets configure these roles and corresponding permissions within the SP2010 web application.

So, open up internet explorer and navigate to “https://app-claims.adcorp.lab:446/” and:

  • Click on “Site Actions” –> “Site Permissions”
  • Click on “Grant Permissions”
  • In the lower right corner of the users/groups field click on the address book icon
  • Enter ONE OF THE ABOVE ROLES in the FIND field and click on the search button
  • Make sure to select the Role node and the click on the role that was found and then click OK
  • Click OK

Repeat these steps for every role that needs to be configured and assign the correct permissions as also stated above.

image

Figure 1: Configuration Of The “ROLE_adcorp.app.ADFSAppClaimsOwner” Role With The SP2010 Web Application And Assigning The “Full Control” Permission To It

-

image

Figure 2: Configuration Of The “ROLE_adcorp.app.ADFSAppClaimsContributor” Role With The SP2010 Web Application And Assigning The “Contribute” Permission To It

-

image

Figure 3: Configuration Of The “ROLE_adcorp.app.ADFSAppClaimsViewer” Role With The SP2010 Web Application And Assigning The “Read” Permission To It

-

After this the roles and permissions look like:

image

Figure 4: The Configured Roles/Accounts And Corresponding Permissions For The SP2010 Web Application

-

For the next part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 10)

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Federation Services (ADFS), Sharepoint Server | 1 Comment »

(2012-09-21) Claims Based Authorizations For Sharepoint Through ADFS (Part 8)

Posted by Jorge on 2012-09-21


-

For the previous part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 7)

-

At this point, right after the creation of the RP trust, no issuance transform rules exist and also no delegation authorization rules exist. However, one claim rule exists in the issuance authorization rules and that is whatever you selected (“Permit All” or “Deny All”) previously during the creation of the RP trust.

image

Figure 1: Default List Of Issuance Authorization Rules For The “Claims Based Sharepoint App” Relying Party Trust

-

Under the hood the configuration of each claim rules is shown below.

(Get-ADFSRelyingPartyTrust "Claims Based Sharepoint App").IssuanceAuthorizationRules

image

Figure 2: Default Configuration Of Each Issuance Authorization Rule For The “Claims Based Sharepoint App” Relying Party Trust

-

Using a PowerShell script I imported my own defined list of issuance transform rules for the “Claims Based Sharepoint App” Relying Party Trust. The total list now looks like is shown below.

image image

Figure 3: Total List Of Issuance Transform Rules For The “Claims Based Sharepoint App” Relying Party Trust (Default And Custom)

-

Under the hood the configuration of each claim rules is shown below.

(Get-ADFSRelyingPartyTrust "Claims Based Sharepoint App").IssuanceTransformRules

image

image

Figure 4: Configuration Of Each Issuance Transform Rule For The “Claims Based Sharepoint App” Relying Party Trust (Default And Custom)

-

Using a PowerShell script I imported my own defined list of issuance authorization rules for the “Claims Based Sharepoint App” Relying Party Trust. The total list now looks like is shown below.

image

Figure 5: Total List Of Issuance Authorization Rules For The “Claims Based Sharepoint App” Relying Party Trust (Default And Custom)

-

Under the hood the configuration of each claim rules is shown below.

(Get-ADFSRelyingPartyTrust "Claims Based Sharepoint App").IssuanceAuthorizationRules

image

Figure 6: Configuration Of Each Issuance Authorization Rule For The “Claims Based Sharepoint App” Relying Party Trust (Default And Custom)

-

For the next part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 9)

-

Cheers,

Jorge

---------------------------------------------------------------------------------------------

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/

---------------------------------------------------------------------------------------------

############### Jorge's Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

---------------------------------------------------------------------------------------------

Posted in Active Directory Federation Services (ADFS), Sharepoint Server | 1 Comment »

(2012-09-20) Claims Based Authorizations For Sharepoint Through ADFS (Part 7)

Posted by Jorge on 2012-09-20


-

For the previous part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 6)

-

Now we need to create a relying party trust for the SP2010 web application and configure that accordingly! You can do that through the GUI or through PowerShell. I’m going to create the RP trust through the GUI and the configure it (issuing transform rules and authorization transform rules) through PowerShell.

Start the ADFS v2.0 MMC and navigate to the “AD FS 2.0\Trust Relationships\Relying Party Trusts” node. Right-click it and select the “Add Relying Party Trust…” option.

Click on “Start”.

image

Figure 1: The Add Relying Party Trust Wizard – Welcome Screen

-

Select the option “Enter data about the relying party manually” and click on “Next >”. By the way, for more information about all the three options about creating a federation trust, see: (2012-08-31) Leveraging Federation Metadata To Setup A Federation Trust (Claims Provider Or Relying Party)

image

Figure 2: The Add Relying Party Trust Wizard – Select Data Source

-

Specify a display name (e.g. Claims Based Sharepoint App) and click on “Next >”

image

Figure 3: The Add Relying Party Trust Wizard – Specify A Display Name

-

For the SP2010 web application select the “AD FS 2.0 profile” and click on “Next >”

image

Figure 4: The Add Relying Party Trust Wizard – Choose Profile

-

The connection to the SP2010 is already secured by SSL and therefore the security token, which is transmitted over the same connection, will also be secured by that! So, it is not needed to additionally encryption the security token itself. I honestly do not know if SP2010 supports this or not. If SP2010 would support this and you would want to enable it, you would need to provide the public part of the token decryption from SP2010. When encrypted, SP2010 would use its private key to decrypt the encrypted security token. In addition, after creating this RP trust, we also need to force ADFS not to encrypt the security token when using this RP trust.

So in this case, just click on “Next >”.

image

Figure 5: The Add Relying Party Trust Wizard – Token Decryption Certificate From Web App (RP)

-

Select the option “Enable support for the WS-Federation Passive Protocol” and specify the exact same URL as when the web application was created in SP2010 and add the _trust part to it. So, in total the URL should something like “https://app-claims.adcorp.lab:446/_trust/” (without the quotes).

image

Figure 6: The Add Relying Party Trust Wizard – URL

-

By default ADFS uses the URL as the identifier. Whatever identifier is used is not important. The only important things to remember are that it must be unique and it must be exactly the same (case-sensitive!) as what has already been configured within the SP2010 web application. In this case that would be: urn:app:sharepointclaimsapp

Add the identifier, click "on “Add” and click on “Next >”.

image

Figure 7: The Add Relying Party Trust Wizard – Configuring Identifiers

-

By default you can only configure “Permit All” or “Deny All”. After the creation of the RP trust you can configure all kinds of complicated conditions if you want to!. For now select the option “Permit all users to access this relying party” and click on “Next >”.

image

Figure 8: The Add Relying Party Trust Wizard – Issuance Authorization Rules

-

This page lists through the different tabs the configured options. Review them all and after that click on “Next >”.

image

Figure 9: The Add Relying Party Trust Wizard – Summary

-

By default the option “Open the Edit Claim Rules dialog for this relying party trust when the wizard closes” is selected. At this time UNcheck it as we will further configure the RP trust through PowerShell.

image

Figure 10: The Add Relying Party Trust Wizard – Finishing

-

To get the full configuration of the just created RP trust “Claims Based Sharepoint App”, use the following powershell command

Get-ADFSRelyingPartyTrust "Claims Based Sharepoint App"

image

Figure 11: The Configuration Of The RP Trust “Claims Based Sharepoint App”

-

First, we are going to disable security token encryption on the RP trust “Claims Based Sharepoint App”.

Get-ADFSRelyingPartyTrust "Claims Based Sharepoint App" | FL Name,EncryptClaims Set-ADFSRelyingPartyTrust -TargetName "Claims Based Sharepoint App" -EncryptClaims $false Get-ADFSRelyingPartyTrust "Claims Based Sharepoint App" | FL Name,EncryptClaims

image

Figure 12: Disabling Encryption Of The Security Token For The RP Trust “Claims Based Sharepoint App”

-

For the next part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 8)

-

Cheers,

Jorge

---------------------------------------------------------------------------------------------

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/

---------------------------------------------------------------------------------------------

############### Jorge's Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

---------------------------------------------------------------------------------------------

Posted in Active Directory Federation Services (ADFS), Sharepoint Server | 1 Comment »

(2012-09-19) Claims Based Authorizations For Sharepoint Through ADFS (Part 6)

Posted by Jorge on 2012-09-19


-

For the previous part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 5)

-

For information about how to install ADFS v2.0 see the blog post about Installing And Configuring ADFS v2 As An STS Server (part1, part 2, part 3) and about Installing And Configuring ADFS v2 As A PRX Server.

-

By default ADFS has one claims provider trust defined and configured called “Active Directory”. That CP trust is also configured with a default list of claims rules (see picture below). For more information about this also see:

-

image16_thumb2_thumb1

Figure 1a: Default List Of Acceptance Claims Rules For The “Active Directory” Claims Provider Trust

-

Under the hood the configuration of each claim rules is shown below.

(Get-ADFSClaimsProviderTrust "Active Directory").AcceptanceTransformRules

image2011_thumb2_thumb1

Figure 1b: Default Configuration Of Each Acceptance Claims Rule For The “Active Directory” Claims Provider Trust

-

Using a PowerShell script I imported my own defined list of claims rules for the “Active Directory” Claims Provider Trust. The total list now looks like is shown below.

image image

Figure 2a: Total List Of Acceptance Claims Rules For The “Active Directory” Claims Provider Trust (Default And Custom)

-

Under the hood the configuration of each claim rules is shown below.

(Get-ADFSClaimsProviderTrust "Active Directory").AcceptanceTransformRules

image

image

image

Figure 2b: Configuration Of Each Acceptance Claims Rule For The “Active Directory” Claims Provider Trust (Default And Custom)

-

For the next part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 7)

-

Cheers,

Jorge

---------------------------------------------------------------------------------------------

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/

---------------------------------------------------------------------------------------------

############### Jorge's Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

---------------------------------------------------------------------------------------------

Posted in Active Directory Federation Services (ADFS), Sharepoint Server | 1 Comment »

(2012-09-18) Claims Based Authorizations For Sharepoint Through ADFS (Part 5)

Posted by Jorge on 2012-09-18


-

For the previous part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 4)

-

For information about how to install ADFS v2.0 see the blog post about Installing And Configuring ADFS v2 As An STS Server (part1, part 2, part 3) and about Installing And Configuring ADFS v2 As A PRX Server.

-

The configuration of ADFS consists of the following:

  1. Configuring (enabling/disabling) Endpoints
  2. Configuring Claims Descriptions
  3. Creating and configuring claims provider (CP) trusts
  4. Creating and configuring relying party (RP) trusts

-

For a demo environment it is not needed to do [1]. However, in whatever environment you are using ADFS you most likely need/must configure [2], [3] and [4].

-

Endpoints can be configured manually through the ADFS v2.0 MMC or through PowerShell using the Get-ADFSEndpoint and Set-ADFSEndpoint CMDlets.

The default list of Endpoints in ADFS is shown below

Get-ADFSEndpoint | Sort-Object FullUrl | FT ClientCredentialType,Enabled,FullUrl,Protocol -auto

image111111_thumb2_thumb1

Figure 1: Default List Of Endpoints In ADFS v2.0

-

Claims Descriptions can be configured manually through the ADFS v2.0 MMC or through PowerShell using the Get-ADFSClaimDescription, Add-ADFSClaimDescription and Set-ADFSClaimDescription CMDlets.

The default list of claims descriptions in ADFS is shown below

Get-ADFSClaimDescription | Sort-Object ClaimType | FT ClaimType,Name,IsAccepted,IsOffered -auto

image11111_thumb3_thumb1

Figure 2: Default List Of Claims Descriptions In ADFS v2.0

-

Using a PowerShell script I imported my own defined list of claims descriptions. The total list now looks like is shown below.

image612_thumb2_thumb1

Figure 3: Total List Of Claims Descriptions In ADFS v2.0 (Default And Custom)

-

For the next part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 6)

-

Cheers,

Jorge

---------------------------------------------------------------------------------------------

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/

---------------------------------------------------------------------------------------------

############### Jorge's Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

---------------------------------------------------------------------------------------------

Posted in Active Directory Federation Services (ADFS), Sharepoint Server | 1 Comment »

(2012-09-17) Claims Based Authorizations For Sharepoint Through ADFS (Part 4)

Posted by Jorge on 2012-09-17


-

For the previous part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 3)

-

Now, we can deploy the webpart that will show us the issued claims within the SP2010 Web Application.

Add-SPSolution "D:\_DEMO\SP2010\Claims-Viewer-WebPart-For-SharePoint2010\bin\Debug\Claims_Viewer_WebPart_For_SharePoint2010.wsp" Install-SPSolution –Identity "Claims_Viewer_WebPart_For_SharePoint2010.wsp" –WebApplication https://app-claims.adcorp.lab:446/ -GACDeployment Get-SPFeature | Where{$_.SolutionId -eq "965849d4-f447-43ad-8136-e1a02b5a1bc0"} | FL Get-SPWeb https://app-claims.adcorp.lab:446/ Enable-SPFeature "Claims-Viewer-WebPart-For-SharePoint2010_Feature1" -URL https://app-claims.adcorp.lab:446/

-

The output of that all can be seen in the picture below.

image5311_thumb3_thumb1

Figure 1: Deploying The Webpart To The Previously Created Sharepoint 2010 Web Application

-

For more information about deploying/removing a solution package in SharePoint 2010, see: SharePoint 2010 Cookbook: How to Deploy or Remove a Solution Package Using PowerShell Commands and Installing or Uninstalling Features. If you are removing a solution in addition navigate to “http://<site FQDN>/_catalogs/wp/” (https://app-claims.adcorp.lab:446/_catalogs/wp/) and delete the remaining component of the web part (only the one matching the name you removed previously). If you do not perform this step, the webpart will still be listed in Sharepoint webpart gallery, but you cannot use it!

-

So, open up internet explorer and navigate to “https://app-claims.adcorp.lab:446/” and:

  • Click on “Site Actions” –> “Site Settings”
  • Click on “Site Collection Features” (you may need to scroll down first!)
  • Confirm that you are seeing the deployed webpart and that its status is ACTIVE

image1111111_thumb2_thumb1

Figure 2: The Deployed Webpart With Status Being Active

-

  • Click on “Site Actions” –> “New Site Page”
  • Enter the name “Issued Claims List”

image7_thumb3_thumb1

Figure 3: Creating A New Site Page

-

  • In the recently modified section click “Issued Claims List”
  • Click on “Editing Tools – Insert”
  • Click on “WebPart”
  • Select the CUSTOM category
  • Select the custom webpart called “Claims Viewer WebPart For SharePoint 2010”
  • Click Add

image12_thumb2_thumb1

Figure 4a: Adding The WebPart To The Previously Created Web Page

-

  • Click on "the “Save” icon

image201_thumb2_thumb1

Figure 4b: The WebPart Added To The Previously Created Web Page

-

image24_thumb2_thumb1

Figure 5: Adding The Issued Claims List Web Page To The Quick Launch

-

  • Click on “Home”

You should now see web page under the Libraries section.

image29_thumb2_thumb1

Figure 6: Libraries Section With The Issued Claims List Web Page

-

  • Click on “Issued Claims List”

image331_thumb3_thumb1

Figure 7: The Issued Claims Within Sharepoint 2010

-

Now you may think….”Why is SP2010 using claims while we are using a Windows based account/ID?” The reason for that is that SP2010 internally works with claims, no matter what! If you look at the OriginalIssuer column you will see for a lot of the claims “Windows” as that is where the information originated from!

-

We now need to reconfigure the web application to use the previuosly configured ADFS authentication provider.

So, start the Sharepoint 2010 Central Administration Web Site and

  • Click on “Central Administration” –> “Manage Web Applications”
  • Click on the Web Application with name “Claims Based Web Application”
  • Click on “Authentication Providers”
  • Click on the “Default Zone”
  • Scroll to the “Claims Authentication Types” section
  • UNcCheck “Integrated Windows Authentication”
  • UNcheck “Enable Windows Authentication”
  • Check “Trusted Identity Provider”
  • Check “ADCORP ADFS v2 STS”
  • Scroll down and click SAVE and close the remaining window

image401_thumb2_thumb1

Figure 8: Reconfiguring The Sharepoint 2010 Claims Based Web Application To Accept Claims From the Trusted Authentication Provider

-

To be able to log on to the Web Application now it is also important to temporarily change the site collection administration to a federated claims ID instead of the temporarily configured Windows AD account/ID.

So, if not already started, start the Sharepoint 2010 Central Administration Web Site and

  • Click on “Application Management” –> “Change site collection administrators”
  • You will an error specifying: “This page contains one or more errors. Fix the following before continuing: No exact match was found. Click the item(s) that did not resolve for more options”
  • Make sure the site collection specifies: “https://app-claims.adcorp.lab:446/
  • Remove any value specified in the Primary Site Collection Administrators and click on the address book icon to the right of that field
  • Enter ADM.ROOT@ADCORP.LAB (=email address as that has been defined as the identity claim during the creation of the authentication provider) in the FIND field and click on the search button
  • Select the E-mail Address node and the click on the user that was found and then click OK
  • Click OK

image431_thumb2_thumb1

Figure 9: Reconfiguring The Primary Site Collection Administrator To Be A federated claims ID

-

For the next part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 5)

-

Cheers,

Jorge

---------------------------------------------------------------------------------------------

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/

---------------------------------------------------------------------------------------------

############### Jorge's Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

---------------------------------------------------------------------------------------------

Posted in Active Directory Federation Services (ADFS), Sharepoint Server | 1 Comment »

(2012-09-16) Claims Based Authorizations For Sharepoint Through ADFS (Part 3)

Posted by Jorge on 2012-09-16


-

For the previous part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 2)

-

The federation related part of sharepoint is done! Let’s now create the Web Application/Site. First I’m going to collect the credentials of the AD user account that will be used by the application as the applicationpool account , then I’m going to create a managed account in SP2010 based upon the previously mentioned AD user account, which by the way must be enabled, and finally I will specify the URL and port port for the Web Application/Site.

# Define The Application Pool Account $account1 = $ENV:USERDOMAIN + "\SVC_R1_WebAppClaims1" Write-Host $account1 Start-Sleep -s 10 $cred1 = Get-Credential New-SPManagedAccount -Credential $cred1 # Define The Web Application URL $webappurl1 = "https://app-claims.adcorp.lab" $port1 = "446"

-

The output of that all can be seen in the picture below.

image301_thumb2_thumb1

Figure 1a: Defining And Creating A Managed Account Within Sharepoint 2010

-

image39_thumb2_thumb1

Figure 1b: Defining And Creating A Managed Account Within Sharepoint 2010 And Defining The URL And Port Of The Web Application

-

Now let’s go crazy and create a sharepoint 2010 web application and the site collection

# Create The Web Application - Claims Based $webapp1 = New-SPWebApplication -name "Claims Based Web Application" -SecureSocketsLayer -ApplicationPool "Sharepoint App Claims Based" -ApplicationPoolAccount $account1 -Url $webappurl1 -Port $port1 -AuthenticationProvider $AuthNProvider1 -DatabaseName "SharePoint_WebAppClaimsBased" $webapp1 # Create The Claim Object For The Site Collection Administrator $claim1 = New-SPClaimsPrincipal -TrustedIdentityTokenIssuer $AuthNProvider1 -Identity "$ENV:USERNAME@$ENV:USERDNSDOMAIN" $claim1 # Create The Site Collection $site1 = New-SPSite $webappurl1':'$port1 -Name "Claims Based Web Site" -OwnerAlias $claim1.ToEncodedString() -template "STS#0" $site1

-

The output of that all can be seen in the picture below.

image441_thumb3_thumb1

Figure 2: Creating The Web Application And The Site Collection Within Sharepoint 2010

-

Now let’s configure the correct SPN on the AD user account used within the Application Pool for the previously created Web Application.

image58_thumb2_thumb1

Figure 3: Configuring The SPN On The AD User Account Used Within The Application Pool

-

Before starting to go crazy and throw claims against SP2010 we still need to configure other stuff. To see which claims SP2010 has accepted/used I want to deploy a webpart into SP2010 for my Claims Based Web Application. The webpart I’m using is based upon the following blog post: How To Create a Claims Viewer Web Part for SharePoint 2010.

However, at this point ADFS is still not configured, so I cannot authenticate against the SP 2010 Web Application using claims to deploy the webpart. Because of that I’m going to reconfigure the web application to temporarily accept Windows Based Authentication leveraging the Kerberos protocol.

So, start the Sharepoint 2010 Central Administration Web Site and

  • Click on “Central Administration” –> “Manage Web Applications”
  • Click on the Web Application with name “Claims Based Web Application”
  • Click on “Authentication Providers”
  • Click on the “Default Zone”
  • Scroll to the “Claims Authentication Types” section
  • Check “Enable Windows Authentication”
  • Check “Integrated Windows Authentication”
  • Select “Negotiate (Kerberos)”
  • UNcheck “ADCORP ADFS v2 STS”
  • UNcheck “Trusted Identity Provider”
  • Scroll down and click SAVE and close the remaining window

-

image491_thumb2_thumb1

Figure 4: Temporarily Reconfiguring The Sharepoint 2010 Claims Based Web Application To Accept Windows Based Authentication

-

To be able to log on to the Web Application it is also important to temporarily change the site collection administration to a Windows AD account instead of the configured claims ID.

So, if not already started, start the Sharepoint 2010 Central Administration Web Site and

  • Click on “Application Management” –> “Change site collection administrators”
  • You will an error specifying: “This page contains one or more errors. Fix the following before continuing: No exact match was found. Click the item(s) that did not resolve for more options”
  • Make sure the site collection specifies: “https://app-claims.adcorp.lab:446/
  • Remove any value specified in the Primary Site Collection Administrators and click on the address book icon to the right of that field
  • Enter ADM.ROOT in the FIND field and click on the search button
  • Select the Active Directory node and the click on the user that was found and then click OK
  • Click OK

image62_thumb2_thumb1

Figure 5: Temporarily Reconfiguring Primary Site Collection Adinistrator To Be A Windows Based Account/ID

-

For the next part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 4)

-

Cheers,

Jorge

---------------------------------------------------------------------------------------------

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/

---------------------------------------------------------------------------------------------

############### Jorge's Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

---------------------------------------------------------------------------------------------

Posted in Active Directory Federation Services (ADFS), Sharepoint Server | 1 Comment »

(2012-09-15) Claims Based Authorizations For Sharepoint Through ADFS (Part 2)

Posted by Jorge on 2012-09-15


-

For the previous part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 1)

-

Now I’m going to define the claims within SP2010 that the trusted ADFS STS is able to issue for SP2010. SP2010 will be made aware of these claims when creating the authentication provider within SP2010 later on. By the way, the claims shown as specific to my environment and most likely may not, or even are not, used within your own environment. Before continuing with the PowerShell code below, make sure to start the Sharepoint Management Shell first.

# Define The Identity Claims To Identify The User $map1 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "Email Address" –SameAsIncoming $map2 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -IncomingClaimTypeDisplayName "Logon uPNAccount" –SameAsIncoming $map3 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname" -IncomingClaimTypeDisplayName "Logon sAMAccount" –SameAsIncoming $map4 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname" -IncomingClaimTypeDisplayName "First Name" –SameAsIncoming $map5 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname" -IncomingClaimTypeDisplayName "Last Name" –SameAsIncoming $map6 = New-SPClaimTypeMapping -IncomingClaimType "http://temp.org/displayname" -IncomingClaimTypeDisplayName "Display Name" –SameAsIncoming $map7 = New-SPClaimTypeMapping -IncomingClaimType "http://temp.org/adobjectdn" -IncomingClaimTypeDisplayName "AD Distinguished Name" –SameAsIncoming $map8 = New-SPClaimTypeMapping -IncomingClaimType "http://temp.org/windowsdomainnamenetbios" -IncomingClaimTypeDisplayName "Windows Domain Name (NBT)" –SameAsIncoming $map9 = New-SPClaimTypeMapping -IncomingClaimType "http://temp.org/windowsdomainnamefqdn" -IncomingClaimTypeDisplayName "Windows Domain Name (FQDN)" –SameAsIncoming $map10 = New-SPClaimTypeMapping -IncomingClaimType "http://temp.org/company" -IncomingClaimTypeDisplayName "Company" –SameAsIncoming $map11 = New-SPClaimTypeMapping -IncomingClaimType "http://temp.org/objectstatus" -IncomingClaimTypeDisplayName "Object Status" –SameAsIncoming # Define The AuthZ Claims $map12 = New-SPClaimTypeMapping -IncomingClaimType "http://temp.org/authzbyorg" -IncomingClaimTypeDisplayName "Global AuthZ By Org" –SameAsIncoming $map13 = New-SPClaimTypeMapping -IncomingClaimType "http://temp.org/authzforappclaims" -IncomingClaimTypeDisplayName "AuthZ For App (Claims)" –SameAsIncoming # Define The Role Claim To Be Used For Authorizations Within SP2010 $map14 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" –SameAsIncoming # Define The Source/Target Location Claims As Introduced In ADFS v2.0 Rollup Package 1 # (Also See: http://jorgequestforknowledge.wordpress.com/2011/10/24/configuring-the-new-five-claim-types-in-adfs-after-installing-rollup-package-1-for-adfs-v2-0/) $map15 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy" -IncomingClaimTypeDisplayName "Through Proxy" –SameAsIncoming $map16 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip" -IncomingClaimTypeDisplayName "Client IP" –SameAsIncoming $map17 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path" -IncomingClaimTypeDisplayName "Endpoint Absolute Path" –SameAsIncoming $map18 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent" -IncomingClaimTypeDisplayName "Client User Agent" –SameAsIncoming $map19 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application" -IncomingClaimTypeDisplayName "Client Application" –SameAsIncoming # Define The Targeted Application Claim $map20 = New-SPClaimTypeMapping -IncomingClaimType "http://temp.org/targetedapp" -IncomingClaimTypeDisplayName "Targeted Application" –SameAsIncoming

-

The output of that all can be seen in the picture below.

image61111_thumb2_thumb1

Figure 1: Defining All The Claims That Can Be Used Within Sharepoint 2010 When Send From The Trusted ADFS STS

-

Now I’m going to define the federation service identifier (realm) that defines the application within both SP 2010 and ADFS v2.0 and finally I will define the sign-in URL within ADFS v2.0. SP2010 will be made aware of these claims when creating the authentication provider within SP2010 later on. By the way, federation service identifier is case-sensitive, so do not shoot yourself in the foot by making it complicated. Choose either case and use that. If you need to specify the same name in multiple locations and you use different cases, then you will be troubleshooting after that, because it will not work. I have learned myself to use lower-case.

# Import The ADFS Snap-In Add-PSSnapin Microsoft.Adfs.PowerShell # Get The ADFS Service Name $adfsServiceName = (Get-ADFSProperties).HostName.ToLower() $adfsServiceName # Get The Passive Federation Address Within ADFS $adfsFedPassiveAddress = (Get-ADFSProperties).FederationPassiveAddress $adfsFedPassiveAddress # Define The Realm For Sharepoint That Identifies It Within Sharepoint And ADFS $realm = "urn:app:sharepointclaimsapp" # Define The Signin URL $signInUrlADFS = "https://" + $adfsServiceName + $adfsFedPassiveAddress $signInUrlADFS

-

The output of that all can be seen in the picture below.

image1411_thumb2_thumb1

Figure 2: Defining Federation Service ID For The Claims Based Web Application And The Sign-In URL Within ADFS

-

Now with all that information it is time to define the trusted authentication provider within SP2010.

# Create the new authN provider within sharepoint $AuthNProvider1 = New-SPTrustedIdentityTokenIssuer -Name "ADCORP ADFS v2 STS" -Description "Secured By ADFSv2 @ ADCORP" –Realm $realm -ClaimsMappings $map1,$map2,$map3,$map4,$map5,$map6,$map7,$map8,$map9,$map10,$map11,$map12,$map13,$map14,$map15,$map16,$map17,$map18,$map19,$map20 -ImportTrustCertificate $ADFSTokenSigningCertSP2010 -SignInUrl $signInUrlADFS -IdentifierClaim $map1.InputClaimType # Get the configured provider in Sharepoint Get-SPTrustedIdentityTokenIssuer

-

The output of that all can be seen in the picture below.

image25_thumb2_thumb1

Figure 3: Creating The Trusted Authentication Provider Within Sharepoint 2010

-

REMARK: if you have multiple SP2010 Web Application supporting claims you need to define their identifier. To read how to do this see either http://blogs.technet.com/b/speschka/archive/2010/04/27/how-to-create-multiple-claims-auth-web-apps-in-a-single-sharepoint-2010-farm.aspx or http://blog.auth360.net/2011/03/28/adding-multiple-claims-aware-web-applications-to-a-sharepoint-2010-farm/ 

-

For the next part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 3)

-

Cheers,

Jorge

---------------------------------------------------------------------------------------------

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/

---------------------------------------------------------------------------------------------

############### Jorge's Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

---------------------------------------------------------------------------------------------

Posted in Active Directory Federation Services (ADFS), Sharepoint Server | 1 Comment »

(2012-09-14) Claims Based Authorizations For Sharepoint Through ADFS (Part 1)

Posted by Jorge on 2012-09-14


I have been wanting to create this post for quite a long time. Reason for that is that when I started to learn about working with ADFS v2.0 I tried this by leveraging federated webSSO against a Sharepoint 2010 Web Application/Site. For me at that time, it was not easy and finding information on the internet on how to achieve this was also not easy. Lots of blog posts provided information, but were at some point lacking important steps or information. Because of that I want to post an end-to-end blog post and save somebody else from the exact same painful experience if you are trying to learn about ADFS v2.0 with for example Sharepoint 2010 as a Relying Party Claims Based Application. So here goes and have fun! Oh, by the way, I’m far from a Sharepoint 2010 specialist! Smile So, if you have comments about that, feel free to use the comments section to say whatever you want to say. Oh, heck I don’t care. Whatever you want to comment on, go ahead and do so so that everybody is able to learn from it!

This explanation assumes everything is installed on one box! If stuff is separated on different boxes, then some of the scripts may need to be changed accordingly. With the information I’m already giving you, that’s therefore something for you to figure out!

So, stay tuned as I will post this in different parts for the next few days! Have fun!

-

One thing that really surprised me, and you will hit it like me if you do not know about it, is that Sharepoint 2010 (SP2010) does not leverage the certificate stores in Windows. For whatever reason it has its own “Trusted Root CA Store”. Because of that, when a user presents a security token from the ADFS STS and signing by its own token signing certificate, SP2010 will wine about not trusting the token signing certificate from ADFS, although the corresponding root CA certificate indeed is in the Trusted Root Certificate Authorities on the Windows Server. So, to make SP2010 stop wining about this, you must import the root CA certificate into SP2010 own trusted root CA store.

So, first I will export the trusted root CA from Trusted Root Certificate Authorities on the Windows Server and write that to a file. Then I will read the certificate file and import it into SP2010 and of course check the trusted root CA actually is there. By the way, do not forget to change the paths and the name of your trusted root CA!

You can use the following PowerShell commands, but first make sure to start the Sharepoint Management Shell:

# Export The Trusted Root CA Certificate From The Windows Trusted Root Certificate Authorities Store $rootCACert = dir cert:\LocalMachine\CA | where {$_.Subject -eq "CN=MY-ROOT-PKI, DC=ADCORP, DC=LAB"} $rootCACert $rootCABytesCER = $rootCACert[0].export("Cert") # Write The Trusted Root CA Certificate To A File [system.IO.file]::WriteAllBytes("D:\_DEMO\SP2010\RFSRWDC1.ADCORP.LAB_MY-ROOT-PKI.CER", $rootCABytesCER) # Import The Trusted Root CA Certificate Into Sharepoint 2010 $rootCACertSP2010 = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("D:\_DEMO\SP2010\RFSRWDC1.ADCORP.LAB_MY-ROOT-PKI.CER") $trustedRootCAuth = New-SPTrustedRootAuthority -Name "Trusted Root CA Certificate - PKI-ROOT-ADCORP" -Certificate $rootCACertSP2010 Get-SPTrustedRootAuthority | Select DisplayName

-

The output of that all can be seen in the picture below.

image

Figure 1: Importing The Trusted Root CA Certificate Into Sharepoint 2010

-

Now I’m going to export the Token Signing Certificate used by ADFS v2.0 so that it is recognized by SP2010 as the Token Signing Certificate of the STS trusted by SP2010. SP2010 will be made aware of this certificate when creating the authentication provider within SP2010 later on.

# Export The ADFS Token Signing Certificate From The Computer's Personal Store $ADFSTokenSigningCert = dir cert:\LocalMachine\My | where {$_.FriendlyName -eq "Token Signing Cert For ADFS-STS"} $ADFSTokenSigningCert $ADFSTokenSigningBytesCER = $ADFSTokenSigningCert.export("Cert") [system.IO.file]::WriteAllBytes("D:\_DEMO\SP2010\FS.ADCORP.LAB.STS.TOKEN.SIGNING.CER", $ADFSTokenSigningBytesCER) $ADFSTokenSigningCertSP2010 = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("D:\_DEMO\SP2010\FS.ADCORP.LAB.STS.TOKEN.SIGNING.CER")

-

The output of that all can be seen in the picture below.

image

Figure 2: Exporting The Token Signing Certificate Used By ADFS From The Personal Certificate Store Of The Computer

-

If you have paid close attention you have noticed that the token signing certificate is from an internal PKI environment and therefore not self-signing. BUT… what if the token signing certificate indeed is self-signed and you are leveraging ADFS automatic certificate rollover? In that case you will not be able to export the self-signed certificate as it is not stored in the personal store of the computer, but rather in the ADFS Configuration database. I have not found a way to export that certificate from the database, BUT… there is a way to export it though! As you may remember, all certificates used by ADFS are listed in the federation metadata of the federation service! Therefore if you target the federation service you can get the token signing certificate used by ADFS. This applies to whatever certificate type you used (external PKI, internal PKI, self-signed). Something to be aware is that you need to target the correct section in the federation metadata and the certificate information is stored in Base64 format. So you have to decode that to bytes and save to a file. See the PowerShell below to see how to do that!

# Load The ADFS Snap-in And Get The Current Directory Add-PSSnapin Microsoft.Adfs.Powershell $CurrentDir = (Get-Location).Path # Get The ADFS Federation Metadata URL $ADFSFederationMetadataURL = (Get-ADFSEndpoint | ?{$_.Protocol -eq "Federation Metadata"}).FullUrl.ToString() # Get The ADFS Federation Service Name/FQDN $ADFSServiceName = (Get-ADFSProperties | Select HostName).HostName # Define The File Name That Will Store The Federation Metadata $ADFSFederationMetadataXMLFile = "$CurrentDir\$ADFSServiceName_FederationMetadata.xml" # Download The Federation Metadata From The Specified URL And Save In The Defined XML File $WebClient = New-Object System.Net.WebClient $WebClient.DownloadFile($ADFSFederationMetadataURL, $ADFSFederationMetadataXMLFile) # Get The Content From The XML File $ADFSFederationMetadataXMLFileContent = [xml](Get-Content -Path $ADFSFederationMetadataXMLFile) # Get The Base64 Encoded Version Of The Token Signing Certificate $ADFSTokenSigningCertBase64 = ($ADFSFederationMetadataXMLFileContent.EntityDescriptor.RoleDescriptor | ?{$_.type -eq "fed:SecurityTokenServiceType"}).KeyDescriptor.KeyInfo.X509Data.X509Certificate # Convert The Base64 Format Into Bytes Format $ADFSTokenSigningCertBytes = [System.Convert]::FromBase64String($ADFSTokenSigningCertBase64) # Write The Bytes To A Certificate File [system.IO.file]::WriteAllBytes("$CurrentDir\$ADFSServiceName.STS.TOKEN.SIGNING.CER", $ADFSTokenSigningCertBytes)

-

The output of that all can be seen in the picture below.

image

Figure 3: Exporting The Token Signing Certificate Used By ADFS From The Federation Metadata

-

For the next part click on the following link: Claims Based Authorizations For Sharepoint Through ADFS (Part 2)

-

Cheers,

Jorge

---------------------------------------------------------------------------------------------

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/

---------------------------------------------------------------------------------------------

############### Jorge's Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

---------------------------------------------------------------------------------------------

Posted in Active Directory Federation Services (ADFS), Sharepoint Server | 2 Comments »

 
%d bloggers like this: