Why Active Directory trusts exist?
There are several reasons, some of them are backward-compatibility, support for Kerberos realms, etc., however the most common reason is to support the account-resource model.
What is the account-resource model?
It's a security model in which user and group accounts exist in a centralized (account) realm and resources (systems, apps, files, etc) exist on different (resource) realm(s).
Notice the direction of trust, vs. the direction of access. Believe it or not, this is the biggest cause for confusion.
Note: The account-resource model is just one reason why AD trusts exist. The key reason is the needs of Global companies that need flexible access models for mergers, acquisitions and most recently IaaS deployments.
Here's what I propose. Why not use a reference model to understand trusts much better?
Here it is:
Let's go into each layer in depth:
There are different communications requirements for things to work as expected, but we need to concentrate first in what kind of traffic we will be dealing with.
The considerations for communications are very important especially in DMZ scenarios; the key here is that most likely there's conversations between 3 different subject-matter-experts: the UNIX, Linux, Mac SME, the AD SME and the Network/Firewall SME.
Traffic between forests to establish the trust relationship in the first place (not in scope for this article, but read the Network Ports used by Trusts section of this link.
- Traffic between the Centrify AD client and its local domain controllers
- Traffic between the Centrify AD client and remote domain controllers (from the trusted domain) for referrals (see below in the AD layer)
- Traffic between systems with AD tools and Centrify tools for referrals and the object picker (see below in the AD layer)
The ports required for AD communication can be determined very quickly with DirectControl, (just run the “adinfo –T” command) but here's a summary:
- TCP 53 (DNS) - without name resolution there's no communication. Period. This means that A and SRV records must be resolvable by all systems on each side of the trust relationship.
- TCP 3268 (Global Catalog): In AD, a domain controller with the Global Catalog role contains a partial replica of all objects in AD. Global Catalog placement has performance implications.
- TCP and UDP 389 (LDAP): This should be self-explanatory.
- TCP 445 (modern Server Message Block): This is optional, but required for GPOs used for config management.
- TCP 88 (Kerberos KDC): Self-explanatory; this the port for Kerberos communications.
- TCP 464 (Kerberos password change): This is the port for password change operations
- TCP 123 (SNTP): This is optional, to sync time with the domain controller's Windows Time Service.
- Ephemeral ports(*): These are often overlooked, but these are the high-ports used for socket communications.
Bottom-line: Expect to allow communications from Centrified systems and management stations to at least two domain controllers from your trusted forest.
These can be read-only DCs (RODCs) and depending on forest complexity, these may have to be Global Catalog.
This is not an issue on flat networks, but definitely more complex high-security scenarios like DMZs.
In the illustration above, this is a post-trust establishment scenario with one RODC in the trusting side and a firewall only allowing traffic for the RODC to be updated by the trusted domain DCs.
Both referral traffic from Centrified systems and management stations are serviced by the RODC.
Note: This is just one way of going about this scenario, there are several ways to go about this with pros and cons.
Name Resolution Layer
Name resolution by way of DNS is often overlooked by many administrators, the key to understand here is that Active Directory clients use Kerberos for authentication and in a "Kerberized" world there's no functionality without being able to resolve names; DNS symmetry is key; fortunately most AD deployments use domain controllers as DNS servers, but in scenarios in which other DNS servers are used, DNS Zones holding AD SRV records have to be accessible.
In my demo environment, I used the “conditional forwarding” capabilities of Windows DNS.
Note that I can get away with this because my network is flat. If I was dealing with a DMZ scenario I would either host a replica and protect it with firewall rules or IPSec encryption for DNS traffic.
Also, make sure you understand the naming conventions for Active Directory objects, and that your AD administrators and network folks are in sync to maintain Subnets, Sites and Services.
Active Directory Layer
The AD layer deals with all the Active Directory-related capabilities needed for the trust to work as expected and these include trusts, referrals, object picking, authorization and group scoping.
Because this topic focuses on the external non-transitive one-way trust, it's important to know it may be selective; but to keep things simple, let's assume a domain-wide trust.
Going back to the basic principle with an example illustrated in the figure below.
Fabrikam (HQ) trusts Contoso (CORP) = users from CORP can access resources from HQ.
Trusts are set up with a dual authorization (just like launching a rocket). If you look at Active Directory Domains and Trusts for both sides you’ll see this:
The non-transitivity of the trust is what provides the assurance that if accounts from the trusting domain are compromised, they won’t be able to access resources from the trusted domain.
We have talked about authentication in most of this entry, but we haven't addressed authorization.
Going back to the basic principle of the example:
"If hq.fabrikam.com trusts corp.contoso.com, that means that users from the corp.contoso.com can access resources from hq.fabrikam.com"
HOWEVER, this does not mean that users from CORP have any privileges on HQ; this will only happen if it's explicitly granted.
The common practice in a centralized account-resource model is to add the Global Domain Administrators group from the trusted domain into the Built-in Local Administrators group from the trusting domain, this will allow for Centralized administration, and since there's really no accounts used by users in the resource domains (other than contingency or service accounts), the unique credential principle is maintained.
This has implications to the Centrify best practices and we'll discuss this on the Centrify layer.
A key concept in the access model is group scoping. In a nutshell it means that security groups (the groups used for authorization) have different scopes: Universal (all forest), Global and Domain Local.
Domain Local groups can contain principals (users/global groups) from the local domain and any trusted domains. Global groups can only contain principals from the same domain.
For the sake of simplicity I will ignore Universal groups.
The best practice is to Assign Rights (or entitlements) to Domain Local Groups and add users or Global Groups to the Domain Local group. From that point on, the add/moves/changes of rights and entitlements are managed via group memberships (illustrated in the example above).
A referral happens when a system from the trusting domain has to authenticate a user from the trusted domain. Let's look at at our oversimplified example:
- If the system centos66 in hq.fabrikam.com needs to authenticate user firstname.lastname@example.org, the authentication will happen locally against the fab-dc1.hq.fabrikam.com domain controller.
- If the system centos66 in hq.fabrikam.com needs to authenticate user email@example.com, provided that the user has a UNIX identity and a role that allows login, the authentication will be referred to dc1.corp.contoso.com to satisfy the request.
The same thing happens with Windows systems or tools like ADUC, Access Manager, PowerShell, etc.
For more information, please read the “Kerberos-Based Processing of Authentication Requests Over Forest Trusts” section of this link.
When using tools like Active Directory users and computers or Access Manager, in order to pick foreign principals you use the object picker.
Here’s an example:
This screen shot is from Access Manager running from the trusting forest (hq.fabrikam.com) and corp.contoso.com is the trusted external forest.
This means that in this case, the Access Manager console must have at least 2 layers (communication and name resolution) in order to get to this point;
Note: The fact that we can get there does not mean that we can browse the trusted forest, we must have a valid AD account from that forest. Remember, we are going against the direction of access.
Contrast with this:
This screen shot is from Access Manager running from the trusted domain notice that you can't even pick from the trusting domain because you'd be going against the direction of access.
This sounds like a broken record (and it is by design), but believe it or not, this is the main source of confusion for the IT leads we work with.
This layer covers the behavior of Centrified systems when an external one-way trust is established, management tools, and how the best practices change in the account-resource model.
TCP/IP Connectivity and Centrify CLI Tools
Like I explained before, the adinfo –T command will be very handy. Let's look at the output of this command from two perspectives:
This confirms that Centrified systems in Fabrikam will have no issues with queries or referral traffic.
Centrify Agents and Trusts
On startup, join, forced cache expiration or when the 8-hour domain discovery threshold is met, the centrify AD client will update the domain map.
The “adinfo --sysinfo domain” displays the current domain map:
The key fields here are the trust type and trust direction. Direction 3 means two-way (always with the local domain), Direction 2 means one-way.
Workstation Mode vs. Zone Mode
Workstation mode (AutoZone) won't work in a 1-way trust scenario. The reason has to do with the way AZ generates UNIX identities. The UID/GID parts of the UNIX identity are generated on the fly based on the user or group's Active Directory SID (unique identifier), however since the system is in a resource forest, based on the security model it can't even read the object's SID. The alternative is to use Centrify Zones.
Note: AutoZone will work over a transitive 2-way trust.
In Zone mode, only authorized users from the local and trusted forests that that have been UNIX-enabled will have access to the system. When you use Access Manager and use the object picker to select an object from the account domain, you must do so with a authenticated user from the trusted domain, at that point our software can see the user/group information and will create the proper identity information in the zone.
Note the red arrow next to Jerry's name. This indicates a foreign principal.
Now let's look at the output of "adquery user -P" (to show user principal names only) from our zoned system:
And the UNIX identity is defined as per the zone settings:
In Express (limited freeware) mode, one-way trusts are not supported because Express uses Auto zone mode.
Access Manager and the Delegation Model
Centrify best practices promote the separation of Governance activities vs. Operations activities. The key here is to understand the group scoping. Access Manager has the ability to generate the best practices that look like this:
Notice the scope “Security Group – Domain Local” - this means that if you’re in a pure account/resource model, you will have to add the Global Security groups from the trusted forest into the corresponding group.
E.g. if you want the Global group Centrify Administrators from the corp.contoso.com account domain to manage Access/Privileges, I would add them to the cfyA_Global_* Domain Local groups.
Zone Provisioning Agent
ZPA along with PowerShell, adedit and the SDK is a key tool to automate for Identity and Access provisioning. This is where understanding group scoping comes into play, because if you make the mistake of:
- Create a Domain Local group for Identity Provisioning
- Nest a Global Group from the trusted forest
What will happen is that ZPA won’t be able to see any add/moves or changes to the group and provisioning won't happen as expected.
Let's look at this using the CLI tools. From Fabrikam, trying to view the memberships of a well-known AD group:
This is consistent with the direction of access principle of AD trusts, and since group memberships are public to authenticated users from trusted forests, George has no issue seeing this information. Let's look at the same queries, but from a system in Fabrikam
Notice the inability to resolve the group in the second query. That's because we're going opposite the access arrow.
One-way trusts have been the subject of discussions over the years but unfortunately the mode of operation is still unfamiliar to many IT leads. We hope that by covering the topic this clarifies to all cross-functional leads looking to research, design, support or troubleshoot this scenario when using Centrify software.