다음을 통해 공유

Accessing Resources across forest and achieve Single Sign ON (Part1)

  • 아티클

Accessing Resources across forest and achieve Single Sign ON (Part1)

This document focuses on the options which can be utilized achieving the single sign on while accessing resources across the forests in different scenarios outlined below.

Mergers and acquisition

Mergers and acquisition is one of the common scenarios we face in today’s world where companies having two different IT infrastructure running different platforms and applications, most of the time mergers and acquisition of the companies end up with merging their IT infrastructure as well but depending on the size of the companies and their IT infrastructure there is always a period of coexistence when both IT infrastructure are to be in fully functional mode and need some kind integration, or there might be a situation where IT heads and Application owners take decision about not migrating their applications across the forest, or legal boundaries and geographical boundaries do not allow companies to host their applications across the geographical boundaries but the identity objects are hosted in a directory services hosted in different geographical location than the application resources, there can be many more situation where resources are in one forest and user identities are in another forest and users would like to have single sing on experience maintaining the security of the resources and directory systems.

There is a lot of information available on the net in bits and pieces, I am trying to gather and put the information together, for easy understand we will take an example of two different forests contoso.com and fab.com, contoso.com is an account forest and also has some local application servers, and fab.com is a resource forest which has some application servers and users from contoso.com need to access the applications in fab.com

   

Diagram 1

Both contoso.com and fab.com are situated in two different geographical location protected with firewall, while we design the single sign on solution for such scenario we need to consider following.

  1. 1.       Network connectivity between Contoso.com and Fab.com
  2. 2.       Name resolution between Contoso.com and Fab.com
  3. 3.       Security
  4. 4.       High availability
  5. 5.       Authentication and Authorization

Network Connectivity between Contoso.com and Fab.com

As mentioned above contoso.com and fab.com are two different IT infrastructure situated in two different geographical locations and we need to have some means of connectivity between contoso.com and fab.com, keeping high availability and best practices in mind it is recommended to have dual connectivity links between two organizations and depending on the SLA of your ISP, it is worth having two different ISP providers providing network connectivity services, planning network connectivity should include the redundancy of every component of the network, firewall, routers, switches, network cards etc. so that if any one of the component along the way fails the redundancy of the component will cover the failure and prevent service interruption for users and also ensure that only required ports are opened on the firewall to ensure the security of the active directory and other application servers. Detailed planning of the networking is beyond the scope of this document

This document will focus on three options to achieve single sign on across

Part 1: Singe sing on with active directory forest trust

Part 2: Single sign on with Active directory Lightweight directory service

Part 3: Active Directory Federation Service

Active Directory Forest Trust

Trust Overview

  • ·         A trust is a relationship established between domains that enable users in one domain to be authenticated by a domain controller in the other domain.

Trust Architecture

Trust is creating secure channel between two domains, two forests or two realms the authentications coming from the other domains, forest, or realms. There are numerous number of components help to form the trust architecture such as authentication protocols (Kerberos, NTLM), the Net Logon service, the Local Security Authority (LSA), and the Trusted Domain Objects (TDOs) stored in Active Directory.

The trust relationships that we can view in Active Directory Domains and Trusts is represented by Trusted Domain Objects (TDO) stored in the System container within its domain. For a domain trust, attributes such as the DNS domain name, domain SID, trust type, trust transitivity, and the reciprocal domain name are represented in the TDO.

The architecture of trusts comprises a range of mutually dependent components; these components contain authentication, the Net Logon service and AD DS, which all rely on DNS to locate domain service records. AD DS provides the base for trust relationships by supplying a central management system through which domain administrators can grant access to trusted authorities in other domains. Trusts then provide the mechanism of authentication between domains or forests.

Trust Directions

The direction that a trust is assigned determines the valid trust path used for authentication. A trust path is defined by the series of trust relationships that authentication requests must follow between domains. Before a user can access a resource in another domain, the security system on domain controllers running on Windows 2003 Server or Windows Server 2008 must determine whether the trusting domain has a trust relationship with the trusted domain. To determine this, the security system computes the trust path between a domain controller in the trusting domain and a domain controller in the trusted domain. All domain trust relationships have only two domains: the trusting domain and the trusted domain.

 

Diagram 2

There are four types of Trust available

  1. 1.       External Trust
  2. 2.       Realm Trust
  3. 3.       Forest Trust
  4. 4.       Shortcut trust

For more information about the trust, refer to article https://technet.microsoft.com/en-us/library/cc775736(WS.10).aspx

In this document we will focus on Forest Trust, there are two types of forest trusts

  1. 1.       One Way Forest Trust
  2. 2.       Two Way Forest Trust

Both one way and two way forest trust are transitive in nature, transitive trust extends the trust relation other domains in the forest; by default all domains in a forest are transitive in nature

Trusted Domain Object

Trusted domain objects (TDOs) are objects that represent each trust relationship within a particular domain. Each time that a trust is established, a unique TDO is created and stored in its domain (in the System container). Attributes such as trust transitivity, type, and the reciprocal domain names are represented in the TDO.

Forest trust TDOs store additional attributes to identify all the trusted namespaces from its partner forest. These attributes include domain tree names, user principal name (UPN) suffixes, service principal name (SPN) suffixes, and security identifier (SID) namespaces.

Impact Analysis

Opening the forest trust will introduce the following impacts to both ends of the trust; the following lists the identified impacts and its mitigating measures to minimize impacts.

Impacts

Mitigation

Security - Kerberos Delegation

Agency application will be able to authenticate on behalf of users

Preventing sensitive user accounts to be delegated.

For application using the Kerberos delegation, it is recommended to be configured with Constrained Delegation, where the service account can only perform delegation of user accounts to limited set of functionalities within agency applications

For more information on Kerberos Constrained Delegation, refer to https://technet.microsoft.com/en-us/library/cc739587(WS.10).aspx

Security – Open firewall ports to allow connections from Agency domain controllers to domain controllers

Due diligence on both ends and to ensure the good practice of network operations and proactively monitoring network traffics to detect any suspicious and malicious activities.

Only open firewall ports to the domain controllers that require direct communication

Security - AD administrators may forge SID to gain access to agency resources

(refer to https://support.microsoft.com/?kbid=289243 )

Enable SID Filtering to enable domain controllers in the trusting domain to remove all SIDs that are not relative to the trusted domain from any authorization data that is received from that domain

Security - User with AD credentials may able to access other agency resources

Enable Selective Authentication to explicitly grant access to access agency resources. For more information on Selective Authentication

Operations – Different operations policy which may introduce different level of operations assurance

Due diligence both forests to ensure the good practice of AD operations.

To ensure security process and control like update management, anti-virus etc. are executed according to security policy.

 

As per the diagram 1 above we have resources in Fab.com and users and computers are part of contoso.com, so to access resources across the forest we would need resource forest trusting account forest, we will see how we can achieve single sign on using One Way Forest Trust

  • One-way forest trust support cross forest Kerberos and NTLM authentication while external trust only support NTLM (Kerberos authentication is the preferred method in SOEasy, NTLM is provided for backward compatibility)
  • A one-way, forest trust between two forests allows members of the trusted forest to use resources that are located in the trusting forest. However, the trust operates in only one direction.

In this scenario users and computers which are logically part of contoso.com domain but situated physically in same subnet as fab.com forest would use contoso.com credentials to access the resources in fab.com, we will see what are the requirements for users to authenticate against contoso.com and access resources in fab.com forest.

 

Diagram 3

Prerequisites to establish One Way Forest Trust

  1. 1.       Name Resolution mechanism for both active directory forest, to establish active directory trust relation between contoso.com and fab.com a DNS name resolution needs to be configured properly
  2. 2.       Required TCP/IP ports needs to be opened on all the firewalls falling underway
  3. 3.       Enterprise or Domain admin credentials from both forests
  4. 4.       PDC emulator role domain controller should be up and running and reachable across the forest
  5. 5.       Trusting Domain and Trusted Domain should have following in common
    1. a.       SID (Security Identifier)
    2. b.      Domain Naming System (DNS) name
    3. c.       NetBios Name
  6. 6.       All domain controllers are in correct time zone (For Kerberos Authentication time difference more than 5 minutes will cause authentication to fail)

Trust Limitations

  1. Number of TDOs - Testing indicates that the time to complete operations related to TDOs, such as authentication across domains, deteriorates noticeably if the Active Directory implementation in an organization contains more than 2400 TDOs
  2. Trust Path Limits - Kerberos clients can traverse a maximum of 10 trust links to locate a requested resource in another domain
  3. Trust Search Limit - When a client searches out a trust path, the search is limited to trusts that are established directly with a domain and those that are transitive within a forest.
  4. Trust Flow - The flow of communication over trusts is determined by the direction of the trust (one-way or two-way) and the transitivity of the trust (transitive or non-transitive)

 Resolution between Contoso.com and fab.com

As we discussed above to establish a trust we do need a healthy name resolution mechanism between the forests, let’s see what options do we have using Active Directory DNS, third party DNS is out of the scope of this document

Best practices for designing the DNS namespace and providing DNS support for deployment of a single Active Directory forest are provided in the “Best Practice Active Directory Design for Managing Windows Networks.” You can view this document on the Microsoft TechNet Web site at https://go.microsoft.com/fwlink/?LinkId=10478 . In the process of designing your multiforest Active Directory deployment, follow these recommendations for each individual forest. After you have completed the DNS design for each individual Active Directory forest, you must analyze the requirements to enable name resolution across the forest boundaries.

The ability to resolve the names from the namespace of a different forest is required by the following activities:

User or computer needs to locate a resource (for example, an Exchange server, file share, or service) that is hosted on a computer that is joined to a different forest.

User or computer needs to locate a domain controller in a different forest for the purpose of authenticating to a resource in that forest.

There are multiple ways of configure DNS name resolution across the forest, for example

  1. 1.       Conditional Forwarding
  2. 2.       Creating a secondary zone
  3. 3.       DNS zone delegation

Conditional Forwarding

DNS servers are configured to forward the queries with a specific name suffix to a DNS server in different forest, contoso.com DNS server is configure to forward the queries with fab.com name suffix to fab.com DNS server and fab.com DNS server is configured to forward queries specific to contoso.com name suffix to contoso.com DNS server

 

Diagram 4

Creating a secondary DNS zone

DNS servers hosting high-level zones in the namespace hierarchy can be configured to host secondary zones that contain the highest-level zone data for other forest as

 

Diagram 5

TCP/IP ports required for establishing trust

Please refer to article below for complete list of ports required to be opened on firewall to establish trust across the forest

https://support.microsoft.com/kb/179442

https://technet.microsoft.com/en-us/library/dd772723(WS.10).aspx

As we have users and client machines sitting across the network firewalls to reach their domain controllers for authentication, we also need to configure firewall and network connectivity to allow clients to logon into the domain, how interactive logon process works and what are the ports required to be open across the firewalls refer to article

 https://technet.microsoft.com/en-us/library/cc780332(WS.10).aspx#w2k3tr_intlg_how_unsl 

Since our end result is to give users seamless experience while accessing the applications across the forest with single sign on process, it is not uncommon in today’s world that you have applications in the environment which would require object picker functionality, so we also need to consider opening firewall ports for object picker functionality, below is the list of ports required

TCP/UDP 135, 137, 138, 139 (RPC)
TCP/UDP 389 by default, customizable (LDAP)
TCP 636 by default, customizable (LDAP SSL)
TCP 3268 (LDAP GC)
TCP 3269 (LDAP GC SSL)
TCP/UDP 53 (DNS)
TCP/UDP 88 (Kerberos)
TCP/UDP 445 (Directory Services)
TCP/UDP 749 (Kerberos-Adm) [Opt.]
TCP port 750 (Kerberos-IV) [Opt.]

Authentication Protocols

Active Directory domain controllers authenticate users and applications by using one of two protocols: either the Kerberos version 5 authentication protocol or the NTLM authentication protocol. When two Active Directory domains or forests are connected by a trust, authentication requests made using these protocols can be routed to provide access to resources in both forests.

Kerberos Version 5 Protocol

The Kerberos version 5 protocol is the default authentication protocol used by computers running Windows 2000, Windows XP Professional, or Windows Server 2003. This protocol is specified in RFC 1510 and is fully integrated with Active Directory, server message block (SMB), HTTP, and remote procedure call (RPC), as well as the client and server applications that use these protocols. In Active Directory domains, the Kerberos protocol is used to authenticate logons when any of the following conditions is true:

NTLM

The NTLM protocol is the default protocol used for network authentication in the Windows NT 4.0 operating system. For compatibility reasons, it is used by Active Directory domains to process network authentication requests that come from earlier Windows-based clients and servers. Computers running Windows 2000, Windows XP or Windows Server 2003 use NTLM only when authenticating to servers running Windows NT 4.0 and when accessing resources in Windows NT 4.0 domains.

When the NTLM protocol is used between a client and a server, the server must contact a domain authentication service on a domain controller to verify the client credentials. The server authenticates the client by forwarding the client credentials to a domain controller in the client account domain. The authentication protocol of choice for Active Directory authentication requests, when there is a choice, is Kerberos version 5. When the Kerberos protocol is used, the server does not have to contact the domain controller. Instead, the client gets a ticket for a server by requesting one from a domain controller in the server account domain; the server validates the ticket without consulting any other authority.

Trust Password

Both domains in a trust relationship share a password, which is stored in the TDO object in Active Directory as part of the trust creation. As part of the account maintenance process, every thirty days, the trusting domain controller changes the password stored in the TDO automatically, without the correct trust password, trust connection cannot be established. Trust password must meet the requirements enforced by domain policy.

Kerberos

To allow application access across the forest, users accessing the applications should be authenticated first with the authentication provider using Kerberos authentication mechanism, below diagram explains the process of Kerberos authentication while accessing the applications

  1. 1.       User logged into the computer and tries to access the application in fab.com, application server doesn’t recognize the user, user needs to get some token to present to application to prove the identity
  2. 2.       User contacts its domain controller KDC (Key Distribution Center)and requests a service ticket for application access
  3. 3.       Domain Controller checks its database for the SPN since the domain controller / global catalog has limited information about its own domain, the SPN is not found, then global catalog checks its database about forest trusts that are established with its forest and, if found, it compares the name suffixes listed in the forest trust trusted domain object (TDO) to the suffix of the target SPN to find a match. Once a match is found, the domain controller gives the referral ticket to Client for domain controller in fab.com
  4. 4.       Client computer connects to fab.com for service ticket for application access
  5. 5.       Domain controller in fab.com connects its global catalog server to find the SPN and the global catalog finds the match for SPN
  6. 6.       Client computer connects the domain controller KDC in fab.com to negotiate the ticket for user from contoso.com to access the application in fab.com
  7. 7.       Once client has a service ticket, it goes back to application server with the service ticket and gains the access to application

Kerberos Delegation (a.k.a. Kerberos Double-hop)

Typically, clients call a service to have the service perform some action on the client’s behalf. Impersonation allows the service to act as the client to perform an action. Delegation allows a front-end service to forward the client’s request to a back-end service in such a way that the back-end service can impersonate the client. Impersonation is most commonly used as a way of checking whether a client is authorized to perform a particular action, while delegation is a way of flowing impersonation capabilities, along with the client’s identity, to a back-end service.

Delegation is a Windows domain feature that can be used when Kerberos-based authentication is performed. Delegation is distinct from identity flow and, because delegation transfers the ability to impersonate the client without possession of the client’s password, it is a much higher privileged operation than identity flow.

Both impersonation and delegation require that the client have a Windows identity. If a client does not possess a Windows identity, then the only option available is to flow the client’s identity to the second service.

With the assumption that client has already has the TGT from contoso.com Domain. When trying to access resource at the fab.com AD, the steps are:

  1. 1.       Desktop connects to Web Application and provides both TGT and service ticket.

Web Application uses the clients TGT to request a service ticket from the fab.com domain controller so Web Application can connect to Database Server.

  1. 2.       Web Application connects to Database Server using the client’s credentials.

Ability to delegate is one of the Kerberos authentication protocol capabilities as defined in RFC 1510 (https://www.ietf.org/rfc/rfc1510.txt). With this capability, user accountability will be improved, since users credentials will be used to access the services end to end, at the other hand, this introduce the risk on misuse of user credential (even though setting application with this capability requires admin privileges at fab.com Network end).

Implement Kerberos Constrained delegation: The constrained delegation extension allows a service to obtain service tickets (under the delegated users identity) to a subset of other services after it has been presented with a service ticket that is obtained either through the TGS_REQ protocol, as defined in IETF RFC 1510, or in the protocol transition extension.

 

NTLM

In case of NTLM authentication, the authentication referral process is shown in below diagram

In this scenario user and computer object are in contoso.com domain and application servers are in fab.com domain and users are trying to access resources in fab.com

  1. 1.       The initial request for authentication goes directly from the client to the web server in the fab.com domain
  2. 2.       This legacy web server creates a challenge to which the client responds.
  3. 3.       The legacy web server then sends the user’s response to a fab.com domain controller in its computer account domain.
  4. 4.       This domain controller checks the user account against its security accounts database. If the account does not exist in the database, domain controller sends the credentials of the client to a domain controller in the user’s domain, in this case constoso.com for pass-through authentication.
  5. 5.       Again, constoso.com domain controller checks the user account against its security accounts database and verifies the user credentials, and returns the result to the sender. If the verification is successful, the message contains the user's authorization data. If the verification is unsuccessful, logon is denied.

Authentication Scope

For the forest trust, the following authentication scope can be selected:

  • Forest-wide authentication: An authentication setting that permits unrestricted access by any users in the specified forest to all available shared resources that are located in any of the domains in the local forest.
  • Selective authentication: An authentication setting that restricts access over an external trust or forest trust to only those users in a specified domain or specified forest who have been explicitly given authentication permissions to computer objects (resource computers) that reside in the local domain or the local forest

Based on the requirement we need to made a decision about the scope of the authentication, if the requirement is to give access to specific number of users across the forest it is recommended to use selective authentication which would restrict access to the group of users who have been explicitly given “Allow to authenticate” access on the server in resource forest.

Authorization can be controlled on the resource forest by creating Domain Local Groups and assigning required permissions.

Above article discusses the aspect of configuring cross forest authentication using Active directory forest trust, watch out for 2nd part of the series which discusses about the Single Sign on using Active directory Lightweight directory service

Comments

  • Anonymous
    July 07, 2011
    We have an application that list all the printers on different location from our company, we had a recent merger with a company that has a seperate active directory setup. Question, do we need to change the exsiting codes of our application so that it could work with another Active Directory setup, if we are using a two-way trust?

  • Anonymous
    September 19, 2012
    Very good article..Thanks..Can i have the links for the next part.

  • Anonymous
    November 12, 2012
    Hi Mubashir, When can we expect part 2? Regards, Greg

  • Anonymous
    March 14, 2013
    I would love to see part 2 and 3! Thanks for the good information

  • Anonymous
    May 26, 2013
    When can we have Part 2 and 3? Thanks

  • Anonymous
    June 16, 2013
    thanks. this is a intrested article

  • Anonymous
    August 29, 2013
    www.watchfomny.com/A-Tv-Iran.php ALEXSUNTHERALEXSUNTHERA@YAHOO.NO

  • Anonymous
    March 03, 2014
    Can we hire you to provide the information that would be in part 2? jp.antona@atkinsglobal.com

  • Anonymous
    May 31, 2014
    Pingback from Gest??o de Vulnerabilidades em Servidores Windows (Parte 2 de 2) | Atitude Reflexiva

  • Anonymous
    November 20, 2014
    Very good article, full of info which I could not find anywhere. THANKS Mubashir!

  • Anonymous
    January 07, 2015
    Can I get a link for Part2 & 3. Would it be possible to send to jaik45@gmail.com

  • Anonymous
    January 14, 2015
    Hi, Is there a link to part 2 as well? Many thanks

  • Anonymous
    September 02, 2015
    Have a look at Adaxes. It allows to use and manage even multi-forest environments from a single console and you don'e even need to setup trusts between the forests for that.http://www.adaxes.com/active-directory_management.htm

  • Anonymous
    January 21, 2016
    Hi,
    we have the problem that we have a res. forest and a user forest.
    The res forest has a one way forest wide transitive forest trust to the user forest.

    The following works fine when a user accesses an ASP.net app in IIS on 2012 R2:
    -Kerberos auth. within the res. forest using a user account in the res. forest
    -Kerberos auth. between res. and user forest whereas: user account is in user forest, user client PC is in user forest, IIS server is in res. forest

    What does not work is:
    -Kerberos auth. between res. and user forest whereas: user account is in user forest, user client PC is in res forest, IIS server is in res. forest

    Do you have any ideas what the problem could be? SPNs are correctly set and forest search order was defined,

    KR
    Chris

  • Anonymous
    January 21, 2016
    Hi,
    we have the problem that we have a res. forest and a user forest.
    The res forest has a one way forest wide transitive forest trust to the user forest.

    The following works fine when a user accesses an ASP.net app in IIS on 2012 R2:
    -Kerberos auth. within the res. forest using a user account in the res. forest
    -Kerberos auth. between res. and user forest whereas: user account is in user forest, user client PC is in user forest, IIS server is in res. forest

    What does not work is:
    -Kerberos auth. between res. and user forest whereas: user account is in user forest, user client PC is in res forest, IIS server is in res. forest

    Do you have any ideas what the problem could be? SPNs are correctly set and forest search order was defined,

    KR
    Chris