ID4223: The SamlSecurityToken is rejected because the SamlAssertion.NotOnOrAfter Condition is not satisfied

Sathish Nadarajan
 
Solution Architect
April 7, 2014
 
Rate this article
 
Views
26108

Today I was facing a strange issue when I opened my Development Site. Hence thought of sharing to the community.

The scenario here is, we are using 2 Servers for our development purpose. One is Windows Server 2012 on which the SharePoint 2013 has been installed. The other one is Windows Server 2008 R2, that we are using for the ADFS authentication.

Somehow, the time on the Windows Server 2008 R2 has been modified. (Not sure how it happened and that’s not our problem also). I tried login to the SharePoint Dev Site and I was getting the strange exception as mentioned on the title of this article. The exact exception and the trace are as follows.

clip_image002

I was little bit worried about this. But the solution was so simple.

1. Go to the Services.msc on the ADFS Server on which the time was not correct.

2. Find the “Windows Time” Service.

3. Restart the Service.

4. Do an IISRESET on both the servers.

5. Refresh the Dev Site.

6. SURPRISE… It worked like charm.

(If required, open the command prompt and type w32tm /resync. But I didn’t do this.)

And one thing I noticed is, as soon as I restarted the service, the time on the ADFS Server corrected automatically.

Happy Coding.

Sathish Nadarajan.

Category : SharePoint

Author Info

Sathish Nadarajan
 
Solution Architect
 
Rate this article
 
Sathish is a Microsoft MVP for SharePoint (Office Servers and Services) having 15+ years of experience in Microsoft Technologies. He holds a Masters Degree in Computer Aided Design and Business ...read more
 

How to Provide Custom Attribute as a Claim from ADFS in SharePoint 2013 using PowerShell

Sathish Nadarajan
 
Solution Architect
March 9, 2014
 
Rate this article
 
Views
39753

In the previous article, we saw how to add custom attributes to the Active Directory. In this article, let us see, how to use those attributes as Claims through ADFS. Adding claims to ADFS, already we saw as a part of Configuring ADFS as authentication provider here. Please refer that, if not read already.

To refresh, we added maritalStatus as an attribute on the previous article. On our sharepoint site, we want, this maritalStatus as a Claim after login into the Site.

Now, the steps are

1. Configure the new claims on the ADFS Server.

2. Delete the TrustedIdentityTokenIssuer.

3. Create the SPClaimTypeEncoding for the new claim value

4. Create a new TrustedIdentityTokenIssuer with the new Encoded Claim value

5. Map the SharePoint site to the newly created TrustedIdentityTokenIssuer.

Let us see them one by one.

1. Configure the new claims on the ADFS Server.

We need to Add the claim description. For that, login to the ADFS Server. Open the ADFS management console. By default, the claim description will looks like,

image

Now, we are going to Add our claim Description.

Right click on the Claim Description.

image

Click Add Claim Description.

Enter the values as below.

image

Click OK. The claim Description will get added.

Now, the screen will looks like,

image

Now, we need to add the newly added claim in the Claims Rule of the web application. i.e., the Relying party trust.

Select the Relying Party Trust, Select the web application. Edit Claim rules.

image

image

image

On the LDAP Attributes, we can type as MaritalStatus and on the Outgoing Claim Type, the drop down contains the Claim MaritalStatus, since we added it on the Active Directory. Hence, select that.

Click Ok, and close this screen.

That’s it. We are done with the ADFS Server. Now, move back to our SharePoint Server.

2. Remove the existing TrustedIdentityTokenIssuer.

 Get-SPTrustedIdentityTokenIssuer | where {$_.Name -eq "win2008r2 claims provider"} | Remove-SPTrustedIdentityTokenIssuer

3. Remove the existing TrustedRootAuthority

 Get-SPTrustedRootAuthority | where {$_.Identity -eq "Token Signing Cert ADFSAuthenticatedSite"} | Remove-SPTrustedIdentityTokenIssuer

4. Now, let us re-create everything with encoding.

 Add-PSSnapin "Microsoft.SharePoint.PowerShell"
 
 Get-SPTrustedIdentityTokenIssuer | where {$_.Name -eq "win2008r2 claims provider"} | Remove-SPTrustedIdentityTokenIssuer 
 
 Get-SPTrustedRootAuthority -Identity "Token Signing Cert ADFSAuthenticatedSite" | Remove-SPTrustedIdentityTokenIssuer
 
 
 $a = [char]0x02bc #700 - for Marital Status
 #$b = [char]0x02bd #701 - Incase if we have 2 more Claims needs to be added
 #$c = [char]0x02be #702 - Incase if we have 2 more Claims needs to be added
 
 
 New-SPClaimTypeEncoding -EncodingCharacter $a -ClaimType "http://ss.loc/maritalstatus" -force
 #New-SPClaimTypeEncoding -EncodingCharacter $b -ClaimType "http://dc07.loc/v2/jobtitle" -force - Incase if we have 2 more Claims needs to be added
 #New-SPClaimTypeEncoding -EncodingCharacter $c -ClaimType "http://dc07.loc/v2/application" -force - Incase if we have 2 more Claims needs to be added
 
 
 
 $Cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("D:WORKCertificatesADFSCert.cer")
 
 New-SPTrustedRootAuthority -Name "Token Signing Cert ADFSAuthenticatedSite" -Certificate $cert
 
 $map = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
 
 $upnClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -IncomingClaimTypeDisplayName "UPN" -SameAsIncoming
 
 $RoleClaimmap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" –SameAsIncoming
 
 $maritalStatusClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://ss.loc/maritalstatus" -IncomingClaimTypeDisplayName "MaritalStatus" -SameAsIncoming
 
 $realm="urn:sharepoint:sathishserver.ss.loc:20003"
 
 $signInURL="https://Win2008R2/adfs/ls"
 
 $sts = New-SPTrustedIdentityTokenIssuer -Name “win2008r2 claims provider” -Description “My Claims Provider”-realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$upnClaimMap,$RoleClaimmap,$maritalStatusClaimMap -SignInUrl $signInURL -IdentifierClaim $map.InputClaimType
 
 $sts 
 

5. Now, map the created TrustedIdentityToken with the web application.

In Central Administration, go to Manage web application and select the web application.

image

Select the Default.

image

On the Edit Authenticaiton screen, we can see the newly created Identity Provider.

image

Select that and click save. On the screen nothing will happen. Let us close this popup and try login to the site collection. It will ask for the ADFS authentication.

That’s it. Now, let us go back to our claims viewer web part. Now, we will be seeing the newly added attribute will be listed as the claim on the screen.image

 

Now, the newly added webpart will show the newly added claim.

 

Happy Coding.

Sathish Nadarajan.

Author Info

Sathish Nadarajan
 
Solution Architect
 
Rate this article
 
Sathish is a Microsoft MVP for SharePoint (Office Servers and Services) having 15+ years of experience in Microsoft Technologies. He holds a Masters Degree in Computer Aided Design and Business ...read more
 

How to Read claims of a User in SharePoint 2013

Sathish Nadarajan
 
Solution Architect
January 12, 2014
 
Rate this article
 
Views
28280

In this article, let us see, how to retrieve the claims of a logged in User in SharePoint 2013. To achieve that, let us create a web part, so that it would be always helpful while we develop applications, based on the Claims.

Claims are nothing but a specific information about a user. Let me give a brief background about the claims and the usage of claims. In one of our requirement, we were using ADFS for the authentication purpose. We had seen enough information about that on the previous posts. In addition to that, some of the properties needs to be configured on the Active directory itself. i.e., for example, what are the activities a user can do on our portal. That information, we kept as an Attribute on the Active Directory itself. The Attribute name can be like “Activity”. It is a multi valued text.

This Activity will be passed to the SharePoint 2013 by means of a Claim. This claim is known as Custom Claim. How to create a custom attribute and a custom claim and all, we will see on the consecutive articles. Now, let us concentrate on how to read the claims from SharePoint 2013 WebPart.

For our easiness, let us create a web part. On the CreateChildControl method, we are planning to read the claim and bind it in a grid.

The first thing, we need to do is, based on the logged in user, we need to get the IClaimsPrincipal object.

 IClaimsPrincipal cp = Page.User as IClaimsPrincipal;

Now, based on the IClaimsPrincipal, we can get the IClaimsIdentity.

 IClaimsIdentity ci = (IClaimsIdentity)cp.Identity;

Now, based on the IClaimsIdentity, we can Iterate the Claims Collection.

 foreach (Claim c in ci.Claims)
                     {
 }
 

Very Simple right. The entire Code for reading and binding it on the grid is as follows.

 protected override void CreateChildControls()
         {
             try
             {
 
                 // Get the claims
                 IClaimsPrincipal cp = Page.User as IClaimsPrincipal;
                 if (cp != null)
                 {
                     DataRow dr;
                     DataTable claimsTable = new DataTable();
                     claimsTable.Columns.Add("Type", typeof(string));
                     claimsTable.Columns.Add("Value", typeof(string));
 
                     IClaimsIdentity ci = (IClaimsIdentity)cp.Identity;
                     foreach (Claim c in ci.Claims)
                     {
                         dr = claimsTable.NewRow();
                         dr["Type"] = c.ClaimType.ToString();
                         dr["Value"] = c.Value.ToString();
                         claimsTable.Rows.Add(dr);
                     }
 
                     // Standard SPGridView to display our claims table
                     SPGridView claimsGrid = new SPGridView();
 
                     // This eventhandler is used to add the word-break style
                     claimsGrid.RowDataBound += new GridViewRowEventHandler(claimsGrid_RowDataBound);
 
                     // AutoGenerate must be false for SPGridView
                     claimsGrid.AutoGenerateColumns = false;
                     claimsGrid.DataSource = claimsTable;
 
                     SPBoundField boundField;
 
                     boundField = new SPBoundField();
                     boundField.HeaderText = "Type";
                     boundField.HeaderStyle.HorizontalAlign = HorizontalAlign.Left;
                     boundField.DataField = "Type";
                     claimsGrid.Columns.Add(boundField);
 
                     boundField = new SPBoundField();
                     boundField.HeaderText = "Value";
                     boundField.HeaderStyle.HorizontalAlign = HorizontalAlign.Left;
                     boundField.DataField = "Value";
                     claimsGrid.Columns.Add(boundField);
 
                     for (int i = 0; i < claimsGrid.Columns.Count; i++)
                     {
                         claimsGrid.Columns[i].ItemStyle.Wrap = true;
                         // Distribute the columns evenly
                         claimsGrid.Columns[i].ItemStyle.Width = Unit.Percentage(100 / claimsGrid.Columns.Count);
                     }
 
                     claimsGrid.DataBind();
 
                     this.Controls.Add(claimsGrid);
                 }
             }
             catch (Exception ex)
             {
                 this.Controls.Add(new LiteralControl(ex.Message));
             }
         }
 

Once, creating the webpart and deploy them, we will be able to see the webpart on the webpart gallery. Add the webpart to our page. The page will looks like as follows.

image

Download the source code HERE

Happy Coding.

Sathish Nadarajan.

Author Info

Sathish Nadarajan
 
Solution Architect
 
Rate this article
 
Sathish is a Microsoft MVP for SharePoint (Office Servers and Services) having 15+ years of experience in Microsoft Technologies. He holds a Masters Degree in Computer Aided Design and Business ...read more
 

How to Add more than One SharePoint 2013 WebApplication to a SPTrustedIdentityTokenIssuer on ADFS using PowerShell

Sathish Nadarajan
 
Solution Architect
December 12, 2013
 
Rate this article
 
Views
40542

In the previous posts, we saw that how to make ADFS as an Authentication Provider for our SharePoint 2013 WebApplication. But later, I faced an issue that, the Certificate which we are exporting from the ADFS Server and Creating an IssuerID and TrustedIdentityTokenIssuer cannot be changed for other WebApplications. I.e., We cannot create more than one TrustedIdentityTokenIssuer on the SharePoint Environment using the Same Certificate from the ADFS Server. At this point, there is no other option, I could find, how can I export a second certificate from the ADFS Server.

Hence, in the meanwhile, I came to a conclusion that, use the Existing TrustedIdentityTokenIssuer for the new WebApplication also. At that time, if you could see, the script to create the TrustedIdentityTokenIssuer is as follows.

 

 Add-PSSnapin "Microsoft.SharePoint.PowerShell"
 
 #Import a token signing certificate by using Windows PowerShell
 
 
 $root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:CertsSathishADFSCert.cer")
 
 
 New-SPTrustedRootAuthority -Name "Sathish Seven Token Signing Cert Parent" -Certificate $root
 
 $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:CertsSathishADFSCert.cer ")
 
 New-SPTrustedRootAuthority -Name "Sathish Seven Token Signing Cert" -Certificate $cert
 
 
 
 $realm = "urn:sharepoint:MyWebApplicationURL"
 
 
 $signInURL = "https://MyADFSServerURL/adfs/ls"
 
 
 #create an identity claim(email) mapping
 
 
 $map = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming 
 
 
 #create an identity claim(UPN) mapping
 
 
 $upnClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -IncomingClaimTypeDisplayName "UPN" -SameAsIncoming 
 
 
 #create an identity claim(Role) mapping
 
 
 $RoleClaimmap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" –SameAsIncoming 
 
 
 #creating a Trustedidentity Token Issuer
 
 
 #$ap = New-SPTrustedIdentityTokenIssuer -Name “Sathish Five Claims Provider” -Description “Sathish Identity Token Issuer” -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$upnClaimMap,$RoleClaimmap -SignInUrl $signInURL -IdentifierClaim $map.InputClaimType
 

Here the Parameter realm is attached with a particular WebApplication. What we need to do is, Add our new WebApplication URL too as a ProviderRealm. Basically, the ProviderRealm is a Set of URL Collection. There we can add more than one WebApplication URL. The pattern should “urn:sharePoint:WebApplicationURL”. The PowerShell Script to achieve this is

 Add-PSSnapin "Microsoft.SharePoint.PowerShell"
 
 $sts = Get-SPTrustedIdentityTokenIssuer | where {$_.Name -eq " Sathish Five Claims Provider "}
 
 $uri = new-object System.Uri("https://MyNewWEbApplicationURL")
 
 $uri
 
 $sts.ProviderRealms.Add($uri, "urn:sharepoint:MyNewWebApplicationURL")
 
 $sts.Update();
 
 $sts 
 

To Consolidate the above steps,

1. To make a WebApplication as a ADFS Authenticated one, we need a https enabled WebApplication. We discussed about that in this article.

2. Add the WebApplication to the RelyingParty Trust on the ADFS Server. We discussed about that in this article and here.

3. Add the WebApplicationURL to the ProviderRealms Collection of the TrustedIdentityTokenIssuer object.

4. Update and do an IISReset of the SharePoint Server. (All the front ends).

5. Change the Authentication Providers of the WEbApplication on the CentralAdministration to Claims Aware and Select the corresponding TrustedIdentityTokenIssuer.

6. Try logging in to the New WebApplication.

That’s it. We are done. Thus, we can add any number of web applications to a single TrustedIdentityTokenIssuer.

Happy Coding.

Sathish Nadarajan.

Author Info

Sathish Nadarajan
 
Solution Architect
 
Rate this article
 
Sathish is a Microsoft MVP for SharePoint (Office Servers and Services) having 15+ years of experience in Microsoft Technologies. He holds a Masters Degree in Computer Aided Design and Business ...read more
 

Creating an ADFS2.0 TrustedIdentityTokenIssuer using PowerShell in SharePoint 2013

Sathish Nadarajan
 
Solution Architect
October 1, 2013
 
Rate this article
 
Views
23657

In this article, let us see, how to create an ADFS 2.0 Trusted Identity Token Issuer (SPTrustedIdentityTokenIssuer) using PowerShell in SharePoint 2013.

In many scenarios, we require some claims based authentication for our web application. These claims based authentication can be done by using some third party tools like ADFS 2.0. Already we had enough discussions about the installation, configuration of ADFS. Hence, in this article, as a series of powershell scripts, let us focus only on the powershell portion alone.

The steps are as follows.

a. Add the Certificate to the Trusted Root Authorities.

b. Create the Claims mappings.

c. Create a variable for the realms.

d. Create a Signin URL

e. Create the New-SPTrustedIdentityTokenIssuer

And the script is as follows.

cls

Add-PSSnapin "Microsoft.SharePoint.PowerShell"

# Add the Certificate to the Trusted Root Authorities

$Cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\Certs\ADFSCert.cer")

New-SPTrustedRootAuthority -Name "Token Signing Cert ADFSAuthenticatedSite" -Certificate $cert

# Create the Claims Mappings

$map = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" –SameAsIncoming

$upnClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -IncomingClaimTypeDisplayName "UPN" –SameAsIncoming

$RoleClaimmap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" –SameAsIncoming

# Create a Realm variable

$realm="urn:sharepoint:sathishserver.ss.loc:20003"

#Create a Signin URL

$signInURL="https://Win2008R2/adfs/ls"

# Create the TrustedIdentityTokenIssuer

$ap1 = New-SPTrustedIdentityTokenIssuer -Name “XYZ” -Description “Test”-realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$upnClaimMap,$RoleClaimmap -SignInUrl $signInURL -IdentifierClaim $map.InputClaimType

· The “Name” attribute describes which authentication provider a Web application is configured for.

· The “Realm” attribute defines the realm to be used by the trusted identity token issuer.

The “ImportTrustCertificate” attribute is what is passed to the token signing certificate copied from the AD FS server in this scenario.

· The “ClaimsMappings” attribute are the claims the trusted identity token issuer will use.

The “SignInUrl” is the URL that users should be redirected to authenticate with the IP-STS. In this scenario, users authenticate with the AD FS server by using Windows integrated security, so they are redirected to the /AD FS/ls subdirectory.

· The “IdentifierClaim” attribute instructs SharePoint Server which of the claims will be the claim used to identify users. In this scenario the e-mail address is used to identify a user.

 

This seems to be very simple.  But sometime, it will kill our time like anything.  Hence, I request to follow the procedures step by step and if we make any mistake, it is very hard to revert as well as fix the issue. 

 

Happy coding.

Author Info

Sathish Nadarajan
 
Solution Architect
 
Rate this article
 
Sathish is a Microsoft MVP for SharePoint (Office Servers and Services) having 15+ years of experience in Microsoft Technologies. He holds a Masters Degree in Computer Aided Design and Business ...read more
 

Configuring ADFS as Authentication Provider For SharePoint 2013 Web Application

Sathish Nadarajan
 
Solution Architect
 
Rate this article
 
Views
57205

In the actual production environment, the Authentication of the SharePoint site is not going to be Windows authentication in many scenarios. There are various third party authentication providers are available in the market. Since ADFS is one of Microsoft’s product, It is been widely used by many of the environment. Hence, let us see how to make the Authentication of our web application using ADFS 2.0.

The overall steps are as follows.

1. Installation and Configuration of ADFS 2.0.

2. Create the web application.

3. Adding the SharePoint WebApplication URL as Third Party Relying Party.

4. Export the ADFS Certificate and Copy the same into SharePoint Machine.

5. Create a Trusted Identity Token Issuer.

6. Edit SharePoint WebApplication Authentication.

7. Verify the setup by logging into the Site.

Let us see, each step individually.

1. Installation and configuration of ADFS 2.0.

We had seen about this in the previous article. Refer here to refresh. In our case, the URL of the ADFS Server is https://win2008R2/adfs/ls.

2. Create the Web Application.

This also, we had already discussed here. To make a Claims aware web application, we need to create an https enabled web application. In our case, the URL of the Web Application is https://SathishServer.ss.loc:20003/ and the site collection is /Sites/ClaimsBasedSite.

3. Adding the SharePoint WebApplication URL as Third Party Relying Party.

This topic also, covered in a separate article. But that URL is meant for the .Net provider Hosted Application. i.e., we need to make the .Net web application also as a claims aware web application. But in our case, now we are planning to add our SharePoint WebAppliclaiton. Hence the URL should be something like,

“urn:sharepoint:SathishServer.ss.loc:20003” and https://sathishserver.ss.loc:20003/_trust/.

Let us do a fast recap by the screen shots.

clip_image002

clip_image004

clip_image006

clip_image008

clip_image010

This is where the actual difference comes. You can see the URL which I am giving. It is not the URL of the of the web application. It is appended with “_trust”.

clip_image012

Again here also, we need to add “urn:sharepoint:SathishServer.ss.loc:20003” as the Relying Party trust Identifier”. (Ignore the screen shot as the port is 20004 for different purpose).

clip_image014

clip_image016

clip_image018

clip_image020

The claim rule are similar to that of the previous post. There is no much changes on it.

4. Export the ADFS Certificate and Copy the same into SharePoint Machine.

The next step would be exporting the ADFS Token Signing Certificate.

a. Open the ADFS Management Console. And Navigate to the Certificates Node.

clip_image022

b. Select the Token-signing Certificate and click “View Certificate”

clip_image024

c. On the Details Tab, click “Copy to File…”

clip_image025

d. The wizard will get opened. Follow the wizard as shown in the screen shot.

clip_image027

clip_image028

clip_image029

clip_image030

clip_image032

clip_image034

clip_image036

clip_image038

e. With this, the Certificate has been copied to file with an extension of CER. Copy the file and paste on the SharePoint Server.

5. Create a Trusted Identity Token Issuer.

Now, we need to create a Trusted Identity Token Issuer on the SharePoint Farm. For that, the certificate copied from the ADFS Server is required to be present on the SharePoint Server. Once it is copied, we can execute the below power shell script to create the “Trusted Identity Token Issuer”.

cls

Add-PSSnapin "Microsoft.SharePoint.PowerShell"

$Cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\Certs\ADFSCert.cer")

New-SPTrustedRootAuthority -Name "Token Signing Cert ADFSAuthenticatedSite" -Certificate $cert

$map = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming

$upnClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -IncomingClaimTypeDisplayName "UPN" -SameAsIncoming

$RoleClaimmap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" –SameAsIncoming

$realm="urn:sharepoint:sathishserver.ss.loc:20003"

$signInURL="https://Win2008R2/adfs/ls"

$ap1 = New-SPTrustedIdentityTokenIssuer -Name “XYZ” -Description “Test”-realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$upnClaimMap,$RoleClaimmap -SignInUrl $signInURL -IdentifierClaim $map.InputClaimType

· The “Name” attribute describes which authentication provider a Web application is configured for.

· The “Realm” attribute defines the realm to be used by the trusted identity token issuer.

The “ImportTrustCertificate” attribute is what is passed to the token signing certificate copied from the AD FS server in this scenario.

· The “ClaimsMappings” attribute are the claims the trusted identity token issuer will use.

The “SignInUrl” is the URL that users should be redirected to authenticate with the IP-STS. In this scenario, users authenticate with the AD FS server by using Windows integrated security, so they are redirected to the /AD FS/ls subdirectory.

· The “IdentifierClaim” attribute instructs SharePoint Server which of the claims will be the claim used to identify users. In this scenario the e-mail address is used to identify a user.

 

With this, we successfully created our Trusted Identity Token Issuer. Let us see, how we can change the authentication provider of our SharePoint Web Application.

6. Edit SharePoint WebApplication Authentication.

a. Now, we created our TrustedIdenityTokenIssuer for SharePoint. Let us see, with the web application.

b. Go to the Central Administration.

clip_image040

c. Select the web application for which we need to change the Authentication Providers.

clip_image042

d. Prompted with the popup. Click the default.

clip_image044

e. Edit Authentication Popup will be shown.

clip_image045

In that, by Default, “Enable Windows Authentication” will be checked. Uncheck it and click “Trusted Identity Provider”. On the below, you can see the list of identity providers, which we created. Click that and Save.

f. That’s it. Now our Web Application is ready to get authenticated by ADFS 2.0.

7. Verify the setup by logging into the Site.

Now we can verify the authentication by login into the site. Type https://sathishserver.ss.loc:20003/Sites/ClaimsBasedSite. After entering the credentials, it will be redirected to https://win2008R2/ADFS/Ls/…… Once, it is authenticated properly, then it will come back to our web application.

8. Trouble shooting.

After following the entire steps, I was facing an issue with the ADFS Authentication. When trying to login to the site, we will be getting some weird exception like “ADFS Exception Occurred” . Normally, SharePoint itself, will not give any clear exceptions. Now again ADFS is also like that only. To see exactly what happens, login to the ADFS Server machine. And go to the EventViewer. On Application Logs, we can see an exception like “The same client browser session has made ‘6’ requests in the last ‘12’ seconds”. By doing some search in the internet, I found a useful link from Steve Psechka. http://blogs.technet.com/b/speschka/archive/2010/08/09/setting-the-login-token-expiration-correctly-for-sharepoint-2010-saml-claims-users.aspx

It was very useful and very clear about the problems. Hence, I am not repeating the points here. Let us get the extract alone. By executing the below script, I get rid of that exception.

#$sts = Get-SPSecurityTokenServiceConfig

#$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan –minutes 1)

#$sts.UseSessionCookies = $true

#$sts.Update()

#iisreset

The actual meaning for the above code can be identified from the above mentioned blog.

For our reference, I downloaded the article and the same has been attached with this post.

Author Info

Sathish Nadarajan
 
Solution Architect
 
Rate this article
 
Sathish is a Microsoft MVP for SharePoint (Office Servers and Services) having 15+ years of experience in Microsoft Technologies. He holds a Masters Degree in Computer Aided Design and Business ...read more
 

Installing and Configuring ADFS 2.0

Sathish Nadarajan
 
Solution Architect
September 26, 2013
 
Rate this article
 
Views
25325

There are many articles available on the MSDN regarding the brief background about ADFS. In this article, let us see, how to install ADFS 2.0 and configure the initial setup. Probably, ADFS will be installed on a separate server other than the SharePoint farm. In my development environment, I am using Windows Server 2012 for the SharePoint environment and on a virtual machine, installed Windows Server 2008 R2. Now we are going to install the ADFS 2.0 on Windows Server 2008 R2 machine. In this case, my machine name is WIN2008R2. Let us use this as the ADFS Server.

We can download the ADFS 2.0 installer from the link

http://www.microsoft.com/en-in/download/details.aspx?id=10909

After downloading I saved the installer on my local disk. Let us follow the steps.

Note:

Before start installing, we need to create a self signed certificate on the ADFS Server. To create a certificate from IIS, already we have a separate article. If you want to recollect, I recommend to go here and refresh yourself. Here I am assuming that, we created the Certificate and the name of the certificate is ADFSCert.cer.

I. Installation of ADFS 2.0

  1. Browse to the Physical hard drive of the AD FS sever where you have AD FS 2.0 setup.

 

clip_image002

  1. Right click the Setup and select Run as Administrator.
  2. Click Next button on ADFS 2.0 Welcome wizard to continue with the ADFS installation.

clip_image004

  1. Click on end user agreement to continue with the setup.

clip_image005

  1. Select Federation Server Role for the AD FS 2.0 installation.

clip_image007

  1. AD FS setup wizard will prompt for list of prerequisites to be installed.

clip_image009

clip_image011

clip_image013

  1. AD FS setup wizard will be completed and it will start the AD FS 2.0 management console.

clip_image015

Now the installation has been completed. Once we click the “Finish”, the Configuration Wizard will be started.

II. Configuration of ADFS 2.0

  1. Open the AD FS 2.0 Management console.

clip_image017

  1. Click AD FS 2.0 Federation Server Configuration wizard in the console.
  2. Create a new federation service in federation server configuration wizard.

clip_image019

  1. Select AD FS 2.0 Standalone federation farm in wizard.

clip_image021

  1. Select self-signed certificate that we have created (Refer Creating a Certificate for ADFS installation section) from the SSL Certificate Drop Down service in federation server configuration wizard.

clip_image023

  1. On clicking Next button, AD FS 2.0 setup will configure the below mentioned features in AD FS server.

clip_image025

  1. The status of ADFS configuration steps will be displayed in setup.

clip_image027

  1. Click close button to configure AD 2.0 federation server configuration wizard.

III. Verification of ADFS 2.0 Installation.

Use the following steps to verify AD FS 2.0 installation:

  1. On AD FS server, open Internet Explorer.
  2. Browse to the federation metadata URL.
  3. In our case the ADFS Server Name is Win2008R2 and the Metadata URL is

https://win2008r2/federationmetadata/2007-06/federationmetadata.xml

clip_image029

  1. Verify that no certificate-related warnings appear. If necessary, check your certificate and DNS settings.

 

With this, we learnt how to Install and Configure ADFS 2.0 on the Dev environment. 

Category : ADFS, SharePoint, Windows

Author Info

Sathish Nadarajan
 
Solution Architect
 
Rate this article
 
Sathish is a Microsoft MVP for SharePoint (Office Servers and Services) having 15+ years of experience in Microsoft Technologies. He holds a Masters Degree in Computer Aided Design and Business ...read more
 

Adding the Self Signed Certificate in Manage trusted of SharePoint 2013

Sathish Nadarajan
 
Solution Architect
September 17, 2013
 
Rate this article
 
Views
30072

In the previous article, we saw how to create a Self-Signed Certificate from IIS. Now, let us see how to copy it into a file and make use of it in SharePoint 2013.

1. Go to IIS

clip_image002

1. Select “Server Certificates”.

2. We will see the list of already existing certificates.

clip_image004

3. Double click the certificate

4. We will be prompted with the below popup.

clip_image006

5. On the Details Tab, there will be a link to “Copy to File…”

6. Click that one.

clip_image008

7. We will be prompted with the wizard.

clip_image010

8. Follow the below screen shots to complete the wizard. As they are self explanatory.

clip_image012

clip_image014

clip_image016

clip_image018

clip_image020

clip_image022

 

Once the export is successful, we will be able to see the Cert on the given path with an extension of *.cer.

 

Now let us have a look at how to add this certificate in to SharePoint 2013 Central Administration.

 

1. Let us go to the Central Administration

clip_image024

2. Go to the Security.

clip_image026

3. Click on the Manage Trust.

clip_image028

4. You will be able to see the existing trusted certificates.

5. Click on new.

clip_image030

6. On the Popup, enter the necessary information.

clip_image032

7. We will be able to see the certificate on the list.

clip_image034

8. Now, this certificate can be access through out your sharepoint 2013 farm.

 

With this, we came to know, how to export the file into cer and how to use that in SharePoint 2013. Let us see the exact usage of these steps in following articles.

 

Happy SharePointing…

Category : IIS, SharePoint

Author Info

Sathish Nadarajan
 
Solution Architect
 
Rate this article
 
Sathish is a Microsoft MVP for SharePoint (Office Servers and Services) having 15+ years of experience in Microsoft Technologies. He holds a Masters Degree in Computer Aided Design and Business ...read more
 

Step by Step Procedures to add a Relying Party on ADFS 2.0

Sathish Nadarajan
 
Solution Architect
April 20, 2013
 
Rate this article
 
Views
58839

In this blog post let us see how to configure the Third party relying party in the ADFS 2.0 Server. This blog post is a continuation of my previous post on Provider Hosted App for SharePoint 2013

After the deployment, if we go and launch the app, we will get the following error message on the screen.

clip_image002

By seeing the error, we can come to a conclusion that the ADFS Server which we configured for our claims cannot be accessed. This is because, when our site requests a Claim from the ADFS Server, our site needs to be added as a Relying Party on the ADFS Server. Now let us see how to add a Third party relying trust on the ADFS Server step by step.

1. Login to the ADFS Server.

2. Launch the ADFS Management Console.

clip_image004

3. On the left hand tree view, select the “Relying Party Trust”.

clip_image006

4. Right click “Relying Party Trusts” and select “Add Relying Party Trust”.

clip_image008

5. We will be prompted with the following screens.

clip_image010

6. Click on Start.

clip_image012

7. Select the “Enter data about the relying party manually” option and click next.

8. Enter the name for this relying party.

clip_image014

9. Select ADFS 2.0 and click next.

clip_image016

10. You will be prompted to browse for a Certificate to encrypt and decrypt the claims. But this is an optional. We can skip this step by pressing the Next.

clip_image018

11. After the above screen, you will be prompted to enter the relying Party url.

clip_image019

12. On the next screen, you can see the entered url will be added.

clip_image021

13. Select the Permit all users option

clip_image023

14. By this we came to the end of the steps.

clip_image025

15. Click on Next to launch the Claims rules.

clip_image027

16. On that Click “Add Rule”.

clip_image029

17. The claim rule template, by default, we can select the Send LDAP Attributes as Claims. Since we are going to use AD as our Claims supplier.

18. On the ClaimRule Name, give a name and the Attribute Store, Since we are going to use the Active Directory, choose that one.

clip_image031

19. On the mapping, let us assume for our example, we are using the E-mail Address as the LDAP Attribute and Outgoing Claim Type also as E-mail.

20. The finished wizard will look like this.

clip_image033

21. With this the configuration of ADFS has been completed.

Now go back to the Browser and Refresh the AppWeb. This will get loaded without any error.

In the next article, let us see how to fetch the Context of the SharePoint from our Provider Hosted Application.

Author Info

Sathish Nadarajan
 
Solution Architect
 
Rate this article
 
Sathish is a Microsoft MVP for SharePoint (Office Servers and Services) having 15+ years of experience in Microsoft Technologies. He holds a Masters Degree in Computer Aided Design and Business ...read more
 

Converting a Basic Provider Hosted Application into Claims Aware Provider Hosted Application in SharePoint 2013

Sathish Nadarajan
 
Solution Architect
April 12, 2013
 
Rate this article
 
Views
30104

In the previous article, we saw how to create a basic provider hosted application. In that, the Authorization and Authentication is being done by the SharePoint Farm itself. The Web Application which we created to deploy our App was a windows authenticated web application.

In this article, let us concentrate on the Authentication process. Microsoft has come up with a new utility server (ADFS) to provide the Claims through which our SharePoint application will be able to Authenticate and proceed with Authorization.

Let us have a brief introduction about ADFS Server.

ADFS Stands for Active Directory Federation Service. The current version of ADFS is 2.0. This utility can be downloaded from the Microsoft Site and can be installed on a separate Windows 2012 Server. Active Directory Federation Services is a software component developed by Microsoft that can be installed on Windows Server operating systems to provide users with Single Sign-On access to systems and applications located across organizational boundaries. It uses a claims-based access control authorization model to maintain application security and implement federated identity.

Claims based authentication is the process of authenticating a user based on a set of claims about its identity contained in a trusted token. Such a token is often issued and signed by an entity that is able to authenticate the user by other means, and that is trusted by the entity doing the claims based authentication.

It will take a separate article to describe about the ADFS and Configuring ADFS with our SharePoint Farm. I am planning to write a separate Article regarding this soon. As of now, with this brief introduction about the ADFS, let us try to convert our previous Sample Sathish.App into a Claims Aware Provider Hosted Application.

In the previous article, we saw that the SharePoint, in turn calls the IIS Server to load the .Net Applications. For our reference, refer the diagram below.

clip_image002clip_image004

Now, by introducing the ADFS Server, the architecture would be

clip_image006

The request was first sent from the User to the SharePoint Farm and the user gets authenticated from the ADFS Server. Once the authentication succeeds, then we .Net application from the IIS Server will be loaded. This is very useful in the Single Sign On Scenario.

Converting into Claims Aware is nothing but a set of changes needs to be done on the web.config file. To do that, we have a tool called Identity and Access Management Tool.

The basic web.config file will look like

 <?xml version="1.0"?>
 <!--
   For more information on how to configure your ASP.NET application, please visit
   http://go.microsoft.com/fwlink/?LinkId=169433
   -->
 <configuration>
   <!--
     For a description of web.config changes for .NET 4.5 see http://go.microsoft.com/fwlink/?LinkId=235367.
 
     The following attributes can be set on the <httpRuntime> tag.
       <system.Web>
         <httpRuntime targetFramework="4.5" />
       </system.Web>
   -->
   <system.web>
     <compilation debug="true" targetFramework="4.5"/>
     <authorization>
       <deny users="?"/>
     </authorization>
     <pages controlRenderingCompatibilityVersion="4.0"/>
   </system.web>
   <appSettings>
     <add key="ClientId" value="*************************"/>
     <add key="ClientSecret" value="***************************"/>
     <add key="ClientSigningCertificatePath" value="C:MYCERTIFICATE.pfx"/>
     <add key="ClientSigningCertificatePassword" value="********"/>
     <add key="IssuerId" value="*************************"/>
   </appSettings>
   <system.serviceModel>
     <bindings>
       <basicHttpBinding>
         <!--Used by app for SharePoint-->
         <binding name="secureBinding">
           <security mode="Transport"/>
         </binding>
       </basicHttpBinding>
     </bindings>
     <protocolMapping>
       <add binding="basicHttpBinding" scheme="https" bindingConfiguration="secureBinding"/>
     </protocolMapping>
   </system.serviceModel>
 </configuration>

Now, the steps to convert this web.config file are,

1. Go to Visual Studio and right click on the AppWeb Project.

clip_image008

2. Click on the Identity and Access Menu. You can see the following screen.

clip_image009

3. Select the ADFS2 Option and provide the necessary information.

clip_image010

4. Click OK.

5. The web.config file will be modified accordingly. The modified web.config file is as below.

 <?xml version="1.0"?>
 <!--
   For more information on how to configure your ASP.NET application, please visit
   http://go.microsoft.com/fwlink/?LinkId=169433
   -->
 <configuration>
   <configSections>
     <section name="system.identityModel" type="System.IdentityModel.Configuration.SystemIdentityModelSection, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
     <section name="system.identityModel.services" type="System.IdentityModel.Services.Configuration.SystemIdentityModelServicesSection, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
   </configSections>
 
   <!--
     For a description of web.config changes for .NET 4.5 see http://go.microsoft.com/fwlink/?LinkId=235367.
 
     The following attributes can be set on the <httpRuntime> tag.
       <system.Web>
         <httpRuntime targetFramework="4.5" />
       </system.Web>
   -->
 
   <location path="FederationMetadata">
     <system.web>
       <authorization>
         <allow users="*" />
       </authorization>
     </system.web>
   </location>
 <system.web>
     <authentication mode="None" />
     <compilation debug="true" targetFramework="4.5" />
     <authorization>
       <deny users="?" />
     </authorization>
     <pages controlRenderingCompatibilityVersion="4.0"  />
     <httpRuntime requestValidationMode="4.5" />
   </system.web>
 
   <appSettings>
     <add key="ClientId" value="*****************"/>
     <add key="ClientSecret" value="***************"/>
     <add key="ClientSigningCertificatePath" value="C:MYCERTIFICATE.pfx"/>
     <add key="ClientSigningCertificatePassword" value="******"/>
     <add key="IssuerId" value="********************"/>
 
     <add key="ida:FederationMetadataLocation" value="https://MYADFSSERVER/federationmetadata/2007-06/federationmetadata.xml" />
     <add key="ida:Issuer" value="https://MYADFSSERVER/adfs/ls/" />
     <add key="ida:ProviderSelection" value="productionSTS" />
     <add key="TrustedProviderName" value="*******" />
     <add key="MembershipProviderName" value="*********" />
     
   </appSettings>
   <!--<system.serviceModel>
     <bindings>
       <basicHttpBinding>
         --><!--Used by app for SharePoint--><!--
         <binding name="secureBinding">
           <security mode="Transport"/>
         </binding>
       </basicHttpBinding>
     </bindings>
     <protocolMapping>
       <add binding="basicHttpBinding" scheme="https" bindingConfiguration="secureBinding"/>
     </protocolMapping>
   </system.serviceModel>-->
 
   <system.webServer>
     <modules>
       <remove name="FormsAuthentication" />
       <add name="WSFederationAuthenticationModule" type="System.IdentityModel.Services.WSFederationAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
     <add name="SessionAuthenticationModule" type="System.IdentityModel.Services.SessionAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
     </modules>
   </system.webServer>
   <system.identityModel>
     <identityConfiguration>
       <audienceUris>
         <add value="https://MYApplicationServer/Sathish.AppWeb/" />
       </audienceUris>
       <issuerNameRegistry type="System.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
         <trustedIssuers>
           <add thumbprint="6C2AE960AE2DD919F000BC8C2E9E5FD4A991FF64" name="http://MYADFSSERVER/adfs/services/trust" />
         </trustedIssuers>
       </issuerNameRegistry>
     </identityConfiguration>
   </system.identityModel>
   <system.identityModel.services>
     <federationConfiguration>
       <cookieHandler requireSsl="false" />
       <!--<cookieHandler requireSsl="true" path="/" />-->
 
    <wsFederation passiveRedirectEnabled="true" issuer="https://MYADFSSERVER/adfs/ls/" realm="https://MYAppServer/Sathish.AppWeb/" requireHttps="false" />
     </federationConfiguration>
   </system.identityModel.services>
   
 </configuration>

6. The same changes can be done without using the Identity and Access Tool too. Basically, we need to modify the web.config to tell the compiler that this is coming from the ADFS Server.

7. I would recommend to go with updating the web.config manually instead of relying on the Identity and Access Tool as it may not allow you to save your changes at the first time.

8. Now we are ready with our claims aware provider hosted application.

9. The last step we need to do is, add our .Net Application as the relying party trust on ADFS Server. That I will be covering on the Next Article.

Thanks for your patience to read this article. Hope this article would be very useful of creating a basic and claims aware provider hosted applications. Let me trigger the next articles over the period of time. Happy coding.

Author Info

Sathish Nadarajan
 
Solution Architect
 
Rate this article
 
Sathish is a Microsoft MVP for SharePoint (Office Servers and Services) having 15+ years of experience in Microsoft Technologies. He holds a Masters Degree in Computer Aided Design and Business ...read more
 

Leave a comment