Hello Folks,

I am starting this blog with Two Assumptions,

You have already created a Trunk in UAG and have a SharePoint site which you are trying to publish.

In the below post I am mainly explaining the steps using which you can publish a SharePoint site without using an external DNS entry.

In this case, I have a web application named HRWeb and have created a portal trunk.

From the UAG Portal, as you can see below, run the application wizard to add the application

Once it reaches the Select Application step, chose Web ‘Other web application (Portal Hostname)’

If you are publishing a generic application mention the Application name and the Application type.

In next step I am choosing the default END point policies except the Access policy as “Always”

In the next step, I will choose Configure an application server as the option, as I have only one SharePoint server in my test LAB and I don’t have to use UAG Load Balancing.

.

In the next section, I can either provide a Host header or IP address of the SharePoint site, in this case Hrweb.spf.com as the host header.

Check the Add portal and tool bar link and also check the open in new window option as well.

We will choose to authorize all users.

Add the Authentication source as a Domain controller DC.SPF.com as the source is AD users

Once you have completed the ADD application wizard, in the next step we will need to activate configuration. This essentially publishes the application.

After publishing, once you login to the UAG portal, you will be able to find the Application as shown below.

Try accessing the HRWEB SharePoint site and please check the URL of the HRweb site that is published. It uses a relative URL.

Hope that helps..!!!!!!

Please feel free to provide any feedback or if you have any questions just use Send email to author to contact me.

Please find the links to the entire series below and do let me know your valuable feedback, suggestions or corrections if any. 

A very special thanks to the two Stalwarts of ADFS who helped me in building this LAB setup  Rahul Gangwar ,  Dilip Sant and the powershell Man Manoj Nair for helping me publish this blog

 ZEN and The ART of ADFS Implementation–Part 1 of 5: Introduction

https://blogs.msdn.com/b/moss_attacks/archive/2012/03/20/zen-and-the-art-of-adfs-implementation-part-1-of-5-introduction.aspx

ZEN and The ART of ADFS Implementation–Part 2 of 5: ADFS Certificates and Accounts setup

https://blogs.msdn.com/b/moss_attacks/archive/2012/03/20/zen-and-the-art-of-adfs-implementation-part-2-of-5-adfs-certificates-and-accounts-setup.aspx

ZEN and The ART of ADFS Implementation–Part 3 of 5: ADFS Deployment Steps

https://blogs.msdn.com/b/moss_attacks/archive/2012/03/20/zen-and-the-art-of-adfs-implementation-part-3-of-5-adfs-deployment-steps.aspx

ZEN and The ART of ADFS Implementation–Part 4 of 5: SharePoint 2010 Integration

https://blogs.msdn.com/b/moss_attacks/archive/2012/03/20/zen-and-the-art-of-adfs-implementation-part-4-of-5-sharepoint-2010-integration.aspx

ZEN and The ART of ADFS Implementation–Part 5 of 5: ADFS Federation between Two forests

https://blogs.msdn.com/b/moss_attacks/archive/2012/03/20/zen-and-the-art-of-adfs-implementation-part-5-of-5-adfs-federation-between-two-forests.aspx

Happy Reading!

Cheers,

Sarath

First step we will ensure that we can ping the CHIADFS server from ZEN ADFS and Viceversa.

I will put a host header entry for Chiadfs.chi.local in ZENADFS

Browse https://zenadfs.zen.local/federationmetadata/2007-06/federationmetadata.xml.

Save the Federationmetadata.xml file and save it on CHIADFS server and we will need it soon.

The same step has to be done from the CHI ADFS server by saving the Metdadat.xml file and saving it in the ZenADFS server.

Next we will add the claims trust for the CHI ADFS in the ZEN ADFS server.

Run the wizard for adding a the claims provider Trust

In the select data source we can provide the federation metadata file location of CHI ADFS ( Which we had earlier copied from the CHI ADFS server)

Run through the steps and complete the wizard.

Once the Claims provider trust has completed the steps, next we will need to edit the claims rules.

This time we will create two rules one for Email pass through and other for Role pass through.

Note: We have used the Rule template as: Pass through or Filter an incoming claim.

Using the Pass Through or Filter an Incoming Claim rule template in Active Directory Federation Services (AD FS) 2.0, you can pass through all incoming claims with a selected claim type. You can also filter the values of incoming claims with a selected claim type. For example, you can use this rule template to create a rule that will send all incoming group claims. You can also use this rule to send only user principal name (UPN) claims that end with @chi.local.

Ok next step is to access CHI ADFS server and add the Relying party trust wizard.

Once you have completed the Relying party trust we need to edit the claim rule as shown below.

This time we will use the template as Send LDAP Attribute as claims as the CHI ADFS server is

Using the Send LDAP Attributes as Claims rule template in Active Directory Federation Services (AD FS) 2.0, you can create a rule that will select attributes from a Lightweight Directory Access Protocol (LDAP) attribute store, such as Active Directory, to send as claims to the relying party.

For example, you can use this rule template to create a Send LDAP Attributes as Claims rule that will extract attribute values for authenticated users from the UPN and Role Active Directory attributes and then send those values as two different outgoing claims.

Next I will add a test user to the SharePoint site https://zensp . For this I will need to login using windows credentials, as shown below.

Now it is time for us to test the federation trust between these two forests.

I will login to win7 machine (part of CHI forest) using the user Tao@chi.local .

Next, I will access the site https://Zensp and I will have to choose between the CHI and ZEN provider and

Special thanks to Rahul Gangwar for all the help in setting this up and reviewing this blog post.

I hope you enjoyed the entire series on SharePoint 2010 and ADFS 2.0 Integration. If you still have any questions or need more clarifications, feel free to reach out to me via the Contact link on my blog. I would be more than happy to respond to your queries.

Cheers,

Sarath

To add a new relying party trust

1. Click Start, point to Administrative Tools, and then click AD FS 2.0.

2. Under AD FS 2.0\Trust Relationships, right-click the Relying Party Trusts folder, and then click Add Relying Party Trust to open the Add Relying Party Trust Wizard.

3. On the Welcome page, click Start.

4. On the Select Data Source page, click Enter data about the relying party manually, and then click next.

Note

The Select Data Source page provides three options for entering the data about the relying party. If the relying party publishes its federation metadata or can provide a file copy of it for you to use, the automatic retrieval method is recommended. It can save time, and it allows you to skip most of the remaining steps in this procedure. The third option is to enter all the configuration data for the new relying party trust manually, as described in steps 5 through 9.

5. On the Specify Display Name page, type a name in Display name. Click Next after you enter the description details.

6. On the Choose Profile page, select the appropriate profile for your needs, and then click Next.

If you know you will require interoperability with federation servers running an earlier version of AD FS, such as provided in Windows Server 2003 R2, click AD FS 1.0 and 1.1 profile. Otherwise, click AD FS 2.0 profile.

7. On the Configure Certificate page, click Browse to browse to and locate a certificate file and add it to the list of certificates, and then click Next.

8. On the Configure URL page, select the appropriate check boxes and specify any corresponding URLs as appropriate for the WS-Federation Passive protocol-based or Security Assertion Markup Language (SAML) 2.0 WebSSO protocol-based endpoint, and then click Next.

9. On the Configure Identifiers page, you must specify at least one identifier for this relying party trust. Type the URI you want to use here, click Add to add it to the list, and then click Next.

Please note that the URN should be off the format URN: ZEN: ZENSP.

10. On the Choose Issuance Authorization Rules page, select whether you want to permit all users or restrict them, based on configuring authorization rules, and then click Next.

11. On the Ready to Add Trust page, review your settings. When you are ready to save your settings, click Next.

12. On the Finish page, click Close.

To create a rule to send LDAP attributes as claims

1. Click Start, point to Programs, point to Administrative Tools, and then click AD FS 2.0 Management.
2. In the console tree, under AD FS 2.0\Trust Relationships, click either Claims Provider Trusts or Relying Party Trusts, and then click a specific trust in the list where you want to create this rule.
3. Right-click the selected trust and then click Edit Claim Rules.
4. In the Edit Claim Rules dialog box, select one the following tabs, depending on the trust that you are editing and which rule set you want to create this rule in, and then click Add Rule to start the rule wizard that is associated with that rule set:
   • Acceptance Transform Rules
   • Issuance Transform Rules
   • Issuance Authorization Rules
   • Delegation Authorization Rules
5. On the Select Rule Template page, under Claim rule template, select Send LDAP Attributes as Claims from the list, and then click Next.

1. On the Configure Rule page under Claim rule name type the display name for this rule, under Attribute store select Active Directory, and under Mapping of LDAP attributes to outgoing claim types select the desired LDAP Attribute and corresponding Outgoing Claim Type types from the drop-down lists.

You have to select a new LDAP attribute and outgoing claim type pair on a different row for each Active Directory attribute that you want to issue a claim for as part of this rule.

In this case I am going to use the email address (UPN) and Role as the Claim Type.

Click the Finish button.

In the Edit Claim Rules dialog box, click OK to save the rule.

Final output will look as shown in below screenshot.

I am not an expert in certificates, but I would recommend having a look at this blog for a better understanding of the various ADFS Certificates and their roles.

Only one thing I would like to call out from the above blog is that the Subject Name of the SSL certificate must match the names used in the ADFS configuration. For example, if you specify a federation server endpoint URL as https://zenadfs.local/adfs/ls/ - then the subject name on the SSL certificate for that server must be “ZENADFS.local”.

If this is an intranet only environment then you would only want to use the host name, then the endpoint URL would be https://zenadfs/adfs/ls/ and the Subject Name on the certificate should be “ZENADFS”

Verify that there are no errors on the certificate and it’s is part of the Trusted Root Authority store.

Same with Token decrypting and Token Signing.

Next step, I would export the Token signing certificate from ADFS server and import it to the SharePoint server.

Once Export has completed copy it to the SharePoint 2010 server.

After importing the Token signing certificate and Its root certificate (IF any) to the Trusted Root Store of SharePoint 2010, we need to run the below command.

If you notice I have chosen both the Windows Authentication and ZEN ADFS provider as the auuthentication source. This will help me login via Windows and provide access to ADFS users. I have added permissions to test user Steve@zen.local, by adding his UPN.

Please note two things,

1) The user should have a valid UPN and should have the email address field filled with appropriate email address. I wasted an hour in troubleshooting without realizing that the email address field was empty for the user in AD.

2) While adding users to SharePoint it will resolve any UPN that you provide say even if you give stev@zen.local instead of Steve@zen.local, it will get resolved with outr giving any errors. This doesn’t mean that user exists or you have added the cortrect user. Hence you will need to double checfk the users while adding them.

So far So good..!!!! Steve@Zen.local was able to successfully login to the SharePoint Site.

Stay tuned for the remaining part of the series !!

Happy Reading!

Cheers,

Sarath

Download the ADFS 2.0 setup from this link .

Once the installation has completed, automatically it will open the federation server configuration wizard, follow the steps as shown below.

It automatically picked the ADFS certificate as ZENadfscert.zen.local as that is the only certificate that was created in my ADFS server. By default from the certificate it took the Federation service name as ZENADFS.Zen.local.

Next step we will need to provide the ADFS account ZEN\ADFSadmin ( Remember the account we created and ran the SETSPN commands)

Configuration service warnings indicate that the server needs a reboot. Once this has been done next step would be add the relying party.

Stay tuned for the remaining part of the series !!

Happy Reading!

Cheers,

Sarath

After CA role has been installed successfully next step is to create the accounts for ADFS and SharePoint2010.

I have created an account ZEN\AdfsAdmin and this account will be used for running the ADFS service.

Create another account ZEN\SPAdmin for running SharePoint.

When you deploy an AD FS 2.0 Federation Server farm you must specify a domain-based service account, and the AD FS 2.0 service account needs to have a SPN (servicePrincipalName) registered to allow Kerberos to function for the Federation Service.

In this case, ZENADFS.local is my ADFS server FQDN, and ZENSP.local being my SharePoint server FQDN.

Please refer AD FS 2.0: How to Configure the SPN (servicePrincipalName) for the Service Account .

Next step would be to create a certificate template for ADFS.

GO To Start > RUN > Type MMC > File ADD or Remove Snap-ins.

ADD certificate as shown below, chose Computer Account, and Local computer in the successive pages and click ok.

Now next step we need to access the ADFS server and run the below command

This will ensure that the template that we have provisioned is available for the ADFS server to create a new certificate.

Next, we will create a new certificate using the template we have created.

In my lab, I have added the CName as ZenADFS.zen.local.

Stay tuned for the remaining part of the series !!

Happy Reading!

Cheers,

Sarath

I know there are several SharePoint guys like me out there, who would like to have a step by step documentation on ADFS certificates creation and federation between two forests. Hence I have tried to capture screenshots for all the steps.

I have split the post into the following chapters for simplicity,

ZEN and The ART of ADFS Implementation–Part 1 of 5: Introduction

ZEN and The ART of ADFS Implementation–Part 2 of 5: ADFS Certificates and Accounts setup

ZEN and The ART of ADFS Implementation–Part 3 of 5: ADFS Deployment Steps

ZEN and The ART of ADFS Implementation–Part 4 of 5: SharePoint 2010 Integration

ZEN and The ART of ADFS Implementation–Part 5 of 5: ADFS Federation between Two forests

The diagram below indicates Typical ADFS Federation between two forests.

NB: Please Read before jumping to the steps.

Since this is a lab environment,

I am not using a Public domain. I have put host header values in Lab Machines so that it can access the ADFS service endpoints. I will explain these once we go through the steps.

I am not using any 3^rd party certificates and I am using Internal CA certificates throughout this lab setup.

I have not gone through the steps for SharePoint 2010 deployment as already there are Tons of Material out there.

Now the above statements means there is no Perimeter network or the internet in my lab setup, but this will not affect the steps to configure the ADFS federation between two forest and I will callout changes required if any.

ZEN Forest Lab Configuration

ZEN_DC – Server 2008 R2, 1 GB RAM, 2.13 GHZ

ZEN_ADFS - Server 2008 R2, 1GB RAM, 2.13 GHZ

ZEN_SP2010 - Server 2008 R2, 1GB RAM, 2.13 GHZ

CHI Forest Lab Configuration

CHI_DC – Server 2008 R2, 1 GB RAM, 2.13 GHZ

CHI_ADFS - Server 2008 R2, 1GB RAM, 2.13 GHZ

CHI_WIN7 – Windows 7 Client, 1GB RAM, 2.13 GHZ

Stay tuned for the remaining part of the series !!

Happy Reading!

Cheers,

Sarath

=======================================================================================

The Microsoft® SharePoint® 2010 Administration Toolkit contains functionality to help administer and manage Microsoft® SharePoint® Foundation 2010 and Microsoft® SharePoint® Server 2010.

=======================================================================================

The Microsoft SharePoint Administration Toolkit contains the following tools to help manage SharePoint Foundation 2010 and SharePoint Server 2010:

• Security Configuration Wizard (SCW) manifests, which add roles for SharePoint 2010 Products to Windows Server 2008 with Service Pack 2 or to Windows Server 2008 R2.
  SCW is an attack surface reduction tool introduced with Windows Server 2003 Service Pack 1. SCW uses a roles-based metaphor to solicit the functionality required for a server and disables the functionality that is not required. By automating this security best practice, SCW helps to create Windows environments that are less susceptible, on the whole, to security vulnerabilities that have been exploited. For more information about SCW in Windows Server 2008, see Security Configuration Wizard (https://go.microsoft.com/fwlink/?LinkId=185511).
• Load Testing Toolkit (LTK), which generates a Visual Studio Team System 2008 (VSTS) load test based on Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007 IIS logs. The VSTS load test can be used to generate synthetic load against SharePoint Foundation 2010 or SharePoint Server 2010 as part of a capacity planning exercise or a pre-upgrade stress test.
  To install the Visual Studio Team System (VSTS), see Visual Studio Team System 2008 Team Suite (https://go.microsoft.com/fwlink/?LinkID=101641). To install Service Pack 1, see Microsoft Visual Studio 2008 Service Pack 1 (https://go.microsoft.com/fwlink/?LinkID=116488).
• User Profile Replication Engine 2010 (UPRE2010), which provides a shared services administrator the ability to replicate user profiles and social data between shared services providers (SSP) in Office SharePoint Server 2007 and User Profile service applications in SharePoint Server 2010. This Windows PowerShell-based tool is not supported for SharePoint Foundation 2010.
• Content Management Interoperability Services (CMIS) connector for SharePoint Server 2010
  The Content Management Interoperability Services (CMIS) connector for SharePoint Server 2010 enables SharePoint users to interact with content stored in any repository that has implemented the CMIS standard, as well as making SharePoint 2010 content available to any application that has implemented the CMIS standard.
  The CMIS connector for SharePoint Server 2010 includes two features:
  • The Content Management Interoperability Services (CMIS) Consumer Web Part, which can be added to any SharePoint page. This Web Part displays and lets users interact with the contents of any CMIS repository.
  • The Content Management Interoperability Services (CMIS) Producer, which allows applications to interact with SharePoint lists and document libraries programmatically by means of the interfaces defined in the CMIS standard.
  
  For more information about the Content Management Interoperability Services (CMIS) standard, see OASIS Content Management Interoperability Services (CMIS) TC (https://go.microsoft.com/fwlink/?LinkId=196694).
  This tool is not supported for SharePoint Foundation 2010.

System Requirements

• Supported Operating Systems: Windows Server 2008 R2; Windows Server 2008 Service Pack 2

• Security Configuration Wizard manifests: Can be installed on any computer running Windows Server 2008 x64 or Windows Server 2008 R2 x64.
• User Profile Replication Engine: Can be installed on any server running a 64-bit Windows operating system. Requires Windows PowerShell. If the source or target is running Microsoft Office SharePoint Server 2007, that source or target server must be updated with the June 2010 Cumulative Update (or a later cumulative update).
• Load Test Kit: Can be installed on any x64 Windows box, although the Prerequisitecollector.exe needs to be run on either an x86 or an x64 machine that is also running Windows SharePoint Services 3.0 or Office SharePoint Server 2007.
• Content Management Interoperability Services (CMIS) connector: Can be installed on any computer running Windows Server 2008 x64 or Windows Server 2008 R2 x64 and the Secure Store Service in SharePoint Server 2010.

Download and extract the package, then follow the instructions provided on TechNet:

• SharePoint 2010 Administration Toolkit v1.0 (SharePoint Server) (https://go.microsoft.com/fwlink/?LinkId=196862)
• SharePoint 2010 Administration Toolkit v1.0 (SharePoint Foundation) (https://go.microsoft.com/fwlink/?LinkId=196863