Bekir AKGÜL | Bilişim Günlüğüm

Bekir AKGÜL Kişisel Web Sitesi

Archive for the ‘Ofis 365’ Category

Ofis 365 de Federasyon işlemi ile kimlik doğrulama adımları

leave a comment »

http://support.microsoft.com/Library/Images/2588424.gif

 

Yukarıdaki resim sorun çözmede yardımcı olacaktır.

Written by bekirakgul

17/10/2011 at 09:45

Ofis 365 kategorisinde yayınlandı

Ofis 365 de Single Sing On kullanmak için Active Directory Federation servisi planlama ve yükleme

leave a comment »

This article provides streamlined planning and deployment instructions for Microsoft Office 365 for enterprises administrators who have determined that they require single sign-on access and who currently do not have an Active Directory Federation Services 2.0 infrastructure deployed in their organization.

If you currently have an AD FS 2.0 production environment and are interested in providing your users with single sign-on access to Office 365 services, you can go directly to the next step: Install and configure the Microsoft Online Services Module for Windows PowerShell for single sign-on.

For additional overview and configuration information about AD FS 2.0, see the Next step and additional references section in this article.

Overview of the AD FS 2.0 for Office 365 single sign-on solution

You can deploy a new AD FS 2.0 infrastructure to provide your Active Directory users, who are logged on to computers located physically on the corporate network or that are logged on remotely to the corporate network, with single sign-on access to Office 365 services using their corporate domain credentials.

Once you have deployed your AD FS 2.0 production environment on-premises, you will need to establish a relying party trust relationship between the AD FS 2.0 federation server farm and Office 365. This relying party trust acts as a secure channel where authentication tokens can safely pass between your organization and Office 365 in order to facilitate single sign-on access to Office 365.

The following image illustrates how local Active Directory users can obtain the necessary authentication tokens from on-premises AD FS 2.0 federation servers that can redirect the user’s requests through the relying party trust to allow them single sign-on access to Office 365.

AD FS and Office 365

Complete these steps

1. Review checklist for deploying AD FS 2.0

This article uses a series of checklists to help you walk through the various deployment tasks that are important for you to follow, in chronological order, to implement an AD FS 2.0 production environment that can provide single sign-on access to Office 365. The following top-level checklist provides you with the high-level deployment tasks that are necessary to most efficiently deploy your new AD FS 2.0 infrastructure on-premises.

icon_chlst_contento Step 1–Checklist 1: Deploy your on-premises AD FS 2.0 infrastructure

Deployment task Links to sections in this article Completed
1. Review the AD FS 2.0 terminology table to help you become familiar with terms that will be used throughout this article. Review AD FS 2.0 terminology icon_checkboxo
2. Review the various AD FS 2.0 deployment options available to use for your new deployment. You will need to consider how many servers to deploy and where you will need to place federation servers and federation server proxies within your intranet or extranet, or both. Plan your AD FS 2.0 deployment icon_checkboxo
3. Review the requirements for deploying AD FS 2.0 for use with Office 365. This information will help you to understand how your corporate network infrastructure will need to be configured to support AD FS 2.0 for accounts, name resolution, certificates, and so on. Follow the requirements for deploying AD FS 2.0 icon_checkboxo
4. Deploy your AD FS 2.0 federation server farm. The procedures provided in this section will walk you through how to set up and configure at least two computers for the federation server role. A federation server farm with at least two servers is recommended for fault tolerance and high availability. Deploy your federation server farm icon_checkboxo
5. Deploy your federation server proxies that will allow clients to connect from outside your corporate network. The procedures in this section will walk you through how to set up each computer in the federation server proxy role. Deploy your federation server proxies icon_checkboxo

After deployment

After you have successfully deployed your AD FS 2.0 infrastructure, proceed to Install and configure the Microsoft Online Services Module for Windows PowerShell for single sign-on. This article guides you through setting up the relying party trust between your new AD FS 2.0 servers on-premises and Office 365.

For on-going management of an AD FS 2.0 server—for example, managing certificate rollover—see Verify and manage single sign-on.

For additional information, such as how to customize the AD FS 2.0 sign-in page, use strong authentication (also called two-factor authentication), or configure reverse proxies in your network for AD FS 2.0, see Configuring Advanced Options for AD FS 2.0.

Back to top

2. Review AD FS 2.0 terminology

Before you begin using this content to deploy AD FS 2.0 for single sign-on to Office 365, we recommend that you first read about AD FS 2.0 terms that are used throughout this article.

AD FS 2.0 term Definition
AD FS 2.0 configuration database A database used to store all configuration data that represents a single AD FS 2.0 instance or Federation Service. This configuration data can be stored using the Windows Internal Database (WID) feature included with Windows Server 2008 and Windows Server 2008 R2 or using a Microsoft SQL Server database.
Claim A statement that one subject makes about itself or another subject. For example, the statement can be about a name, email, group, privilege, or capability. Claims have a provider that issues them (in this case an Office 365 customer) and they are given one or more values. They are also defined by a claim value type and, possibly, associated metadata.
Federation Service A logical instance of AD FS 2.0. A Federation Service can be deployed as a standalone federation server or as a load-balanced federation server farm. The name of the Federation Service defaults to the subject name of the SSL certificate. The DNS name of the Federation Service must be used in the Subject name of the Secure Sockets Layer (SSL) certificate.
Federation server A computer running Windows Server 2008 or Windows Server 2008 R2 that has been configured to act in the federation server role for AD FS 2.0. A federation server serves as part of a Federation Service that can issue, manage, and validate requests for security tokens and identity management. Security tokens consist of a collection of claims, such as a user’s name or role.
Federation server farm Two or more federation servers in the same network that are configured to act as one Federation Service instance.
Federation server proxy A computer running Windows Server 2008 or Windows Server 2008 R2 that has been configured to act as an intermediary proxy service between a client on the Internet and a Federation Service that is located behind a firewall on a corporate network. In order to allow remote access to the services in Office 365, such as from a smart phone, home computer, or Internet kiosk, you need to deploy a federation server proxy.
Relying party A Federation Service or application that consumes claims in a particular transaction.
Relying party trust In the AD FS 2.0 Management snap-in, a relying party trust is a trust object that is created to maintain the relationship with another Federation Service, application, or service (in this case Office 365) that consumes claims from your organization’s Federation Service.
Network load balancer A dedicated application (such as Network Load Balancing) or hardware device (such as a multilayer switch) used to provide fault tolerance, high availability, and load balancing across multiple nodes. For AD FS 2.0, the cluster DNS name that you create using this NLB must match the Federation Service name that you specified when you deployed your first federation server in your farm.

Back to top

3. Plan your AD FS 2.0 deployment

The first step in planning an AD FS 2.0 deployment for Office 365 is to select the right deployment topology to meet the single sign-on needs of your organization. AD FS 2.0 requires that you use either Windows Internal Database (WID) or a SQL Server database to store the AD FS 2.0 configuration data used by the Federation Service.

The recommended AD FS 2.0 topology for the majority of Office 365 customers is to use the federation server farm with WID and proxies topology that follows. There is also an advanced option of creating a federation server farm with SQL Server proxies, mentioned later in this section.

In addition, this section also provides a table for determining the number of AD FS 2.0 servers to deploy in your organization, as well as information about adding federation servers to increase performance.

Recommended topology: Federation server farm with WID and proxies

The default topology for Office 365 is an AD FS 2.0 federation server farm that consists of multiple servers hosting your organization’s Federation Service. In this topology, AD FS 2.0 uses WID as the AD FS 2.0 configuration database for all federation servers that are joined to that farm. The farm replicates and maintains the Federation Service data in the configuration database across each server in the farm.

The act of creating the first federation server in a farm also creates a new Federation Service. When WID is used as the AD FS 2.0 configuration database, the first federation server that is created in the farm is referred to as the primary federation server. This means that this computer will be configured with a read/write copy of the AD FS 2.0 configuration database.

All other federation servers configured for this farm are referred to as secondary federation servers, as they must replicate any changes that are made on the primary federation server to their read-only copies of the AD FS 2.0 configuration database that they store locally.

Note
We recommend the use of at least two federation servers in a load-balanced configuration.

 

Setting up this base federation server farm topology is the first phase of your AD FS 2.0 deployment. The second phase consists of determining how to provide access control functionality for external users by deploying federation server proxies.

Phase 1: Deploy your federation server farm

When you are ready to start deploying your farm, you should plan on placing all of the federation servers in your corporate network behind a Network Load Balancing (NLB) host that can be configured for an NLB cluster with a dedicated cluster DNS name and cluster IP address.

Important
This cluster DNS name must match the Federation Service name (for example, fs.fabrikam.com) and be Internet-routable for the instance of AD FS 2.0 that you deploy. If the name does not match, the authentication request won’t be routed to the correct DNS server or the correct federation server.

 

The NLB host can use the settings defined in this NLB cluster to allocate client requests to the individual federation servers. The following diagram depicts how Fabrikam, Inc. might set up the first phase of their deployment using a two-computer federation server farm (fs1 and fs2) with WID and the positioning of a DNS server and a single NLB host wired to the corporate network.

FS Farm with WID

Note
If there is a failure on this single NLB host, then users will not be able to access Office 365 services. Add additional NLB hosts if your business requirements do not allow having a single point of failure.

 

Phase 2: Deploy your federation server proxies

In general, federation server proxies are used to redirect client authentication requests coming from outside your corporate network to the federation server farm. For Office 365 enterprise customers, deploying federation server proxies to your existing AD FS 2.0 infrastructure is necessary to enable the following user scenarios:

  • Work computer, roaming: Users who are logged on to domain-joined computers with their corporate credentials, but who are not connected to the corporate network (for example, a work computer at home or at a hotel), can access the services in Office 365.
  • Home or public computer: When the user is using a computer that is not joined to the corporate domain, the user must sign in with their corporate credentials to access the services in Office 365.
  • Smart phone: On a smart phone, to access the services in Office 365 such as Microsoft Exchange Online using Microsoft Exchange ActiveSync, the user must sign in with their corporate credentials.
  • Microsoft Outlook or other email clients: The user must sign in with their corporate credentials to access their Office 365 email if they are using Outlook or an email client that is not part of Office; for example, an IMAP or POP client.

To support these user scenarios, this second phase will build on Phase 1 of the deployment discussed previously, by adding two federation server proxies, providing access to a DNS server on the perimeter network, and access to a second NLB host on the perimeter network.

The second NLB host must be configured with an NLB cluster that uses an Internet-accessible cluster IP address and it must use the same cluster DNS name setting as the previous NLB cluster you configured on the corporate network for Phase 1 (fs.fabrikam.com). The federation server proxies will also be configured with Internet-accessible IP addresses.

The following diagram shows the existing Phase 1 deployment and how Fabrikam, Inc. might provide access to a perimeter DNS server, add a second NLB host with the same cluster DNS name (fs.fabrikam.com), and add two federation server proxies (fsp1 and fsp2) to the perimeter network.

FS Farm with WID and Proxies

Note
  • You can use Microsoft Forefront Unified Access Gateway (UAG) or Forefront Threat Management Gateway (TMG) to publish AD FS 2.0 to the extranet. For more information about how to do this, see Configuring Advanced Options for AD FS 2.0.
  • You can also use third-party HTTP reverse proxy solutions to publish AD FS 2.0 to the extranet.
  • All AD FS 2.0 communication that travels through the firewall is based on HTTPS.

 

Advanced option: Federation server farm with SQL Server and proxies

This is an advanced AD FS 2.0 deployment topology option that uses federation server proxies and a SQL Server configuration to enable all federation servers in the farm to read and write to a common SQL Server database. Using a SQL Server database as the AD FS 2.0 configuration database provides the following benefits over WID:

  • High-availability features of SQL Server that administrators can use.
  • Additional performance enhancements, including the ability to scale out using more than five federation servers (WID is limited to five federation servers per farm).
  • Geographic load-balancing to help provide increases for high traffic based on location.
Note
Because this topology is an advanced AD FS 2.0 deployment option, the details for how this topology works and how to deploy it are not covered in this article.

 

For more information about this topology option, see Configuring Advanced Options for AD FS 2.0.

Estimation table: Determine the number of AD FS 2.0 servers to deploy in your organization

You can use the following table to help you estimate the minimum number of AD FS 2.0 federation servers and federation server proxies that you will need to place in a federation server farm configured with WID throughout your corporate network infrastructure based on the number of users who will require single sign-on access, including remote access, to Office 365.

Note
All computers that will be configured for the federation server or federation server proxy role must be running either the Windows Server 2008 or Windows Server 2008 R2 operating system.

 

We recommend that you use one federation server to account for redundancy. The following table follows this recommendation.

Number of users accessing Office 365 Minimum number of servers to deploy Recommendation and steps
Fewer than 1,000 users 0 dedicated federation servers

0 dedicated federation server proxies

1 dedicated NLB server

For the federation servers, use two existing Active Directory domain controllers (DCs) and configure them both for the federation server role. To do this, first select two existing DCs, and then:

  1. Install AD FS 2.0 on both domain controllers.
  2. Configure one as the first federation server in a new farm.
  3. Join the second one to the federation server farm.

For NLB, configure an existing NLB host or obtain a dedicated server and then install the NLB server role on it and then configure the NLB server.

For the federation server proxies, use two existing web or proxy servers and configure them both for the federation server proxy role. To do this, select two existing web or proxy servers that reside in the extranet, and then:

  1. Install AD FS 2.0 on both servers.
  2. Configure them for the federation server proxy role.
  3. Install the NLB server role on one of the federation server proxies or configure an existing NLB host.
Note
If you do not have two existing DCs and two web or proxy servers or they are not running either Windows Server 2008 or Windows Server 2008 R2, you should deploy dedicated servers instead, as discussed in the next row of this table.

 

1,000 to 15,000 users 2 dedicated federation servers

2 dedicated federation server proxies

For the federation servers, obtain two dedicated servers, and then:

  1. Install AD FS 2.0 on both servers.
  2. Configure one as the first federation server in a new farm.
  3. Join the second one to the farm.
  4. Install the NLB server role on one of the federation servers or configure an existing NLB host.

For the federation servers, obtain two dedicated servers that you can place in the extranet:

  1. Install AD FS 2.0 on both servers.
  2. Configure them for the federation server proxy role.
  3. Install the NLB server role on one of the federation server proxies or configure an existing NLB host.
15,000 to 60,000 users Between 3 and 5 dedicated federation servers

At least 2 dedicated federation server proxies

Each dedicated federation server can support approximately 15,000 users. Therefore, add an additional dedicated federation server to the base two federation server deployment described previously for every 15,000 users that will require access to Office 365, up to a maximum of five federation servers in the farm or 60,000 users.

Note
An AD FS 2.0 federation server farm configured to use WID supports a maximum of five federation servers. If you need more than five federation servers, you need to configure a SQL Server database to store the AD FS 2.0 configuration database. For more information about this option, see Configuring Advanced Options for AD FS 2.0.

 

Note
To use Forefront Unified Access Gateway (UAG) or Forefront Threat Management Gateway (TMG) to publish AD FS 2.0 to the extranet, see Configuring Advanced Options for AD FS 2.0.

 

The minimum number of users to servers recommendations provided in the previous table are calculated based on the following hardware:

Hardware Specifications
CPU speed Dual Quad Core 2.27GHz CPU (8 cores)
RAM 4 gigabytes (GB)
Network Gigabit

Adding federation servers to increase performance

When two or more federation servers are configured in a farm using NLB technology, they can operate independently to help process the load of incoming user requests made to the AD FS 2.0 Federation Service without degrading the overall performance of the service as a whole. Therefore, there is little overhead involved with adding additional federation servers to your existing production environment after you have deployed your initial federation servers strategically in your network.

Back to top

4. Follow the requirements for deploying AD FS 2.0

For a new AD FS 2.0 deployment to create a relying party trust successfully with Office 365, you must first make sure that your corporate network infrastructure is configured to support AD FS 2.0 requirements for accounts, name resolution, and certificates. AD FS 2.0 has the following types of requirements:

  • Software requirements
  • Certificate requirements
  • Network requirements

Software requirements

AD FS 2.0 software must be installed on any computer that you are preparing for the federation server or federation server proxy role. You can install this software by either using the AD FS 2.0 Setup Wizard or by performing a quiet installation using the adfssetup.exe /quiet parameter at a command line.

For a base installation platform, AD FS 2.0 requires either the Windows Server 2008 or the Windows Server 2008 R2 operating system. AD FS 2.0 has a separate installation package for each of the operating system platforms.

Prerequisites

During the AD FS 2.0 installation process, the setup wizard attempts to automatically check for and, if necessary, install both prerequisite applications and dependent hotfixes. In most cases the setup wizard will install all of the prerequisite applications necessary for AD FS 2.0 to operate and install.

However, there is one exception: when you are installing AD FS 2.0 on the Windows Server 2008 platform. If this is the case in your deployment situation, you will first need to make sure that .NET 3.5 SP1 is installed on the servers running Windows Server 2008 before installing the AD FS 2.0 software, as it is a prerequisite of AD FS 2.0 and it will not automatically be installed by the AD FS 2.0 Setup Wizard on this platform. If .NET 3.5 SP1 is not installed, the AD FS 2.0 Setup Wizard will prevent installation of the AD FS 2.0 software.

Hotfixes

You may need to install AD FS 2.0 hotfixes after you have installed AD FS 2.0. For more information about this option, see Installing AD FS 2.0 Hotfixes.

Virtualization

AD FS 2.0 supports software virtualization of both the federation server and federation server proxy roles. To account for redundancy, we recommend that you store each AD FS 2.0 virtual machine on separate, physical virtual servers.

For more information about setting up a virtual server environment using Microsoft virtualization technology, see the Hyper-V Getting Started Guide.

Certificate requirements

Certificates play the most critical role in securing communications between federation servers, federation server proxies, Office 365, and web clients. The requirements for certificates vary, depending on whether you are setting up a federation server or a federation server proxy computer, as described in the following tables.

Federation server certificates

Federation servers require the certificates in the following table.

Certificate type Description What you need to know before deploying
SSL certificate (also referred to as a Server Authentication Certificate) This is a standard Secure Sockets Layer (SSL) certificate that is used for securing communications between federation servers, clients, and federation server proxy computers. AD FS 2.0 requires an SSL certificate when configuring federation server settings. By default, AD FS 2.0 uses the SSL certificate configured for the Default Web Site in Internet Information Services (IIS).

The Subject name of this SSL certificate is used to determine the Federation Service name for each instance of AD FS 2.0 that you deploy. For this reason, you may want to consider choosing a Subject name on any new certification authority (CA)-issued certificates that best represents the name of your company or organization to Office 365 and this name must be Internet-routable. For example, in the diagram provided earlier in this article (see “Phase 2”), the subject name of the certificate would be fs.fabrikam.com.

Important
AD FS 2.0 requires this SSL certificate to be without a dotless (short-name) Subject name.

 

Recommendation: Because this certificate must be trusted by clients of AD FS 2.0, use an SSL certificate that is issued by a public (third-party) CA or by a CA that is subordinate to a publicly trusted root; for example, VeriSign or Thawte.

 

Token-signing certificate This is a standard X.509 certificate that is used for securely signing all tokens that the federation server issues and that Office 365 will accept and validate. The token-signing certificate must contain a private key, and it should chain to a trusted root in the Federation Service. By default, AD FS 2.0 creates a self-signed certificate. However, depending on the needs of your organization, you can change this later to a CA-issued certificate by using the AD FS 2.0 Management snap-in.

Recommendation: Use the self-signed token-signing certificate generated by AD FS 2.0. By doing so, AD FS 2.0 will manage this certificate for you by default. For example, in case this certificate is expiring, AD FS 2.0 will generate a new self-signed certificate to use ahead of time.

Caution
The token-signing certificate is critical to the stability of the Federation Service. In case it is changed, Office 365 needs to be notified about this change. Otherwise, the requests to Office 365 services will fail. For more information about managing certificates across the AD FS 2.0 federation server farm and Office 365, see Update trust properties.

 

Federation server proxy certificates

Federation server proxies require the certificate in the following table.

Certificate type Description What you need to know before deploying
SSL certificate This is a standard SSL certificate that is used for securing communications between a federation server, federation server proxy, and Internet client computers.

 

This certificate must be bound to the Default Web Site in IIS before you can run the AD FS 2.0 Federation Server Proxy Configuration Wizard successfully.

This certificate must have the same subject name as the SSL certificate configured on the federation server in the corporate network.

Recommendation: Use the same server authentication certificate as is configured on the federation server that this federation server proxy will connect to.

For more information about the certificates that federation servers and federation server proxies use, see AD FS 2.0 Design Guide.

Network requirements

Configuring the following network services appropriately is critical for successful deployment of AD FS 2.0 in your organization.

TCP/IP network connectivity

For AD FS 2.0 to function, TCP/IP network connectivity must exist between the client, domain controllers, federation servers, and federation server proxies.

DNS

The primary network service that is critical to the operation of AD FS 2.0, other than Active Directory, is Domain Name System (DNS). When DNS is deployed, users can use friendly computer names that are easy to remember to connect to computers and other resources on IP networks.

The process of updating DNS to support AD FS 2.0 consists of configuring the:

  • Internal DNS servers in the corporate network to resolve the cluster DNS name to the cluster IP address for the NLB cluster you configure on the corporate network NLB host. For example, resolving fs.fabrikam.com to 172.16.1.3.
  • Perimeter network DNS servers to resolve the cluster DNS name to the cluster IP address for the NLB cluster you configure on the perimeter NLB host. For example, resolving fs.fabrikam.com to 192.0.2.3.

NLB requirements

NLB is required to provide fault tolerance, high availability, and load-balancing across multiple nodes. It can be implemented with hardware, software, or a combination of both. You need to configure the DNS resource records based on your Federation Service name for the NLB cluster so that the fully-qualified domain name (FQDN) of the cluster (also referred to as cluster DNS name in this article) will be resolved to its cluster IP address.

For general information about the NLB cluster IP address or cluster FQDN, see Specifying the Cluster Parameters.

Utilize Extended Protection for Authentication

If your computers have Extended Protection for Authentication, and you use Firefox, Chrome, or Safari, you may not be able to sign in to Office 365 using Integrated Windows authentication from within the corporate network. If this situation occurs, your users might receive logon prompts on a regular basis. This is due to the default configuration (on Windows 7 and patched client operating systems) for AD FS 2.0 and Extended Protection for Authentication.

Until Firefox, Chrome, and Safari support Extended Protection for Authentication, the recommended option is for all clients accessing Office 365 services to install and use Windows Internet Explorer 8. If you want to use single sign-on for Office 365 with Firefox, Chrome, or Safari, there are two other solutions to consider. However, there may be security concerns in taking either of these approaches. For more information, see Microsoft Security Advisory: Extended protection for authentication. The solutions include:

  • Uninstalling the Extended Protection for Authentication patches from your computer.
  • Changing the Extended Protection for Authentication setting on the AD FS 2.0 server. For more information, see Configuring Advanced Options for AD FS 2.0.
  • Reconfiguring the authentication settings for the AD FS 2.0 webpage on each federation server from Integrated Windows authentication to using Forms Based Authentication.

Back to top

5. Deploy your federation server farm

The most important operation you need to perform to provide your users with single sign-on access to Office 365 is to deploy a new AD FS 2.0 federation server farm. We recommend that you deploy at least two federation servers in order to provide fault tolerance, load-balancing, and scalability to your organization’s AD FS 2.0 production environment.

The following checklists include the preparation and deployment tasks that are necessary to create the first AD FS 2.0 federation server in a new farm, create the second federation server, and then join the second federation server to the farm.

Note
  • Complete the tasks in these checklists in order. When a reference link takes you to a procedure, return to this topic after you complete the steps in that procedure so that you can proceed with the remaining tasks in this checklist.
  • Unless otherwise noted, to complete all of the tasks using the procedures in this section you must first be logged into the computers as a member of the Administrators group, or have been delegated equivalent permissions.

 

icon_chlst_contento Step 5–Checklist 1: Prepare your network infrastructure for federation servers

Deployment task Links to topics in this section Completed
1. Join the computers that will become federation servers to a domain where Active Directory users will be authenticated.

Note
You can ignore this step if you will use existing domain controllers as federation servers.

 

Join the computer to a domain icon_checkboxo
2. Create and configure a new NLB cluster DNS name or use an existing NLB cluster in the corporate network that will be used by the new federation server farm. Then add the federation server computers to the NLB cluster. If you are using Windows Server technology for your current NLB hosts, choose the appropriate link to the right based on your operating system version. To create and configure NLB clusters on Windows Server 2003 and Windows Server 2003 R2, see Checklist: Enabling and configuring Network Load Balancing. To create and configure NLB clusters on Windows Server 2008, see Creating Network Load Balancing Clusters.

To create and configure NLB clusters on Windows Server 2008 R2, see Creating Network Load Balancing Clusters.

icon_checkboxo
3. Create a new resource record for the cluster DNS name in the corporate network DNS that points the FQDN name of the NLB cluster to its cluster IP address. Add a resource record to the corporate DNS for the cluster DNS name configured on the corporate NLB host icon_checkboxo
4. Import the server authentication certificate to the Default Web Site for each federation server in the farm.

Note
Installing this certificate on the Default Web Site is a requirement before you can use the AD FS 2.0 Federation Server Configuration Wizard.

 

Import a server authentication certificate to the Default Web Site icon_checkboxo
5. Create and configure a dedicated service account in Active Directory where the federation server farm will reside and configure each federation server in the farm to use this account. Create a dedicated service account for the federation server farm icon_checkboxo

icon_chlst_contento Step 5–Checklist 2: Deploy your federation server farm

Deployment task Links to topics in this section Completed
1. Install the AD FS 2.0 software and AD FS 2.0 hotfixes on the computers that will become federation servers. Install the AD FS 2.0 software icon_checkboxo
2. Configure the AD FS 2.0 software on one of the computers to act in the federation server role. Follow this procedure to create the first federation server in a new farm. Configure the first federation server in the federation server farm icon_checkboxo
3. Configure the second federation server using the same steps above and then skip to this task and use the procedure to the right to join this new federation server to the new farm. Add a federation server to the federation server farm icon_checkboxo
4. From a client computer, verify that the federation servers are operational. Verify that the federation server is operational icon_checkboxo

Join the computer to a domain

For AD FS 2.0 to function, each computer that functions as a federation server must be joined to a domain. Federation server proxies may be joined to a domain, but it is not a requirement.

To join the computer to a domain

  1. On the computer that you want to join to a domain, click Start, click Control Panel, and then double-click System.
  2. Under Computer name, domain, and workgroup settings, click Change settings.
  3. On the Computer Name tab, click Change.
  4. Under Member of, click Domain, type the name of the domain that this computer will join, and then click OK.
  5. Click OK, and then restart the computer.

Add a resource record to the corporate DNS for the cluster DNS name configured on the corporate NLB host

For clients on the corporate network to successfully access the Federation Service, a host (A) resource record must first be created in the corporate Domain Name System (DNS) that resolves the cluster DNS name of the Federation Service (for example, fs.fabrikam.com) to the cluster IP address in the corporate network (for example, 172.16.1.3). You can use the following procedure to add a host (A) resource record to the corporate DNS for the NLB cluster.

To add a resource record to corporate DNS for the cluster DNS name configured on the corporate NLB host

  1. On a DNS server for the corporate network, open the DNS snap-in.
  2. In the console tree, right-click the applicable forward lookup zone (for example, fabrikam.com), and then click New Host (A or AAAA).
  3. In Name, type only the computer name of the federation server or federation server cluster; for example, for the fully-qualified domain name (FQDN) fs.fabrikam.com, type fs.
  4. In IP address, type the IP address for the federation server or federation server cluster; for example, 172.16.1.3.
  5. Click Add Host.
    Important
    It is assumed that you are using a DNS server, running Windows 2000 Server, Windows Server 2003, or Windows Server 2008 with the DNS Server service, to control the DNS zone.

     

Import a server authentication certificate to the Default Web Site

After you obtain a server authentication certificate from a certification authority (CA), you must manually install that certificate on the Default Web Site for each federation server in your farm.

Because this certificate must be trusted by clients of AD FS 2.0, use an SSL certificate that is issued by a public (third-party) CA or by a CA that is subordinate to a publicly trusted root; for example, VeriSign or Thawte. For information about installing a certificate from a public CA, see IIS 7.0: Request an Internet Server Certificate.

Note
The subject name of this server authentication certificate must match the FQDN of the cluster DNS name (for example, fs.fabrikam.com) you created earlier on the NLB host. If Internet Information Services (IIS) has not been installed, you must install IIS first in order to complete this task. When installing IIS for the first time, we recommend that you use the default feature options when prompted during the installation of the server role.

 

To import a server authentication certificate to the Default Web Site

  1. Click Start, point to All Programs, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
  2. In the console tree, click ComputerName.
  3. In the center pane, double-click Server Certificates.
  4. In the Actions pane, click Import.
  5. In the Import Certificate dialog box, click the button.
  6. Browse to the location of the pfx certificate file, highlight it, and then click Open.
  7. Type a password for the certificate, and then click OK.

Create a dedicated service account for the federation server farm

To configure a federation server farm environment in AD FS 2.0, you must create and configure a dedicated service account in Active Directory where the farm will reside. This dedicated service account is necessary to ensure that all resources required by the AD FS 2.0 farm are granted access to each of the federation servers in the farm.

You then configure each federation server in the farm to use this same service account. For example, if the service account that was created was fabrikam\ADFS2SVC, each computer that you configure for the federation server role and that will participate in the same farm must specify fabrikam\ADFS2SVC at this step in the Federation Server Configuration Wizard for the farm to be operational.

Note
You have to perform the tasks in this procedure only one time for the entire federation server farm. Later, when you create a federation server by using the AD FS 2.0 Federation Server Configuration Wizard, you must specify this same account on the Service Account wizard page on each federation server in the farm.

 

To create a dedicated service account for the federation server farm

  1. Create a dedicated user/service account in the Active Directory forest you will use in your organization.
  2. Edit the user account properties, and select the Password never expires check box. This action ensures that this service account’s function is not interrupted as a result of domain password change requirements.
    Note
    • If you need to change your password for the service account on a regular basis, see Configuring Advanced Options for AD FS 2.0.
    • Using the Network Service account for this dedicated account will result in random failures when access is attempted through Integrated Windows authentication, as a result of Kerberos tickets not validating from one server to another.

     

Install the AD FS 2.0 software

AD FS 2.0 software must be installed on any computer that you are preparing for the federation server role. You can install this software by either using the AD FS 2.0 Setup Wizard or by using a command-line parameter. For more information about this parameter, see AD FS 2.0 Deployment Guide.

Make sure to complete the installation process by installing all of the required hotfixes on each federation server computer, as indicated by the last step in this procedure.

To install the AD FS 2.0 software

  1. Download the AD FS 2.0 software package for your specific operating system version (either Windows Server 2008 or Windows Server 2008 R2) by saving the AdfsSetup.exe setup file onto the computer. To download this file, go to Active Directory Federation Services 2.0 RTW.
  2. Locate the AdfsSetup.exe setup file that you downloaded to the computer, and then double-click it.
  3. On the Welcome to the AD FS 2.0 Setup Wizard page, click Next.
  4. On the End-User License Agreement page, read the license terms.
  5. If you agree to the terms, select the I accept the terms in the License Agreement check box, and then click Next.
  6. On the Server Role page, select Federation server, and then click Next.
  7. On the Completed the AD FS 2.0 Setup Wizard page, click Finish.
    Important
    In some situations the AD FS 2.0 installation may require a restart (for example, when dependent hotfixes have been installed).

     

  8. Install all of the hotfixes as indicated in Installing AD FS 2.0 Hotfixes.

Configure the first federation server in the federation server farm

You can use the following procedure to set up the computer to become the first federation server in a new federation server farm using the AD FS 2.0 Federation Server Configuration Wizard.

Membership in Domain Admins, or a delegated domain account that has been granted write access to the Program Data container in Active Directory, is the minimum of access required to complete this procedure.

To create the first federation server in the federation server farm

  1. After the AD FS 2.0 software installation is complete, click Start, then Administrative Tools, and then AD FS 2.0 Management to open the AD FS 2.0 Management snap-in.
  2. On the Overview page, click AD FS 2.0 Federation Server Configuration Wizard.
  3. On the Welcome page, verify that Create a new Federation Service is selected, and then click Next.
  4. On the Select Stand-Alone or Farm Deployment page, click New federation server farm, and then click Next.
  5. On the Specify the Federation Service Name page, verify that the SSL certificate that is showing matches the name of the certificate that was imported into the Default Web Site in IIS previously. If this is not the correct certificate, select the appropriate certificate from the SSL certificate list.
    Note
    The wizard will not allow you to override the certificate if an SSL certificate is configured for IIS. This ensures that any intended prior IIS configuration for SSL certificates is preserved. To work around this issue, you can go back and import the certificate to the Default Web Site of IIS again.

     

  6. If you have previously reinstalled AD FS on this computer, then the Existing AD FS Configuration Database Detected page appears. If that page appears, click Delete database, and then click Next.
  7. On the Specify a Service Account page, click Browse. In the Browse dialog box, locate the domain account that will be used as the service account in this new federation server farm, and then click OK. Type the password for this account, confirm it, and then click Next.
    Note
    For more information about the service account that was created earlier in this article, see Create a dedicated service account for the federation server farm.

     

  8. On the Ready to Apply Settings page, review the details. If the settings appear to be correct, click Next to begin configuring AD FS 2.0 with these settings.
  9. On the Configuration Results page, review the results. When all the configuration steps are finished, click Close to exit the wizard.
Note
When you finish the steps in this procedure, the AD FS 2.0 Management snap-in will automatically open and a message will appear indicating that the Required Configuration is Incomplete and that you should Add a trusted relying party. You can disregard this message. A relying party trust for Office 365 will be added in a later step. For more information, see Install and configure the Microsoft Online Services Module for Windows PowerShell for single sign-on. Once this step has been completed, this message will disappear from the AD FS 2.0 Management snap-in.

 

Add a federation server to the federation server farm

After you install the AD FS 2.0 software and configure the required certificates on a computer, you are ready to configure the computer to become a federation server. You can use the following procedure to join a computer to a new federation server farm.

You join a computer to a farm with the AD FS 2.0 Federation Server Configuration Wizard. When you use this wizard to join a computer to an existing farm, the computer is configured with a read-only copy of the AD FS 2.0 configuration database and it must receive updates from a primary federation server.

To add a federation server to the federation server farm

  1. After the AD FS 2.0 software installation is complete, click Start, then Administrative Tools, and then AD FS 2.0 Management to open the AD FS 2.0 Management snap-in.
  2. On the Overview page, or in the Actions pane, click AD FS 2.0 Federation Server Configuration Wizard.
  3. On the Welcome page, verify that Add a federation server to an existing Federation Service is selected, and then click Next.
  4. If the AD FS 2.0 database that you selected already exists, the Existing AD FS Configuration Database Detected page appears. If that occurs, click Delete database, and then click Next.
    Caution
    Select this option only when you are sure that the data in this AD FS 2.0 database is not important or that it is not used in a production federation server farm.

     

  5. On the Specify the Primary Federation Server and Service Account page, under Primary federation server name, type the computer name of the primary federation server in the farm, and then click Browse. In the Browse dialog box, locate the domain account that is used as the service account by all other federation servers in the existing federation server farm, and then click OK. Type the password and confirm it, and then click Next.
    Note
    For more information about the service account that was created earlier in this article, see Create a dedicated service account for the federation server farm.

     

  6. On the Ready to Apply Settings page, review the details. If the settings appear to be correct, click Next to begin configuring AD FS 2.0 with these settings.
  7. On the Configuration Results page, review the results. When all the configuration steps are finished, click Close to exit the wizard.

Verify that the federation server is operational

You can use the following procedures to verify that a federation server is operational; that is, that any client on the same network can reach a new federation server.

Procedure 1: To verify that the federation server is operational

  1. Log on to a client computer that is located in the same forest as the federation server.
  2. Open a browser window. In the address bar, type the federation server’s DNS host name, and then append /adfs/fs/federationserverservice.asmx to it for the new federation server; for example:

    https://fs1.fabrikam.com/adfs/fs/federationserverservice.asmx

  3. Press ENTER, and then complete the next procedure on the federation server computer. If you see the message There is a problem with this website’s security certificate, click Continue to this website.

    The expected output is a display of XML with the service description document. If this page appears, IIS on the federation server is operational and serving pages successfully.

Procedure 2: To verify that the federation server is operational

  1. Log on to the new federation server as an Administrator.
  2. Click Start, point to Administrative Tools, and then click Event Viewer.
  3. In the details pane, double-click Applications and Services Logs, double-click AD FS 2.0 Eventing, and then click Admin.
  4. In the Event ID column, look for event ID 100. If the federation server is configured properly, you see a new event—in the Application log of Event Viewer—with the event ID 100. This event verifies that the federation server was able to successfully communicate with the Federation Service.

Back to top

6. Deploy your federation server proxies

AD FS 2.0 federation server proxies reside in the extranet to act as a proxy for client logons to a federation server that is located in the corporate network. The federation server proxy also facilitates the distribution of security tokens for remote clients that are attempting to access Office 365.

The following checklist includes the deployment tasks that are necessary to deploy two federation server proxies that will redirect authentication requests to a federation server in your new federation server farm.

Note
  • It is recommended that you deploy at least two federation server proxies in order to provide fault tolerance and use an NLB host for fault tolerance and load balancing.
  • You can use Forefront Unified Access Gateway (UAG) or Forefront Threat Management Gateway (TMG) to publish AD FS 2.0 to the extranet. For more information about how to do this, see Configuring Advanced Options for AD FS 2.0.
  • You can also use third-party HTTP reverse proxy solutions to publish AD FS 2.0 to the extranet.
  • To complete all of the tasks using the procedures in this section you must first be logged into the computers as a member of the Administrators group, or have been delegated equivalent permissions.

 

icon_chlst_contento Step 6–Checklist 1: Prepare your network infrastructure for federation server proxies

Deployment task Links to topics in this section Completed
1. Prepare two computers running either the Windows Server 2008 or Windows Server 2008 R2 operating system to be set up as federation server proxy. Depending on the number of users you have, you can use existing web or proxy servers or use a dedicated computer. N/A icon_checkboxo
2. Add the name of the Federation Service in the corporate network (the cluster DNS name you created earlier on the NLB host in the corporate network) and its associated cluster IP address to the hosts files on each federation server proxy computer in the perimeter network. Add the cluster DNS name and IP address to the hosts file on the proxy computer icon_checkboxo
3. Create a new cluster DNS name and cluster IP address on the NLB host in the perimeter network and then add the federation server computers to the NLB cluster. If you are using Windows Server technology for your current NLB hosts, choose the appropriate link to the right based on your operating system version.

Important
The cluster DNS name used for this new NLB cluster must match the name of the Federation Service in the corporate network.

 

To create and configure NLB clusters on Windows Server 2003 and Windows Server 2003 R2, see Checklist: Enabling and configuring Network Load Balancing.

To create and configure NLB clusters on Windows Server 2008, see Creating Network Load Balancing Clusters.

To create and configure NLB clusters on Windows Server 2008 R2, see Creating Network Load Balancing Clusters.

icon_checkboxo
4. Create a new resource record for the NLB cluster in the perimeter network DNS that points the cluster DNS name of the NLB cluster to its cluster IP address. Add a resource record to the perimeter DNS for the cluster DNS name configured on the perimeter NLB host icon_checkboxo
5. Use the same server authentication certificate as the one used by the federation servers in the corporate network and install it in IIS on the Default Web Site of the federation server proxy. Import a server authentication certificate to the Default Web Site on the proxy computer icon_checkboxo

icon_chlst_contento Step 6–Checklist 2: Deploy your federation server proxies

Deployment task Links to topics in this section Completed
1. Install the AD FS 2.0 software on the computer that will become the federation server proxy. Install the AD FS 2.0 software on the proxy computer icon_checkboxo
2. Configure the AD FS 2.0 software on the computer to act in the federation server proxy role by using the AD FS 2.0 Federation Server Proxy Configuration Wizard. Configure a computer for the federation server proxy role icon_checkboxo
3. Using Event Viewer, verify that the federation server proxy service has started. Verify that the federation server proxy is operational icon_checkboxo

Add the cluster DNS name and IP address to the hosts file on the proxy computer

In order for the federation server proxy to work as expected in the perimeter network, you must add an entry to the hosts file on each federation server proxy computer that points to the cluster DNS name hosted by the NLB in the corporate network (for example, fs.fabrikam.com) and its IP address (for example, 172.16.1.3). Adding this entry to the hosts file enables the federation server proxy to properly route a client-initiated call to a federation server either within the perimeter network or outside the perimeter network.

To add the cluster DNS name and IP address to the hosts file on the proxy

  1. Navigate to the %systemroot%\Winnt\System32\Drivers directory folder and locate the hosts file.
  2. Start Notepad, and then open the hosts file.
  3. Add the IP address and the host name of a federation server in the hosts file, as shown in the following example:

    172.16.1.3             fs.fabrikam.com

  4. Save and close the file.
Important
If the cluster IP address on the NLB host in the corporate network ever changes, you must update the local hosts file on each federation server proxy.

 

Add a resource record to the perimeter DNS for the cluster DNS name configured on the perimeter NLB host

To service authentication requests from clients either in the perimeter network or outside the perimeter network, AD FS 2.0 requires name resolution to be configured on external-facing DNS servers that host the organization’s zone (for example, fabrikam.com).

To do this, add a Host (A) Resource Record to the external-facing DNS server that serves only the perimeter network for the cluster DNS name (for example, “fs.fabrikam.com”) to point to the external cluster IP address that has just been configured.

To add a resource record to the perimeter DNS for the cluster DNS name configured on the perimeter NLB host

  1. On a DNS server for the perimeter network, open the DNS snap-in. Click Start, point to Administrative Tools, and then click DNS.
  2. In the console tree, right-click the applicable forward lookup zone (for example, fabrikam.com), and then click New Host (A or AAAA).
  3. In Name, type only the name of the cluster DNS name you specified on the NLB host in the perimeter network (this should be the same DNS name as the name of the Federation Service). For example, for the FQDN fs.fabrikam.com, type fs.
  4. In IP address, type the IP address for the new cluster IP address you specified on the NLB host in the perimeter network. For example, 192.0.2.3.
  5. Click Add Host.

Import a server authentication certificate to the Default Web Site on the proxy computer

After you obtain a server authentication certificate used by one of the federation servers in the corporate network, you must manually install that certificate on the Default Web Site for each federation server proxy in your organization.

Because this certificate must be trusted by clients of AD FS 2.0, use an SSL certificate that is issued by a public (third-party) CA or by a CA that is subordinate to a publicly trusted root, for example, VeriSign or Thawte. For information about installing a certificate from a public CA, see IIS 7.0: Request an Internet Server Certificate.

Note
The subject name of this server authentication certificate must match the FQDN of the cluster DNS name (for example, fs.fabrikam.com) you created earlier on the NLB host. If Internet Information Services (IIS) has not been installed, you must install IIS first in order to complete this task. When installing IIS for the first time, we recommend that you use the default feature options when prompted during the installation of the server role.

 

To import a server authentication certificate to the Default Web Site on the proxy computer

  1. Click Start, point to All Programs, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
  2. In the console tree, click ComputerName.
  3. In the center pane, double-click Server Certificates.
  4. In the Actions pane, click Import.
  5. In the Import Certificate dialog box, click the button.
  6. Browse to the location of the pfx certificate file, highlight it, and then click Open.
  7. Type a password for the certificate, and then click OK.

Install the AD FS 2.0 software on the proxy computer

AD FS 2.0 software must be installed on any computer that you are preparing for the federation server proxy role. You can install this software by either using the AD FS 2.0 Setup Wizard or by using a command-line parameter. For more information about this parameter, see AD FS 2.0 Deployment Guide.

Make sure to complete the installation process by installing all of the required hotfixes on each federation server proxy computer, as indicated by the last step in this procedure.

To install the AD FS 2.0 software on the proxy computer

  1. Download the AD FS 2.0 software package for your specific operating system version (either Windows Server 2008 or Windows Server 2008 R2) by saving the AdfsSetup.exe setup file onto the computer. To download this file, go to Active Directory Federation Services 2.0 RTW.
  2. Locate the AdfsSetup.exe setup file that you downloaded to the computer, and then double-click it.
  3. On the Welcome to the AD FS 2.0 Setup Wizard page, click Next.
  4. On the End-User License Agreement page, read the license terms.
  5. If you agree to the terms, select the I accept the terms in the License Agreement check box, and then click Next.
  6. On the Server Role page, select Federation server proxy, and then click Next.
  7. On the Completed the AD FS 2.0 Setup Wizard page, verify that the Start the AD FS 2.0 Federation Server Proxy Configuration Wizard when this wizard closes check box is selected, and then click Finish to restart the computer.
    Important
    In some situations the AD FS 2.0 installation may require a restart (for example, when dependent hotfixes have been installed). In that case, make sure to select the Restart now check box on the Completed the AD FS 2.0 Setup Wizard page, and then click Finish to restart the computer.

     

  8. Install all of the hotfixes as indicated in Installing AD FS 2.0 Hotfixes.

Configure a computer for the federation server proxy role

After you configure a computer with the required certificates and have installed the AD FS 2.0 software, you are ready to configure the computer to become a federation server proxy. You can use the following procedure so that the computer acts in the federation server proxy role.

Important
Before you use this procedure to configure the federation server proxy computer, make sure that you have followed all the steps for the checklists provided in Deploy your federation server farm in the order that they are listed. Make sure that at least one federation server is deployed and that all the necessary credentials for authorizing a federation server proxy configuration are implemented. You must also configure Secure Sockets Layer (SSL) bindings on the Default Web Site or this wizard will not start. All these tasks must be completed before this federation server proxy can function.

 

To configure a computer for the federation server proxy role

  1. On the Completed the AD FS 2.0 Setup Wizard page in the AD FS 2.0 Setup Wizard, a check box named Start the AD FS 2.0 Federation Server Proxy Configuration Wizard when this wizard closes is selected by default. Start the wizard, and then, on the Welcome page, click Next.
  2. On the Specify Federation Service Name page, under Federation Service name, type the name that represents the Federation Service for which this computer will act in the proxy role (for example, fs.fabrikam.com).
  3. Based on your specific network requirements, determine whether you will need to use an HTTP proxy server to forward requests to the Federation Service. If so, select the Use an HTTP proxy server when sending requests to this Federation Service check box, under HTTP proxy server address type the address of the proxy server, click Test Connection to verify connectivity, and then click Next.
  4. When you are prompted, specify the credentials that are necessary to establish a trust between this federation server proxy and the Federation Service.

    By default, only the service account used by the Federation Service or a member of the local BUILTIN\Administrators group can authorize a federation server proxy.

  5. On the Ready to Apply Settings page, review the details. If the settings appear to be correct, click Next to begin configuring this computer with these proxy settings.
  6. On the Configuration Results page, review the results. When all the configuration steps are finished, click Close to exit the wizard.

After you finish setting up the computer, verify that the federation server proxy is working as expected.

Verify that the federation server proxy is operational

You can use the following procedure to verify that the federation server proxy can communicate with the Federation Service in AD FS 2.0. You run this procedure after you run the AD FS 2.0 Federation Server Proxy Configuration Wizard to configure the computer to run in the federation server proxy role. For more information about how to run this wizard, see Configure a computer for the federation server proxy role.

Note
The result of this test is the successful generation of a specific event in Event Viewer on the federation server proxy computer.

 

To verify that the federation server proxy is operational

  1. Log on to the federation server proxy as an Administrator.
  2. Click Start, point to Administrative Tools, and then click Event Viewer.
  3. In the details pane, double-click Applications and Services Logs, double-click AD FS 2.0 Eventing, and then click Admin.
  4. In the Event ID column, look for event ID 198.

    If the federation server proxy is configured properly, you will see a new event in the Application log of Event Viewer, with the event ID 198. This event verifies that the federation server proxy service was started successfully and now is online.

Back to top

7. Next step and additional references

After you have successfully deployed your AD FS 2.0 infrastructure, you need to set up the relying party trust between your new AD FS 2.0 servers on-premises and Office 365. For more information, see Install and configure the Microsoft Online Services Module for Windows PowerShell for single sign-on.

If you would like to read additional information about AD FS 2.0, you can use following reference links to locate authoritative technical documentation that has been reviewed by the AD FS 2.0 product team.

General information about AD FS 2.0

For general overview, evaluation, or advanced troubleshooting information about AD FS 2.0, use the following applicable reference links:

Additional deployment information about AD FS 2.0

If you are considering deploying a more complex AD FS 2.0 infrastructure than what is provided in this article, consider reviewing more advanced planning and deployment information using the following reference links.

Written by bekirakgul

17/10/2011 at 09:39

Ofis 365 kategorisinde yayınlandı

Ofis 365 “Single Sing On” Yol Haritası

leave a comment »

Single sign-on: Roadmap

Single sign-on, also called identity federation, allows you and your users to access services in Microsoft Office 365 for enterprises with your Active Directory corporate credentials. Without single sign-on, you, the administrator, and your users will need to maintain separate user names and passwords for your online and on-premises accounts. Single sign-on requires both Active Directory Federation Services 2.0 and Active Directory synchronization.

The following diagram illustrates how your on-premises Active Directory and your AD FS 2.0 federation server farm interact with Office 365 in the cloud. When you set up single sign-on, you establish a relying party trust between AD FS 2.0 and Office 365. Local Active Directory users obtain authentication tokens from AD FS 2.0 that redirect the users’ requests through the relying party trust. This allows your users to access Office 365 without needing to sign in with different credentials.

AD FS and Office 365

Step 1: Prepare for single sign-on

To prepare for single sign-on, you can learn about single sign-on benefits and what your users will experience when they connect from different locations. You also should make sure your environment meets the requirements for single sign-on and verify that your Active Directory is set up in a way that is compatible with single sign-on requirements. For more information, see Prepare for single sign-on.

Step 2: Deploy Active Directory Federation Services 2.0

After you have prepared your environment for single sign-on, you deploy a new AD FS 2.0 infrastructure to provide your local and remote Active Directory users with single sign-on access to Office 365. If you currently have an AD FS 2.0 production environment, you can use that for single sign-on rather than setting up a new AD FS 2.0 infrastructure. For more information, see Plan for and deploy Active Directory Federation Services 2.0 for use with single sign-on.

Step 3: Install the Microsoft Online Services Module for Windows PowerShell

Once you have deployed your AD FS 2.0 production environment on-premises, you establish a relying party trust relationship between the AD FS 2.0 federation server farm and Office 365. This federated trust acts as a secure channel where authentication tokens can safely pass between your organization and Office 365. To add or convert a domain for single sign-on and establish this trust, you must both download the Microsoft Online Services Module for Windows PowerShell and run cmdlets in Windows PowerShell. For more information, see Install and configure the Microsoft Online Services Module for Windows PowerShell for single sign-on.

Step 4: Verify additional domains

If you have any additional domains that don’t use single sign-on, add these domains to Office 365 and then verify them. For more information, see Add your domain to Office 365 and Verify a domain at any domain name registrar.

Steps 5 to 9: Set up Active Directory synchronization

In order for single sign-on to work properly, you must set up Active Directory synchronization as well. This includes preparing for, activating, installing a tool, and verifying directory synchronization. After you have verified directory synchronization, you activate your synced users. Using single sign-on and directory synchronization together ensures that user identities are represented correctly in Office 365. To set up directory synchronization, see Active Directory synchronization: Roadmap.

Step 10: Verify and manage single sign-on

Verify that single sign-on was set up correctly and learn how to maintain single sign-on and directory synchronization. For more information, see Verify and manage single sign-on and Manage directory synchronization.

Written by bekirakgul

17/10/2011 at 09:37

Ofis 365 kategorisinde yayınlandı

Takip Et

Her yeni yazı için posta kutunuza gönderim alın.