(2019-02-07) People Picker Error In Sharepoint 2013

From time to time I fully update my test/demo environment to make sure all the installed stuff uses the latest available features for those versions. And yes, I’m still running some old versions because I need the basic functionality for some things to work and do not need the latest and greatest. Because I’m still running everything on a server on-premises, yes those people still exist, I need to careful will the latest and greatest apps behaving as resource hogs. And that’s why I’m still running Sharepoint Foundation 2013. At the same time while updating I some times also try out stuff just to see if things are still working. This blog is basically more about archiving this piece of information from my brain the next time it happens so I do not forget it.

This time, even as a Site Collection administrator, I was not able to navigate to the site or assign permissions to some AD group or user.

In the first case, I saw the error “Sorry, You Don’t Have Access To This Page”. For me that was quite surprising as by default Site Collection admin have Full Control.

this

Figure 1: Error “Sorry, You Don’t Have Access To This Page”

–

Browsing to the settings page to assign permissions, using a direct URL (“https://<FQDN>:<PORT>/_layouts/15/settings.aspx”)as navigation was not possible. While trying to assign permissions to a group, the group could not be resolved and it showed the error “Sorry, We’re Having Trouble Reaching The Server”

Figure 2: Error “Sorry, We’re Having Trouble Reaching The Server” While Resolving A Security Principal

–

I googled around and noticed I was not the only one having this issue. After trying a number of solutions, the only solution that really worked for me was extending the web application and when done unextending it again.

To extend a web application:

• On the Sharepoint Server start a browser and navigate to the Central Administration site
• On the Central Administration site in the Application Management section  click “Manage Web Applications”
• Select the web application that is not working due to the errors above and in the ribbon click “Extend”
• Make sure the option “Create A New IIS Web Site” is selected
• Check all the other settings and see if those do not conflict with any other web application on the same box, and when OK click “OK” at the bottom
• After letting the system finish the extension of the web application, try to assign permissions again

…and if correct you should now be able to resolve security principals from AD.

Figure 3: Resolving A Security Principal From AD Now Does Work

–

After confirming, it is working again, you can UNextend the web application again.

To UNextend a web application:

• On the Sharepoint Server start a browser and navigate to the Central Administration site
• On the Central Administration site in the Application Management section  click “Manage Web Applications”
• Select the web application that was previously extended for which you want to delete the extension
• On the ribbon, just below the “Extend” button click on the tiny arrow and select “Remove Sharepoint from IIS Web Site”
• Select the correct extension to delete
• Make sure to delete the IIS Web Site too

You should be good now. At least I was!

–

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Advertisement

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

–

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!

Figure 1: The User Leveraging Forms Based Authentication

–

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

• ADFS 2 Sharepoint 2010 Signout
• ADFS 2 SharePoint 2010 Signout
• Signout issue from Claim enabled Site in SharePoint 2010 with adfs 2.0
• Setting the Login Token Expiration Correctly for SharePoint 2010 SAML Claims Users

–

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

• Make Sure You Know This About SharePoint 2010 Claims Authentication – Sticky Sessions Are REQUIRED

–

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

• Configuring SharePoint 2010 and ADFS v2 End to End
• Configuring Claims Based Authentication for SharePoint with AD FS 2.0
• UPDATED: How To Add ADFS 2.0 as a Federated Identity Provider in SharePoint 2010
• Real World Claims Part 1: Prelude to a SharePoint Presentation
• Real World Claims Part 2: Begin at the Beginning – Provision the ADFS and SharePoint Demo Environment
• Real World Claims Part 3: Setting Up the Demo Web Sites
• Real World Claims Part 4: Configuring ADFS and SharePoint STS
• SharePoint 2010 and ADFS 2.0 the complete Step-by-Step guide
• SharePoint 2010 and ADFS 2.0 Setup
• Claims Based Authentication using ADFS 2.0
• Implementing Claims-Based Authentication with SharePoint Server 2010 

–

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

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

–

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.

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

–

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

–

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:

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: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

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

–

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.

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

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.

 

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

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.

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

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: https://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

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

———————————————————————————————

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

–

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”.

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)

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 >”

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 >”

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 >”.

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).

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 >”.

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 >”.

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 >”.

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.

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"

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

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: https://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

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

———————————————————————————————

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

–

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:

• (2011-09-13) Bare Minimum Acceptance Transform Rules For The Default Claims Provider Trusts In ADFS v2.0
• (2011-10-24) AD FS 2.0 Claims Rule Language Primer From The ASKDS Team
• (2011-10-24) Configuring The New Five Claim Types In ADFS After Installing Rollup Package 1 For ADFS v2.0

–

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

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.

 

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

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: https://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

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

———————————————————————————————

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

–

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

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

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.

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: https://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

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

———————————————————————————————

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

–

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.

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

Figure 2: The Deployed Webpart With Status Being Active

–

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

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

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

–

• Click on "the “Save” icon

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

–

• Click on “Home”
• Click on “Site Pages”
• Click on “Issued Claims List”
• Copy the URL of the webpage (e.g. https://app-claims.adcorp.lab:446/SitePages/Issued%20Claims%20List.aspx)
• Click on “Home”
• Click on “Customize The Quick Launch” (you may need to scroll down)
• Click on “Navigation Link”
• In the “Type the web address” field enter (without the quotes) “https://app-claims.adcorp.lab:446/SitePages/Issued%20Claims%20List.aspx”
• In the “Type the description” field enter (without the quotes) “Issued Claims List”
• Select the LIBRARIES heading
• Click OK

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.

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

–

• Click on “Issued Claims List”

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

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

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: https://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

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

———————————————————————————————

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

–

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.

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

–

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.

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.

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

–

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

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: https://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

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

———————————————————————————————

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

–

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: https://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.

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.

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.

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: https://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

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

———————————————————————————————