GAPTHEGURU

Geek with special skills

How to setup Active Directory Federation Services

Part 1

Active directory federation service is Windows component which enables authentication of users on sites beyond its administrative domain. Example for this type of authentication is when users from one site have to access resources on some external site such as resources in partner network (e.g. Partner web sites etc.) When resource on remote site needs authentication for accessing, but “local” credentials should to be used, that is point where Active Directory Federation Service (AD FS) takes place.

Active Directory Federation Services enable using your AD (Active Directory) service to authenticate its users when they access resources belonging to other domains and placed on remote locations. To enable service which allows this type of authentication Active Directory federation should de established between two remote sites. There should be Active Directory Federation servers placed on both locations.

User authentication on site where resources reside and where user tries to access are based on token issued by federation services server on user location. Next picture shows AD FS architecture:

On user side, where Account Federation server resides is AD controller which authenticates users. On remote location in resources site is Resource Federation Server which participate in user authentication on remote site.

Follow scenario happens when user tries to access recourse on remote side:

1. User send request to access resource

2. Application server(SharePoint on picture) contacts Resource Federation server to authenticate user

3. Resource Federation server claim Account Federation server providing user identities

4. Account Federation server send user identities to Active Directory which authenticates user

5. Account Federation server creates token for user and send it to Resource federation server

6. When receive token for user Receive Federation server creates service token and forward it to resource server (SharePoint) and authentication process is completed.

On described way is provided SSO (single sign on) mechanism for users accessing resources on locations which are out of its administration boundary. Trust between two organizations is established though Active Directory Federation services.

To establish federation between two sites a few steps should be performed:

– Installation AD Federation Services on Account and Resource Federation servers

– Configuration of resource server(web server or other application server to which resources clients access)

– Configuration of Federation Servers(both account and resource) to establish trusted relationships

–  Client configuration

Installation AD Federation Services on Account and Resource Federation servers

AD FS services can be installed as role on Windows Server 2008. To begin installation go to Start->Administrative Tools->Server Manager. Then right click on roles and Add Role. Opens Add roles wizard:

Click on Active Directory Federation Services and then Next. Next window is Role Services. Click on check box by component you want to install (in this case Federation Service):

Maybe you will be prompted to install additional services such as IIS or some components of IIS needed for AD FS working. Confirm installation additional services (click on Add Required Role Services). When installation finishes click Next. Window for choosing SSL certificate for AD FS server appears. This certificate will be used for securing communication between clients and federation server.

As certificate for SSL connection you can choose existing certificate issued by your enterprise CA authority or create self signed certificate created on federation server. In this example self signed certificate will be used. For that click Create a self-signed certificate for SSL encryption and click Next. Opens window for token signing certificate:

Token signing certificate is used for signing tokens issued for client authentication on remote site where are resources which client want to access. When client make request to access resources application server (SharePoint on picture) request Resource Federation server to identify client. Resource Federation Server then contacts Account Federation Server on client side. When request for client authentication comes to Account Federation Server this server contacts AD controller which authenticates client. After client authentication  by AD is finished, Account Federation Server generates token signed by Token-Signing Certificate and sent it to Resource Federation Server which then generates service token and send it to resource server. When this process is completed client can access resources.

After Token-signing certificate is generated click next. Appears window for trust policy generation:

Trust policy defines rules applied when request from partner Federation Server comes to authenticate user. It defines situations in request should be accept or denied and types of information should be included in token issued to Federation Server on the side of partner organization. Trust policy can be created for this purpose or existing can be used. In this example we will create new policy. Click on Create new policy and then Next. Appears window with list of services which will be installed:

In this case AD Federation service and IIS server will be installed.

When verify which services will be installed click Install to begin installation process. After finishing window which shows results of installation is displayed:

With this last step AD FS server role is installed. On the same way this role installs on both Recourse and Account Federation server. After installing AD FC roles servers should be properly configured for trust relationship and communication establishing. Also resource server should be configured to be aware of federation server.

PART 2

When you have Federation Services installed as server roles on both sides of federation (account and resource) you have to properly configure servers to establish trust between them. Configuration includes configuring trust policy on both servers, create and configure group claim and AD account store and establish trust by importing policy from one federation server to another, on partner side. In this article I will describe process of AD FS server configuration. Configuration of both federation servers (account and resource) will be described.

Configuring Federation Services on federation servers

 Trust policy configuration

First thing to configure is trust policy configuration. To do that go through next steps:

1. Open AD FS configuration console. Go to Start->Administrative Tools and click Active Directory Federation Services. Opens next window:

2. On console tree double click Federation Services and then right click on Trust Policy and then Properties:

3. On General tab in Federation Services URI type URI of AD Federation Service. This URI is used to identify federation service on federation server. If AD FS is installed on server farm this URI should be same for all servers in farm. Also, in partner organization this URI should be same in trust policy imported from partner.

4. In the Federation Service endpoint URL text box URL of federation service appear. There is default URL, you can change it.

5. On Display Name tab type trust policy name and click OK.

On the same way trust policy should be configured on both federation servers, with differences in policy names, URLs and AD FS URIs.

Create group claim for claim-aware application

1. For authentication requests from partner side to be handled group claim should be created. To create group claim Go to Start->Administrative Tools and click Active Directory Federation Services

2. On console tree double click Federation Services, double click Trust Policy, double click My Organization, right click Organization Claims, go to New and click Organization Claim

3. In the Create a New Organization Claim dialog box in Claim name type name of new organization claim. It is claim from AD FS service on other (partner) side, let say Partner Claim.

4. Ensure that Group claim is selected and click OK

Claim should be configured on both sides, Account Federation server and Resource Federation Server

Add AD account store

When group claim is created and configured account store should be added. It is store in which are placed user credentials authenticated during resource accessing . In this case Active Directory will be used as account store. AD is most efficient and most used store for users when AD FS services are used.

To add AD as account store do next steps:

1. Go to Start->Administrative Tools and click Active Directory Federation Services

2. On console tree double click Federation Services, double click Trust Policy, double click My Organization, right click Account Stores, go to New and click Account Store:

3. On the Welcome to the Add Account Store Wizard page, click Next.

4. On the Account Store Page Active Directory Domain Services should be selected. Click Next

5. Enable this Account Store page appears. Enable this account store check box should be selected. Click Next

6.  On the Completing the Add Account Store Wizard page, click Finish

Adding account store in configuring AD FS server should be performed on both federation servers (Account and Resource)

Map a global group to the group claim for claims aware application

1. Go to Start->Administrative Tools and click Active Directory Federation Services

2. On console tree double click Federation Services, double click Trust Policy, double click My Organization , double click Account Stores, right click Active Directory, go to New and click Group Claim Extraction.

3. In Create a New Group Claim Extraction dialog box, click Add, type name of your mapping, for example partnerclaimusers, and then click OK.

4. Map to this Organization Claim menu should display group claim for partner organization, in this case Partner Claim we configured earlier. Click OK

Mapping a global group to the group claim should be configuring only on account federation server side because user that accessing resources are on that side, in same domain as account AD FS server. On this side of resource federation server claims aware application should be added and configured.

Adding and configuring claims aware application on AD FS of resource federation server

When configuring account federation server map group claim to group of users in AD is needed. On the other side, on resource federation server mapping of claims aware application should be done to connect application to which clients access with federation service. To add claim aware application do next steps on Resource Federation server:

1. Go to Start->Administrative Tools and click Active Directory Federation Services

2. On console tree double click Federation Services, double click Trust Policy, double click My Organization, right click Application, go to New and click Application.

3. On the Welcome to the Add Application Wizard page, click Next

4. On the Application Type page, click Claims-aware application, and then click Next.

5. On the Application Details page, in Application Display Name, type Claims-aware Application

6. In application URL type URL of your web application to which client access (e.g. http://web.domain.com/application

7. On the Accepted Identity Claims page, click User principal name (UPN), and then click Next.

8. On the Enable this application page check Enable this application and click Next

9. Click finish on Completing the Add Application Wizard page

After adding claims aware application group claim should be added to application. For this go to Applications folder, click to Claims aware application, right click to your group claim and click Enable.

When described settings are done federation servers are configured for federation but for establishing full trust between servers exporting and importing trust policies between servers is needed. When policies are exchanged trust between servers is established and AD FS service is configured between organizations.

Advertisements

05/23/2012 Posted by | Active Directory, ADFS, Federation, Security, SSO, Windows Server | , , | 1 Comment

Active Directory Windows 2008 and 2008 R2 Documentation

Here are some documents that may help you with some specific Active Directory tasks
(I’ll try to keep this list updated).

Global:
Changes in Functionality from Windows Server 2003 with SP1 to Windows Server 2008
Changes in Functionality in Windows Server 2008 R2 and from TechNet
Active Directory Design Guide
AD DS Deployment Guide
AD DS Installation and Removal Step-by-Step Guide
Active Directory Domain Services – Technet & Operations Guide.doc
Running Domain Controllers in Hyper-V

Licensing
Windows Server 2008 R2 Licensing Overview
Licensing Microsoft Server Products in Virtual Environments white paper

DNS:
DNS Step-by-Step Guide
DNSSEC Deployment Guide

Migration/Upgrade:
Upgrading Active Directory Domains to Windows Server 2008 and Windows Server 2008 R2 AD DS Domains & from TechNet
Migrate Server Roles to Windows Server 2008 R2
ADMT Guide: Migrating and Restructuring Active Directory Domains
Windows Server 2008 R2 Migration Utilities x64 Edition

Read Only Domain Controllers:
Read-Only Domain Controllers (RODC) Branch Office Guide and from TechNet
Read-Only Domain Controllers (RODC) in the Perimeter Network
Read-only Domain Controllers Step-by-Step Guide from TechNet
Read-only Domain Controllers Known Issues for Deploying RODCs
Read-Only Domain Controllers Planning and Deployment Guide

Firewall:
Active Directory and Active Directory Domain Services Port Requirements
Service overview and network port requirements for the Windows Server system
How to configure a firewall for domains and trusts
How to restrict FRS replication traffic to a specific static port
Restricting Active Directory replication traffic and client RPC traffic to a specific port
Active Directory Domain Services in the Perimeter Network (Windows Server 2008)
Active Directory in Networks Segmented by Firewalls (Windows Server 2003)

Security/Delegation:
How to Delegate Basic Server Administration To Junior Administrators
Best Practice Guide for Securing Active Directory Installations.doc
Active Directory Domain Services in the Perimeter Network (Windows Server 2008)
Windows 2000 Security Event Descriptions (Part 1 of 2)
Windows 2000 Security Event Descriptions (Part 2 of 2)
Description of security events in Windows Vista and in Windows Server 2008
Description of security events in Windows 7 and in Windows Server 2008 R2
How to use Group Policy to configure detailed security auditing settings KB 921469
Security Auditing Windows Server 2008, Windows Server 2008 R2 TechNet

Backup/Recover:
Recovering Your Active Directory Forest
How to restore deleted user accounts and their group memberships in Active Directory KB840001
How to restore deleted user accounts and their group memberships in Active Directory
Best practices around Active Directory Authoritative Restores in Windows Server 2003 and 2008
The importance of following ALL the authoritative restore steps

05/03/2012 Posted by | Active Directory, Windows Server | | Leave a comment

Installation of SSO on SQL Failover Cluster

In this post I will tell a story of my experience with installation of SSO on SQL Cluster. Each BizTalk Server has an Enterprise Single Sign-On service (EntSSO.exe). Enterprise Single Sign-On is also referred as SSO or EntSSO. SSO serves two purposes. One is for data encryption, that is, port URI data. And the other is, as what the name indicates, Single Sign-On. Single Sign-On is about credential mapping. BizTalk Server SSO currently supports only Windows-initiated Single Sign-On. That means you can only map Windows users accounts to external application (affiliate application) user accounts. On the inbound side the sender is authenticated with Windows; on the outbound side, BizTalk Server automatically authenticates with the affiliate applications using the preconfigured credential mapping. Single Sign-On is a useful feature in business-to-business (B2B) scenarios.

Note: However the encryption function is mandatory for a BizTalk system. Single Sign-On for credential mapping can be solved with other tools like Oracle Wallet.

In addition to the SSO services running on each of the BizTalk Servers, there is a master secret server. The master secret server is a server with the SSO service running on it. The master secret server can be one of the SSO services running on one of the BizTalk Servers, or a dedicated master secret server.

It is the same executable called EntSSO.exe, but with an additional sub component responsible for maintain and supply the master secret key to the SSO services on the other BizTalk Servers. The other SSO services running on the BizTalk Servers check every 30 seconds to see whether the master secret has changed. If it has changed, they read it securely; otherwise, they continue to use the master secret they already have cached in memory.

Considering there is only one master secret server in your entire environment and the dependency of BizTalk Server, it is recommended that you use an active-passive cluster configuration for the master secret server. Because the master secret server doesn’t consume a lot of resources, it is very common to use the SQL Server failover cluster for clustering the master secret server.

On the first server cluster node where you run BizTalk Server Configuration, you choose to create a new SSO system. That makes the cluster node as the master secret server. The host name of the master secret server is the host name of the physical cluster node. The master secret key is automatically generated on that node. On the other cluster node, you choose to join the existing SSO system. To cluster the master secret server, you need to change the master secret server from the first cluster node host name to the virtual SQL Server failover cluster network name (NameSQL1), and create a SSO generic service cluster resource. At the end, you restore the master secret key to the other cluster nodes. So, when the cluster fails over to another node, that node has the master secret. These steps can be done using the domain admin account (usually a network senior administrator will perform these steps with this account i.e. as example I will name the account InstallBizTalk).

Clustering the master secret server service is a complicated process. You might find it confusing when and where you need to perform a step, and the order of the steps. Here are some general rules:

· You must install and configure SSO on each of the cluster nodes. When you create the new SSO system on the first cluster node, this node can be either an active cluster node or a passive cluster node.

· After you successfully installed and configured SSO on all of the cluster nodes, you must update the master secret server host name from a physical cluster node host name to the virtual cluster network name, and you must change the rename from an active node.

· After the master secret server host name is changed, you must restart the SSO service on the active node to refresh the cache by taking the SSO cluster resource offline and then online.

· You must create an SSO cluster resource before restoring the master secret key on the other cluster nodes.

· Before you restore the master secret key on a cluster node, you must make it the active node first.

Steps involved to successfully install and configure SSO on cluster will be outlined here.

There are several SSO user groups. Two of them are required when configuring the master secret server. SSO Administrators have the highest level user rights in the SSO system; and SSO Affiliate Administrators defines the affiliate applications that the SSO system contains.

To create a domain group account for the SQL Server service groups

1. If you haven’t already logged on or if you are logged on with a different credential, log on to Cluster Node A using domain admin account.

2. Click Start, and then click Run.

3. In the Run dialog box, enter dsa.msc, and then click OK.

4. From Active Directory Users and Computers, if the YourDomain domain is not already expanded, click the plus sign (+) to expand the YourDomain.com domain.

5. In the left pane, right-click Users, point to New, and then click Group.

6. From New Object – Group, enter the following values, and then click OK.

Name Value
Group name SSO Administrators
Group scope Global
Group type Security

7. Repeat steps 5 to 6 to create one more group:

Name Value
Group name SSO Affiliate Administrators
Group scope Global
Group type Security

To create a domain user account for the SSO Service

1. (continue from the previous procedure)

2. In the left pane, right-click Users, point to New, and then click User.

3. From New Object – User, enter the following values, and then click Next.

Name Value
First name SSO
Last name Service
User logon name SSOService

4. Enter or select the following values, and then click Next.

Name Value
Password TBD
Confirm password TBD
User must change password at next logon (clear)
User cannot change password (select)
Password never expires (select)
Account is disabled (clear)

5. Click Finish.

Both YourDomain\SSOSerivce and domain admin account need to be members of the YourDomain\SSO Administrators group. It is designated for installing and configuring the BizTalk Server system.

To make YourDomain\SSOService and domain admin account members of SSO Administrators

1. (continue from the previous procedure)

2. In the left pane, highlight Users.

3. In the right pane, right-click SSO Service, point to All Tasks, and then click Add to a group.

4. From Select Group, enter or select the following values, and then click OK.

Name Value
Select this object type Group or Built-in security principal
From this location YourDomain
Enter the object name to select SSO administrators

5. To acknowledge that the account was created, click OK.

6. Repeat steps 3 to 5 to add domain admin account into the same group.

Granting YourDomain\SSO Administrators Full Control on Cluster Node A

You need to grant YourDomain\SSOService or YourDomain\SSO Administrators with the full control privilege on the cluster administrator.

To grant YourDomain\SSO Administrators full control on the cluster

1. If you haven’t already logged on or if you are logged on with a different credential, log on to Cluster Node A as YourDomain\IInstallBizTalk.

2. Click Start, point to All Programs, point to Administrative Tools, and then click Cluster Administrator.

3. From Cluster Administrator, in the left pane, right-click CLUSTER NODE A, and then click Properties.

4. From CLUSTER NODE A Properties, click the Security tab, and then click Add.

5. From Select Users, Computers, or Groups, enter the following values, and then click OK.

Name Value
Select this object type Group or Built-in security principal
From this location YourDomain.com
Enter the object name to select SSO administrators

6. Verify the Allow box is selected, and then click OK.

Installing the SSO Components on Cluster Node A

With the accounts and permissions configured in the last step, you can now install the master secret server. BizTalk Server is not cluster aware as SQL Server is. You will need to install SSO on each of the cluster nodes. You will also need to create the SSO cluster resource manually.

BizTalk Server installation process has two parts. In this step, you will install the components. And the next step is configuring the master secret server.

To install the SSO components on Cluster Node A and Cluster Node B

1. If you haven’t logged on, log on to Cluster Node A as YourDomain\InstallBizTalk.

2. Run setup.exe to install BizTalk Server 2006 R2.

3. On the Start page, click Install Microsoft BizTalk Server 2006 R2 on this computer.

4. On the Customer Information page, enter information in the User name box, the Organization box, and the Product key box, and then click Next.

5. On the License Agreement page, read the license agreement, select yes, I accept the terms of the license agreement, and then click Next.

6. On the Component Installation page, clear all the check boxes, select Enterprise Single Sign-On Administration Module and Enterprise Single Sing-On Master Secret Server from the Additional Software group, and then click Next.

clip_image002

7. On the Summary page, click Install.

8. On the Installation Completed page, clear Launch BizTalk Server Configuration check box, and then click Finish.

Installing the SSO Components on Cluster Node B

Repeat the same steps to install the SSO components on Cluster Node B.

Configuring the Master Secret Server on Cluster Node A

Configuring the master secret server has three parts, creating SSO database, assigning SSO service account, and backing-up the master secret. Notice there are two options, create a new SSO system, and join an existing SSO system. On the first cluster nodes, you must choose to create a new SSO system. When you create a new SSO system, you must specify the database server name, and the database name. But you don’t need to specify the master secret server host name. The current host name, becomes the default master secret server. Later, you must change the master secret server from the physical cluster node host name to the virtual cluster host name, YourVirtualServerName.

It doesn’t matter whether Cluster Node A is the active node or a passive node when you go through this procedure.

To configure the master secret server on Cluster Node A

1. If you haven’t logged on, log on to Cluster Node A as YourDomain\InstallBizTalk.

2. Click Start, point to All Programs, point to Microsoft BizTalk Server 2006, and then click BizTalk Server Configuration.

3. On the Microsoft BizTalk Server 2006 Configuration page, choose Custom Configuration, enter the following values, and then click Configure.

Name Value
Database server name Database Name Cluster
User name YourDomain\SSOService
Password TBD

4. in the left pane, click Enterprise SSO.

5. In the right pane, enter or select the following values:

Name Value
Enable Enterprise Single Sign-On on this computer (checked)
Create a new SSO system (selected)
SSO Database: Server Name Database Name Cluster
SSO Database: Database Name SSODB
Enterprise Single Sign-On Service: Account YourDomain\SSOService
SSO Administrator(s): Windows Group YourDomain\SSO Administrators
SSO Affiliate Administrators(s): Windows Group YourDomain\SSO Affiliate Administrators

image

6. In the left pane, click Enterprise SSO Secret Backup. The Enterprise SSO secret is very critical. You must back it up to a file. It is a good practice to burn the key into a CD and store the CD in a safe place.

7. In the right pane, enter the following values:

Name Value
Secret back password TBD
Confirm password TBD
Password reminder TBD
Backup file location C:\Program Files\Common Files\Enterprise Single Sign-On\SSOSecret.bak)

8. Click Apply Configuration.

9. On the Summary page, to apply the configuration, click Next.

10. Verify that the Configuration Result is Success, and then click Finish.

11. Close Microsoft BizTalk Server 2006 Configuration.

1.1.4 Configuring SSO on Cluster Node B

On the second node, you choose to join the existing SSO system. When joining the existing SSO system, it shares the SSO database of the existing SSO system.

To configure the master secret server on Cluster Node B

1. If you haven’t logged on, log on to Cluster Node B as YourDomain\InstallBizTalk.

2. Click Start, point to All Programs, point to Microsoft BizTalk Server 2006, and then click BizTalk Server Configuration.

3. On the Microsoft BizTalk Server 2006 Configuration page, choose Custom Configuration, enter the following values, and then click Configure.

Name Value
Database server name ServerName Database Cluster
User name YourDomainSSOService
Password TBD

4. In the left pane, click Enterprise SSO.

5. In the right pane, enter or select the following values:

Name Value
Enable Enterprise Single Sign-On on this computer (checked)
Join an existing SSO system (selected)
Server Name ServerName Database Cluster
Database Name SSODB
Account YourDomain\SSOService

6. Click Apply Configuration.

7. On the Summary page, to apply the configuration, click Next.

8. Verify that the Configuration Result is Success, and then click Finish.

9. Close Microsoft BizTalk Server 2006 Configuration.

1.1.5 Updating the Master Secret Server Host Name

When SSO was configured on the first cluster node, it created a new SSO system. It used the host name of the physical cluster node as the master secret server host name that is Cluster Node A. You must change it to the server cluster virtual name, which is YourVirtualClusterName. This procedure must be carried out from the active cluster node. All it does is to update the master secret server field in the SSO database.

To configure the master secret server on Cluster Node B

1. If you haven’t already logged on, log on to Cluster Node A as YourDomain\InstallBizTalk.

<sso>
  <globalInfo>
    <secretServer> ServerName Database Cluster</secretServer>
  </globalInfo>
</sso>

2. Open a notepad.exe, create a file with the following content, and then save it as “C:\Program Files\Common Files\Enterprise Single Sign-On\SSOCluster.xml” (with the double quotes). The content is case sensitive.

clip_image002[5]

3. Open a command prompt, and then change directory to the C:\Program Files\ Common Files\Enterprise Single Sign-On\ folder.

4. From the command prompt, execute the following command:

ssomanage -updatedb SSOCluster.xml

5. Verify the master secrete server name has been changed to  as shown below:

C:\Program Files\Common Files\Enterprise Single Sign-On>ssomanage -updatedb ssocluster.xml
Using SSO server on this computer
 
Updated SSO global information with the following values -
 
SSO secret server name                  : ServerName Database Cluster
SSO Admin account name                  : NOT CHANGED
SSO Affiliate Admin account name        : NOT CHANGE

image

Creating SSO Cluster Resource

BizTalk Server is not cluster aware. So you must manually create the master secret server cluster resource. You can either create a dedicated virtual server (cluster group) for the SSO cluster resource, or use an existing cluster group. The instructions provided use the SQL Server Cluster Group. If you create a dedicated cluster group, you also need to create a network name cluster resource depended by the SSO cluster resource.

To Create SSO cluster resource

1. If you haven’t already logged on, log on to Cluster Node A as YourDomain\InstBizTalk.

2. Click Start, point to All Programs, point to Administrative Tools, and then click Cluster Administrator.

3. In the left pane, expand CLUSTER NODE A, expand Groups, and then expand SQL Server Cluster Group. If you get a prompt before it opens Cluster Administrator, choose Open Existing Cluster, and point it to CLUSTER NODE A.

4. Right-click SQL Server Cluster Group, click New, and then click Resource.

5. From New Resource, enter or select the following values, and then click Next.

clip_image002[9]

6. From Possible Owners, verify that CLUSTER NODE A and CLUSTER NODE B are in the Possible owners list, and then click Next.

7. From Dependencies, select SQL Network Name (Cluster Node A) and click Add. And then click Next.

8. From Generic Service Parameters, type or select the following values, and then click Next:

clip_image002[11]

9. From Registry Replication, click Finish.

clip_image001Note
Do not configure any registry keys for replication in the Registry Replication dialog box. Replication of registry keys is not a requirement when creating a SSO cluster resource and, in fact, may cause problems when failover of this cluster resource is attempted.

10. In the details pane, right-click ENTSSO, and click Bring Online. Verify that the state is changed to Online.

Restoring the Master Secret on Cluster Node B

Before restoring the master secret on Cluster Node B, you must make Cluster Node B as the active cluster node, and restart the cluster resource by taking the cluster resource offline and then online.

To make Cluster Node B the active cluster node

1. Log on to Cluster Node B as RBW-NL\InstBizTalk.

2. Click Start, point to All Programs, point to Administrative Tools, and then click Cluster Administrator.

3. From Cluster Administrator, expand CLUSTER NODE A in the left pane, expand Groups, and then expand SQL Server Cluster Group. In the details pane, the Owner column of the cluster resources shows the active cluster node

4. If Cluster Node B is not the active cluster node, in the left pane right-click SQL Server Cluster Group, and then click Move Group. Wait until all the cluster resources are online.

5. In the details pane, right-click ENTSSO, and then click Take Offline. Wait until all the cluster resources are offline.

6. In the details pane, right-click ENTSSO, and then click Bring Online. Wait until all the cluster resources are online.

To restore the master secret on the second cluster node

1. Copy the master secret backup file, C:\Program Files\Common Files\Enterprise Single Sign-On\SSOSecret.bak, on Cluster Node A to the same folder on Cluster Node B. SSOSecret.bak is how you named the file when you configured the master secret server on Cluster Node A.

2. Open a command prompt, and then change the directory to C:\Program Files\Common Files\Enterprise Single Sign-On.

3. Type and execute the following command in the command prompt:

ssoconfig -restoresecret SSOSecret.bak

image

Through following this procedure you will be successful in deploying SSO on SQLCluster and configure SSO. My experience is that in following this procedure with an senior administrator inside an organization works the best. This procedure us done with BizTalk Server 2006 R2, but is also suitable for BizTalk Server 2009.

02/28/2012 Posted by | Active Directory, Biztalk, Cluster Configuration, Sql Server, SSO, Windows Server | , , , | 1 Comment

Understanding FSMO Roles in Server 2008 Active Directory

Overview

FSMO stands for Flexible Single Master Operations, and FSMO roles (also known as operations master roles) help you prevent conflicts in your Active Directory.

In this article I will examine the difference between the single and multi-master models in Windows Server 2000, 2003 and 2008 and I will go through what you need to know about the different FSMO roles. I will also take a look at FSMO reliability and availability and what’s new with FSMO in Windows Server 2008.

Windows 2000/2003/2008 Multi-Master Model

  • For most Active Directory objects, the task of updating can be performed by any Domain Controller except those Domain Controllers that are read-only. Updates such as computer object properties, renamed organizational units, and user account password resets can be handled by any writable domain controller.

    After an object is changed on one domain controller, those changes are propagated to the other domain controllers through replication. During replication all of the Domain Controllers share their updates. So a user that has their password reset in one part of the domain may have to wait until those changes are replicated to the Domain Controller that they are signing in from.

    This model works very well for most objects. In the case of any conflicts, such as a user’s password being reset by both the central helpdesk as well as an administrator working at the user’s site, then conflicts are resolved by whichever made the last change. However, there are some changes that are too important, and are not well suited to this model.

    Windows 2000/2003/2008 Single-Master Model

    There are 5 specific types of updates to Active Directory that are very specific, and conflicts should be avoided. To help alleviate any potential conflicts, those updates are all performed on a single Domain Controller. And though each type of update must be performed on a single Domain Controller, they do not all have to be handled by the same Domain Controller.

    These types of updates are handled by Domain Controllers Flexible Single Master Operations roles, or FSMO roles. Each of the five roles is assigned to only one domain controller.

    There are five of these FSMO roles in every forest. They are:

    • Schema Master
    • Domain Naming Master
    • Infrastructure Master
    • Relative ID (RID) Master
    • Primary Domain Controller (PDC) Emulator

    Additionally, three of those FSMO roles are needed once in every domain in the forest:

    • Infrastructure Master
    • Relative ID (RID) Master
    • Primary Domain Controller (PDC) Emulator

    Here is what you need to know about the different FSMO roles.

    • All Schema Changes and Updates to Active Directory are Processed by the DC with the Schema Master Role

    Whenever the schema is modified at all, those updates are always completed by the domain controller with the schema master role. Schema is updated during the normal replication, and the schema updates are replicated throughout all the domains in the forest. Since the schema master role is only needed once in the forest, it is kept in the forest root domain. It’s advisable to place the schema master role on the same domain controller (DC) as the primary domain controller (PDC) emulator.

    • Changes to Which Domains are Part of the Forest are Processed by the DC with the Domain Naming Master Role

    As domains join or leave the forest, the domain naming master makes the updates into active directory. Only this DC actually commits those changes into the directory. The domain naming master also commits the changes to application partitions. Like the schema master role, this role is a forest level FSMO, and it is only needed once across all domains in a forest. Also like the schema master, it is suggested to let this role be handled by the same domain controller – the PDC emulator in the forest root.

    • Each Domain in a Forest Translates Names for Other Domains Through Their Infrastructure Master

    The infrastructure master is a translator, between globally unique identifiers (GUIDs), security identifiers (SIDs), and distinguished names (DNs) for foreign domain objects. If you’ve ever looked at group memberships of a domain local group which has members from other domains, you can sometimes see those users and groups from the other domain listed only by their SID. The infrastructure master of the domain of which those accounts are in is responsible for translating those from a SID into their name.

    Each domain has their own infrastructure master, including the forest root and every child domain. Usually, you do not put the infrastructure master role on a domain that holds the global catalog. However, if you’re in a single domain forest, the infrastructure master has no work to do, since there is no translation of foreign principals. In that case it’s acceptable to place the infrastructure master it on any domain controller (DC), even if it has the global catalog. For a forest with multiple domains, if there’s even one domain controller that doesn’t have the global catalog on it, then you need to put the infrastructure master role on a domain controller that does not have the global catalog.

    • The Unique Part of a Security Identifier is Assigned from the Relative ID (RID) Master

    One of the first things understood about a security identifier (SID) is that they are unique. There are two parts of a SID: the domain identifier (domain ID), and the relative ID (RID). The domain identifier part of the SID is uniform among all security principals in the domain. When looking at a list of SIDs in a domain, it’s easy to identify the domain SIDs – they all look the same. On the contrary, the relative ID part of the SID is the unique part. The two parts together make up what we commonly identify as a SID.

    It is conceivable, then, that if two or more domain controllers were responsible for determining the relative IDs for the SIDs that two domain controllers may come up with the same relative ID for two different objects before they’ve replicated with each other.

    That is impossible when only one DC in a domain is responsible for the creation of the relative IDs for SIDs. The relative ID master, or RID master, hands out batches of relative IDs to individual domain controllers, then each domain controller can use their allotment to create new users, groups, and computers. When domain controllers need more relative IDs in reserve, they request them from, and are assigned by, the domain controller with the RID master FSMO role.

    Every domain in a forest must have a domain controller with the RID master FSMO role assigned to it. It is recommended that the RID master FSMO role be assigned to whichever domain controller has the PDC emulator FSMO role.

    • The Domain Controller (DC) That is the Primary Domain Controller (PDC) Emulator is the Authoritative DC in a Domain

    The domain controller that has the PDC emulator FSMO role assigned to it has many duties and responsibilities in the domain. For example, the DC with the PDC emulator role is the DC that updates passwords for users and computers. When a user attempts to login, and enters a bad password, it’s the DC with the PDC emulator FSMO role that is consulted to determine if the password has been changed without the replica DC’s knowledge. The PDC emulator is also the default domain controller for many administrative tools, and is likewise the default DC used when Group Policies are updated.

    Additionally, it’s the PDC emulator which maintains the accurate time that the domain is regulated by. It’s the time on the PDC emulator which identifies when the last write time for an object was (to resolve conflicts, for example.) If it’s a forest with multiple domains, then the forest root PDC is the authoritative time source for all domains in the forest.

    Each domain in the forest needs its own PDC emulator.

    // <![CDATA[
    ord = window.ord || Math.floor(Math.random()*1E16);
    document.write(”);
    //]]>
    // ]]>

    // <![CDATA[
    document.write(”);
    // ]]>
    //

    // <a href=”http://ad2.netshelter.net/jump/ns.petri/general;ppos=btf;kw=;tile=1;sz=300×600,300×250;ord=123456789?&#8221; target=”_blank” ><img src=”http://ad2.netshelter.net/ad/ns.petri/general;ppos=btf;kw=;tile=1;sz=300×600,300×250;ord=123456789?&#8221; border=”0″ alt=”” /></a>

    FSMO Reliability and Availability

    Due to the importance of the FSMO roles, the domain controllers need to be online at the time the services are needed. For some of the FSMO roles, such as schema master, this is not very much. It only needs to be online when the schema is updated. For other roles, such as the PDC emulator, it needs to be online and accessible all the time.

    Ideally, you put the PDC emulator on the domain controller with the best hardware available, and ensure that it’s in a reliable hub site. It should have other domain controllers in the same active directory domain and site to replicate with. Then, to reduce administration and complexity, you also assign at least some of the other FSMO roles to the same DC – the RID master to the PDC of each domain, and the schema master and domain naming master the PDC of the forest root.

    In the event that a DC with one of the FSMO roles is unavailable, especially the PDC emulator, it is critical for the domain to get that FSMO role back. If, for example, you know that the PDC emulator is going to have to be turned off for scheduled maintenance, you should transfer the FSMO role to a different domain controller. In the unfortunate event that the PDC emulator has crashed and is now down with an unplanned outage, you will have domain errors until the PDC emulator is bought back online. If you cannot get the PDC emulator back online, you may have to seize the FSMO role to another domain controller. It is always better to transfer ahead of time then have to seize the role after a crash. Seizing a role should be done only as a last resort. In the event of a seizure, you cannot ever bring the DC that previously held the role back online.

    New with Windows Server 2008 Active Directory is the ability to designate ahead of time a standby operations master. This domain controller is connected directly to the primary operations master role holders through replication to

    Summary

    When updating a part of Active Directory is too critical of an operation to risk a conflict, Windows Active Directory Domains utilize a single-server model to provide updates to those services. The right to update or perform certain duties in Active Directory is granted to domain controllers through the assignment of one of the Flexible Single-Master roles, or FSMO roles.

    There are five FSMO roles. Two of them, schema master and domain naming master, are only assigned once in the forest, in the domain at the forest root. The other three FSMO roles: RID master, PCD emulator, and the infrastructure master, are assigned in each domain, typically all to the same domain controller.

    The availability requirements of the domain controller with an FSMO role are dependent on the role. For example, the schema master may be offline without causing any concern until an update to the schema is attempted. FSMO roles can be transferred to another domain controller to improve performance or to allow for continued access during a scheduled outage. In the event of an unscheduled outage, FSMO roles may be seized as a last resort.

    Links

01/18/2012 Posted by | Active Directory, FSMO, SID, Windows Server | , , | Leave a comment

   

%d bloggers like this: