Tag Archives: trusts

Active Directory Federation Services (AD FS) – Part 1

AD FS is a service which allows to securely exchange identity information between trusted business partners. Let’s assume Company A and Company B is business partners. Company B management wants to access Share point portal runs on Company A in secure manner. With use of ADFS Company B can provides the authentication information in form of “Claims” to Company A. then Company A will use “trust policy” to map these claims in to claims which share point web application will understand. Then based on that outcome system will make the authorization decisions.

This ADFS services also used to provide single sign on (SSO) experience between on premises active directory and windows azure active directory instance.

Benefits

1.    Single Sign On (SSO)

ADFS service will give SSO experience to federation partners to access its partner’s web based applications.

2.    Easy Partner’s User Account Management 

Between federation partners, the user identities, attributes, group memberships etc. managed by the partner’s organization. So you do not need to worry about changing, activate/deactivate user accounts used for the authentication.  Also in event of partnership termination, it can be done with single trust policy change and do not need to worry about user accounts.

3.    Web services Interoperability

AD FS federated identity management solution is interoperates with other security products that supports WS-* web services architecture. It allows to make federation partnerships with environments which do not use windows identity model. 

4.    Centralized federation partner management

All the federation partnerships can manage using AD FS MMC.

5.    Extensible architecture

Organizations can use the extensibility to modify AD FS to support its business policies.

AD FS Deployment

In order to install AD FS need at least 2 servers. One server is to hold AD FS and other server will holds Web Application Proxy service. This 2 roles can’t install in one server.

To install AD FS, servers must be joined to the domain.

Client – Web Application Proxy – Federation communications are based on HTTPS. So if your organization do not runs with CA, make sure you apply 3rd party SSL along with proper DNS entries before AD FS configurations.

Also port 443 should open in order to proceed with following communications,

1)    Client computer should be able to connect AD FS or Web Application Proxy Server using HTTPS (443)
2)    AD FS and Web Application Proxy servers should be able to communicate using HTTPS (443)

Web Application Proxy

Prior to Windows server 2012 R2, this service was called as Federation server proxy. This service should be hosted in a server in perimeter network. This will be act as a gateway connecting a host in unprotected network to federation server in protected network.

This is the end of post and in next article let’s look in to AD FS deployment in demo environment. If you have any question about the post feel free to contact me on rebeladm@live.com

Configuring Trusts – Part 4

This is the last part of the series which explain about “Trusts” between infrastructures. If you not checked the other 3 parts yet you can find them in here.

Configuring Trusts – Part 1
Configuring Trusts – Part 2
Configuring Trusts – Part 3

This article will explain how to configure trusts between infrastructures.

Demo Setup

For the demonstration I will be using following setup.

Organization

Domain

Primary DC

Contoso Ltd.

Contoso.com

Microsoft Windows Server 2012 R2

XYZ Ltd.

Xyz.com

Microsoft Windows Server 2012 R2

I am going to initiate a “Forest Trust” between the 2 organizations. It will be Two-Way trust which allows each forest, domains and users to access “allowed” resources in each organization infrastructure.

Before start the process the initial step is to make sure following ports are open in firewalls in both organizations to initiate the trusts.

UDP Port 88 – Kerberos Protocol
TCP and UDP Port 387 – LDAP
TCP Port 445 – Microsoft SMB
TCP Port 135 – Trust endpoint resolution

In order to initiate a trust you need to login as user account which is member of Domain Admins or Enterprise Admins groups.

Also you need to consider about the DNS ( domain name services )before proceed with the trust initiation process. If both organizations using root DNS server coming for both forests it will not be an issue. But if not you need to create DNS Zones in each forest dns servers. In here for the demo I have setup secondary dns zone with transferring copy of running DNS zone on XYZ.com. I have explain DNS zone setup in one of my previous articles in blog. If you not familiar with the process please refer to it here

dns1

1)    To start the process I will log in to contoso.com domain as enterprise administrator.

2)    Then Server Manager > Active Directory Domains and Trusts

t1

3)    In active directory domains and trust snap-in right click on contoso.com domain and click properties

t2

4)    In next window go to “Trusts” tab and click on “New Trust” button

t3

5)    It will open the “New Trust Wizard” click next to start the process

t4

6)    In next window we need to specify the DNS name or the netbios name of the domain we going to initiate trust with. In our demo it will be “xyz.com”. then click next to continue

t5

7)    In next window we need to select the trust type. I have selected “Forest Trust” and click next to continue

t6

8)    We are going to setup “Two-Way” trust so in next window I selected “Two-way” from the list and click continue

t7

9)    Trusts are need to initiate in both sides. But if you have appropriate access permissions to the remote forest, you can initiate it. In next window it give option to initiate the trust in remote forest. Since I do have access I select “Both this domain and specified domain” and click next

t8

10)    In next window I have specified the logins to initiate trust in remote forest (the account need to be member of Domain Admins or Enterprise Admins groups). Then click next to continue

t9

11)    In next windows it ask to select the authentication scope for local forest. In here I select forest-wide authentication

t10

12)     In next windows it ask to select the authentication scope for remote forest. In here I select forest-wide authentication

t11

13)    In  next window it gives brief description about the selections we made and click next to initiate the trust

t12

14)    In next window it asks about routed name suffixes for the local forest. I will use default and click next

t13

15)    In another window it asks to confirm the outgoing trust. Since we initiated the other side of trust, select yes and click next

t14

16)    Next window it asks to confirm incoming trust. Since we initiated the other side of trust, select yes and click next

t15

17)    Then it gives confirmation about the successfully create trust. Click finish to exit from wizard.

t16

18)    In remote XYZ.com we can confirm the initiate trust by looking in to domain properties like we did in steps 1-3

t17

This completes the process of creating forest-trust. The options selected on process will change based on trust type, authentication scope etc.

Testing

For the testing purpose of the trust I have created following scenario.

Contoso domain file server hosts a folder called “Share-Contoso”. We need to provide access to user account called “xyz-user” from XYZ forest to this particular folder.

After initiating the trust, when we going to apply share permission to the “Share-Contoso” folder now we can select users from the XYZ.com domain.

sh1

sh2

After applying permissions I am trying to log in to contoso file server from remote location ( here I used a pc which is not added to domain ) and once its ask to provide logins I have provided the login info for xyz-user for XYZ.com domain.

sh3

Once it’s authenticated we can see it’s provided the access to relevant share.

sh4

As we can see the trust is successfully initiated. If you have any questions feel free to contact me on rebeladm@live.com

Configuring Trusts – Part 3

This is the part 3 of the series which explain about “Trusts” between infrastructures. If you not checked the other 2 parts yet you can find them in here.

Configuring Trusts – Part 1
Configuring Trusts – Part 2

In this article I will cover up the rest of the concepts, terms, involves with setting up a trust.

Security Identifier (SID) filtering

Microsoft Systems uses a structure known as SID to express its identities. Its act as a token. SID filtering is used to block users in trusted forest or domain being able to elevate their privileges in local forest or domain. This is important for external trusts as when you trusting you can control rights to provide credentials between domains.

By default windows 2012, windows 2012 R2 have SID filtering enabled. If you wish to disable this, you can do it using following commands. (https://technet.microsoft.com/en-us/library/cc794801(v=ws.10).aspx)

To disable SID filter quarantining for the trusting domain


Netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /quarantine:No /userD:<DomainAdministratorAcct> /passwordD:<DomainAdminPwd>


To disable SID filter quarantining for the trusting forest


Netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /enablesidhistory:Yes /userD:<DomainAdministratorAcct> /passwordD:<DomainAdminPwd>


It is recommended to keep the default enabled state unless you have critical reason.

Name Suffix Routing

In an organization it may have different UPN (User Principle Name) suffixes used with in its forest. For example Contoso LTD. May use contoso.com, mycontoso.net, companyA.org as name suffixes. But when you creating a trust you may not need to allow users from all these suffixes. With Name suffix routing we can enable or disable the UPN suffixes which will involve with the trust operations.

I will demonstrate how we can do this in next post which will go more in to real world configurations.

Trust Authentications

Trusts can use 2 authentication protocols. By default it uses Kerberos Version 5. If it’s not supporting it use NTLM Authentication.  In order to initiate a trust, the administrator need to be a member of domain admin group or enterprise admin user group. Trust needs to initiate in both sides.

Trust Components (https://technet.microsoft.com/en-us/library/cc773178(v=ws.10).aspx)

IC195612

Before initiate trusts it is important to make sure following ports are open in both sides.

UDP Port 88 – Kerberos Protocol
TCP and UDP Port 387 – LDAP
TCP Port 445 – Microsoft SMB
TCP Port 135 – Trust endpoint resolution

This is the end of a part 3 of the configuring trust series and in next article let’s look in to real world setups. If you have any questions regarding the post feel free to contact me on rebeladm@live.com
 

Configuring Trusts – Part 2

This is the part 2 of the series of articles which describes about trusts between infrastructures. If you still not read the part 1 of the series you can find it in here.

On previous article I explain what is a trust and common terms used in process. This article will be extend to it.

External Trusts – Let’s assume we have child domain called “HQ.contoso.com” under contoso.com forest. Company recently had business relationship with XYZ corp. They having child domain under the XYZ.com forest called “Sales.xyz.com”. As per business need management wants to allow users, resources in “Sales.xyz.com” to access data, resources in “HQ.contoso.com”. None of the other domains, child domains in both forest should allow in this operation. This is where we can use “External Trusts”. So it will only allow part of the forest to participate in unique operation.

Realm Trust – Also in real world Microsoft AD services is not the only directory services organizations uses. So it is not practical forcing another organization to change their directory services to match with ours to make trust. Realm trusts are helps to mitigate this issue and it allows to make trusts with active directory domain and non-Windows Kerberos version 5 realm (such as Linux directory service)

Forest Trusts – This is the most commonly used trust type. Using forest trust, one active directory forest will trust another active directory forest. These trust can be uni-directional trust or bi-direction trusts. By default forest trusts are “Trasitive”. It means any domain or child domain under these forests will be automatically trusted by each other (based on trust direction).  

In forest trust we can use two authentication scopes according to our business requirement.

Forest-wide Authentication – This is the default authentication setting for forest trusts. Users in remote forest will be automatically allow to authenticate local forest resources. In here it doesn’t means any user in remote forest can access any resources. They still need pass the ACL, permission rules resources used. This authentication model is recommended for the organizations with multiple forests.

Selective Authentication – Using this method we can allow selected users, groups in remote forest to access resources in local forest.  This is the best option to control access security while maintaining a forest trust.

Shortcut Trusts – Let’s assume we have two forests called contoso.com and XYZ.com. As per below image both forests do have several domains and child domains. We do have a user called ‘User A” in “IT.Hotels.contoso.com”. He needs to access a file share from a server located under “HR.Constructions.XYZ.com”.

short1

Now if we think about the authentication process it will need to pass the traffic all the way up to root domain in both forests. Sometime these child domains may located on different countries or cities. These may also connect through slow links due to high cost. So this traffic does effect regular operations.

Shortcut trusts allows to pass authentication traffic between IT.Hotels.contoso.com and HR.Constructions.XYZ.com directly without going through domain tree. Shortcut trust can be bi-directional or uni-directional.

short2

This is the end of Part 2 of the series and if you have any questions feel free to contact me on rebeladm@live.com

Configuring Trusts – Part 1

Trusts, simply we can define as a bond between multiple domains, multiple forests. It controls how or what been allowed between domains and forests.

Let’s assume we have a company called Contoso Inc. and its running with domain contoso.com. Company recently merge with another company called XYZ Inc. and its running with domain xyz.com. Management wants to allow their resources to been used by both company users. For ex- A user in contoso.com will required to access a share in xyz.com file server. Company wants to do it with minimum impact or changes. This is where “trusts” comes in to the picture. Using trusts we can control who will be trusted, how it will be and what sort of access users have on resources.

Before we move in to the configurations it is important to understand the concepts of trusts.

Trusting Domain – This will be the domain contains the resources which will need to allow access. As ex- in my domain contoso.com have a file share called “Sales”. I needs to allow sales users from XYZ.com to access it. In here contoso.com act as trusting domain.

Trusted Domain – This will holds the resources which you wish to grant access. As ex- if we take same above example, XYZ.com domain holds the user accounts which will be allow to access resources on contoso.com. So XYZ.com act as trusted domain.

Transitivity – Trust transitivity allows to extend the trust in to child domain level. For example with trust I may need to allow users in child domains of xyz.com also to have access in to contoso.com domain resources.   I can do it with trust transitivity.

We can categorize trusts based on the direction it’s applying to.

Two-Way Trust – This also known as bidirectional trust. This is the trust mostly been used among organizations. In here both sides on the trust work as trusting and trusted domains.

One-way Incoming Trust – In here trust is created in trusted domain and trusted domain can access resources in trusting domain only.

One-way Outgoing Trust – In here resources in remote, specified domain can authenticated in initiating domain.

if any questions about the post feel free to contact me on rebeladm@live.com