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.


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.

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.


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

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

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

DNS Step-by-Step Guide
DNSSEC Deployment Guide

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

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)

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

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

Understanding FSMO Roles in Server 2008 Active Directory


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);
    // ]]>

    // <![CDATA[
    // ]]>

    // <a href=”;ppos=btf;kw=;tile=1;sz=300×600,300×250;ord=123456789?&#8221; target=”_blank” ><img src=”;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


    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.


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


%d bloggers like this: