Chapter #2 – A Matter of Trust
Beyond the perimeter’s edge
Versione italiana disponibile qui → [IT]
Spring 1993, the writer is still completing studies.
One April Sunday the F1 Grand Prix takes place at Donington, UK. For the legendary Ayrton Senna it is a difficult year: his McLaren is inferior to the competition, and he starts fifth on the grid, but there is one detail that plays in his favour: it is raining! And when it rains, his trust in the car becomes absolute.
Green light, he launches forward like fury and by the end of the first lap he is already in the lead, in total domination. No one else has his confidence on a wet track.
In the rest of the world, in those same months, something equally extraordinary was taking shape, radically changing the way people trusted computer systems.
With the spread of the World Wide Web and the distribution of the NCSA Mosaic browser, the Internet stops being an environment reserved for a handful of specialists and suddenly becomes accessible.
Anyone can connect, explore remote resources, interact with systems they do not know and do not control.
Until that moment, security models had been built around clear boundaries: corporate networks, local systems, well‑defined domains.
With the Web, instead, people begin relying on distant services, remote identities, infrastructures that live outside their direct control.
It is a cultural revolution even before a technological one.
In Enterprise systems the subject of trust is played out across two opposing fronts.
On one side, the Windows universe was spreading based on a closed, perimeter-based trust model that coincided with the first domains.
This is where the first explicit concept of trust was introduced, built on a proprietary protocol: NTLM.
A mechanism designed for controlled environments, where trust is a static, declared configuration.
On the other side, the Unix and academic world had long used distributed authentication models, reaching significant maturity with Kerberos V5.
Here, trust is not merely a connection between systems, but an element designed for open, interconnected, and potentially heterogeneous environments.
Two profoundly different visions of trust, created to respond to different needs.
With the introduction of Active Directory, however, Microsoft made a fundamental choice: it embraced the values of the other model and adopted Kerberos as the foundational basis of the new authentication system, initiating a path of convergence between these two worlds.
Initially the models coexisted, side by side more than integrated, as a necessary compromise to guarantee backward compatibility.
Only with Windows Server 2003 did a more mature form of convergence arrive, marking the transition towards a Kerberos‑first approach, in which trust became part of the architecture rather than merely a connection between separate perimeters.
And yet, despite this convergence having happened more than twenty years ago, it has not always been fully understood.
As if, paradoxically, trust itself had been lacking in the process that intended to unite schools of thought that were originally far apart.
This chapter starts from here.
From a kind of trust that has evolved technically, but not always conceptually, and from the consequences of not having truly understood that change all the way through.
What it is and how it works
We have understood that the concept of “Trust” has deep roots; let us now try to frame it into practical terms within the context of Active Directory.
Basic mechanics of a Trust
Let us start from a principle that is very often taken for granted: the Authentication Domain.
A Domain is a perimeter within which an implicit “trust” exists among the objects that belong to it, mediated by appropriate permissions that define who can access what and in which mode (we discussed ACLs in Chapter 1).
Between different perimeters (Domains) there is no implicit trust, and consequently access is not allowed.
The element that distinguishes all objects belonging to the same Domain is the Security Identifier (SID).
This is a fundamental attribute of the Windows security model: an immutable string that uniquely identifies an entity (user, group, computer…) regardless of the name assigned to it.
A SID has a precise structure and can be represented in readable form as follows:
S‑1‑5‑21‑<DomainIdentifier>‑<RelativeIdentifier>
The first part of the SID identifies the authority that issued it and the security context in which the object was created.
In particular, the sequence S‑1‑5‑21 indicates that the SID belongs to a Windows domain context, while the value <DomainIdentifier> represents the identity of the domain itself.
This means that all objects belonging to the same domain share exactly the same initial portion of the SID.
The final part, called the Relative Identifier (RID), is what makes the object unique within that domain.
The RID is assigned by the Domain Controller at the time the object is created and distinguishes a user, group or computer from all others that share the same Domain SID.
In other words, the SID always tells two different truths:
· where the object comes from (the domain that issued it)
· who the object is within that domain
This separation is one of the cornerstones of the Active Directory security model; if you want to explore the topic further, here is the link to the official article.
Thanks to this mechanism, ever since the very first NT Domains, the Domain Trust mechanism has been available, initially based on the NTLM protocol.
It is important to remember that, even conceptually, trust has a precise direction, the same is true for Domain Trusts, where those who provide the resources (for example, a File Server in a resource Domain) extend trust to those who provide the identities (the user Domain).
This direction is represented with an arrow going from resources to identities.
When a Trust is activated, the resource domain does not import users nor replicate objects from the trusted domain.
Instead, it accepts something much simpler and far more powerful: the Security Identifiers issued on the other side.
When an external object is used for the first time (for example, by adding it to a local group or assigning it a permission) Active Directory automatically creates a Foreign Security Principal.
A Foreign Security Principal is not a real local account, but a pointer: a minimal object containing only the SID of the remote entity.
It allows the resource domain to include external identities in its authorisation mechanisms without needing to know their structure or replicate their attributes.
Once again, everything revolves around trust: the resource domain does not know who that object is, but trusts that its SID was issued by an authority considered reliable.
The evolution of trusts: from point-to-point connections to architectural trust
In the first Windows domain model, trust was a simple and very concrete concept: two domains know each other, speak to each other, trust each other.
Nothing more. Every trust is an explicit, manually created connection that applies only between two well defined endpoints.
If you need something else, you create another trust, and then another.
It is a model coherent with its era: small environments, clear perimeters, few interactions.
But it is also a model that does not scale.
Every new relationship increases complexity and, more importantly, makes trust fragile: forgetting a single link is enough for something to stop working.
With the arrival of Active Directory and the birth of the forest concept, Microsoft changed approach.
Domains were no longer independent islands, but parts of a broader structure designed to share a common trust space.
To support a hierarchical domain model, intra‑forest trusts were introduced: automatic, bidirectional, transitive.
Trust was no longer an exception but a structural property.
It was a fundamental shift: for the first time, trust stopped being a set of exceptions and became a foundational rule.
However, when it becomes necessary to leave this perimeter (to collaborate with external domains, legacy environments or completely separate forests) one temporarily returns to the past.
As a legacy of Domain Trusts, External Trusts were introduced: explicit, non‑transitive links, deliberately limited.
A necessary compromise, designed to contain risk and reduce exposure.
The problem is that, in the meantime, the world moved on.
With Windows Server 2003, the attempt at a definitive synthesis arrived: the Forest Trust.
No longer trust between individual domains, but between entire sets of domains.
No longer an exception, but a coherent extension of the Kerberos‑first model introduced with Active Directory.
Trust finally became part of extended architectures as well: transitive, structured, designed for complex scenarios such as migrations, consolidations and coexistence.
From that moment onwards, trusts were no longer just a way to “make things work”, but a design tool that must be considered carefully.
So far we have mentioned many different types of trusts; confusion is easy, so let’s put things in order:
In architectural design, the real decision concerns external-type trusts (not intra-forest), where we must decide “how much” trust to grant and, above all, in what way.
And this is where the gap we still see today is born, because while the trust model has evolved, the way people think about it has often remained still.
Applying the wrong trust model to the wrong context is very often not a configuration error.
It is a conceptual legacy.
What can go wrong
As with the first chapter, I felt it would be both interesting and effective to place the theoretical aspects into a practical context, always starting from what I have been able to observe in the field.
Real case #1 – The trust you do not expect
Let us return to Real Case #1 of Chapter #1. The migration project is complex and the work of the “tightrope walker” goes on. If you thought you had already seen and solved every problem, you were mistaken: this is a situation that still has a few surprises in store.
Permissions on the user accounts have been fixed, and the migration tests begin. To fully understand everything that this scenario includes, I believe it is worth laying it out in a summary diagram:
Even just by counting the number of arrows needed to draw the diagram, you immediately understand the meaning of the word “complex”. There are several elements in play, so let us focus on the most significant ones:
There is a Trust between the source and target Active Directory environments
The Entra Connect synchronisation engine is in the target and has a connector to the source
The users to be migrated use a specific suffix in their UserPrincipalName (UPN), that logon attribute that resembles an email address
The login method for that UPN suffix in the Entra ID tenant is federated and points to an ADFS Farm in the source
This is a scenario where a “collaboration between the parties” is already active, and the Trust is its main pillar. Identity migration is only one part of the overall design.
Staying on the topic of identities, however, I would like to highlight a couple of details:
The NetBIOS names and FQDNs of the two Active Directory environments are different, which is a requirement for enabling a trust
The users’ UPN suffix, which is effectively an additional FQDN, can be registered only in one of the two Active Directory environments at a time, otherwise an “UPN suffix collision” is generated. This forces a cut over migration approach, where the user accounts and the related FQDN are moved in one block.
Back to our tests: a separate FQDN is identified with which to carry out the whole process, the procedure continues, cut over time arrives, the users become active in the target and the logon test begins.
Microsoft 365 logon page, the UserPrincipalName of a test user is entered, the federation system redirects us to the source ADFS Farm, the password is entered and… the attempt fails: Incorrect username or password.
Hmm… a very generic error, and so the usual sequence of checks begins:
Is the user active in the target? > Yes
Password reset in the target > still KO
Attempt to log on to ADFS using SamaccountName (DOMAIN\username) > same error
Does DNS resolution work? > Yes
Are the requirements for multi-forest ADFS scenarios met? > OK
Is the Trust configured correctly? > …
This is the moment when the detail that changes everything emerges.
By analysing the Trust configuration between the two Active Directory environments, it becomes clear that an External Trust had been enabled, or rather inherited, instead of a more sophisticated Forest Trust.
Another important detail, already mentioned above, is that the users being migrated use additional UPN suffixes, for example: <username>@UPNsuffix.xyz
These are defined at forest level and are part of the metadata shared through the Configuration partition.
The Name / UPN Suffix Routing mechanism uses this information and is available only in the Forest Trust context.
“Name suffix routing is a mechanism used to manage how authentication requests are routed across Windows Server 2003 forests that are joined together by forest trusts.”
External Trusts, operating exclusively at domain level, do not have visibility over forest metadata and therefore cannot route additional UPN suffixes.
For this reason, an attempt to log on using the additional UPN suffix, carried out through the ADFS Farm in the source environment, cannot correctly route the request towards the Domain Controllers in the target Active Directory environment.
So, we are dealing with an inherited configuration, certainly functional for its original purpose, but incompatible with the current scenario.
At this point, the question becomes inevitable: how do we solve it?
The most obvious technical solution would be to replace the External Trust with a Forest Trust. Logical, right?
The problem is that, in real projects, obvious solutions are not always practical, and they clash with corporate policies.
In this case, the customer was very clear: no architectural change could be approved without a formal impact assessment, carried out in a controlled environment that reproduced production faithfully. And there was an additional, non-negotiable constraint: the user experience must not change.
Understandable requirements indeed, correct and protective ones, but in practice they meant only one thing: the simplest path was blocked.
This is one of those moments when the tightrope walker’s work truly makes itself felt. You have the diagnosis, you know the cure, but you cannot administer it. You must find an alternative path that respects the constraints, does not compromise the user experience and does not blow up the project timeline.
The solution identified was to work around the limit without ignoring it: introduce a new ADFS Farm in the target environment, validate the architecture and the user experience with a dedicated UPN suffix, and collect the evidence needed to bring a formal proposal for architectural change to the table at a later stage.
Not the ideal answer. But the possible answer in that specific context.
This is the resulting diagram:
Once again, we are facing an extra effort that can hardly be anticipated during the normal assessment phase.
The Trust was active and was doing exactly what it had been designed to do, but it was not sufficient to support the migration scenario.
Assuming that the Trust was put in place after 2003, it becomes natural to reflect on the foresight of the decision that led to the use of an External Trust and on the constraints it carries forward over time.
Lessons learned from the Trust
Trust, in computer systems, is one of those concepts that we take for granted until it stops working.
It is an invisible, silent companion that accustoms us to its presence without ever making itself heard. And yet, when it is designed or inherited without full awareness, it can determine the success or failure of entire architectures.
The case seen in this chapter clearly shows a point that is often overlooked: a trust is not just a technical connection, it is a design choice.
A choice that is born in a specific context, to solve a specific problem, and that can remain perfectly valid for years… until the context changes.
When hybrid identities, federations, additional UPN suffixes and cloud continuity requirements come into play, that same trust can become an invisible constraint.
Not because it is “wrong”, but because it was designed for a different world, with simpler boundaries and less articulated authentication paths.
The most important lesson is that trust does not automatically scale with complexity.
Adding new components, such as Entra ID, ADFS and multi forest synchronisations, without rethinking the trust model often means building on foundations that were not designed to bear that weight.
There is then a second lesson, even more subtle: trust related problems rarely manifest themselves explicitly.
They do not produce clear errors, they do not point to a precise cause. They present themselves as ambiguous behaviours, authentications that fail “for no reason”, configurations that appear correct but do not work. And it is precisely this ambiguity that makes them costly to diagnose and resolve.
As in the case of the guardian seen in Chapter 1, the problem is not the trusts themselves.
They continue to do exactly what they were designed to do: define perimeters, establish boundaries, and determine who can trust whom.
The problem arises when modern design ignores those boundaries, assuming that trust is implicit, transitive or adaptable by default.
In hybrid environments, trust is not an operational detail but a first level architectural decision.
Treating it as an inheritance to be endured, rather than as an element to be understood and redesigned, means pushing problems further into the future, where they will inevitably become more complex and more expensive, especially when “political” constraints are added to the equation.
And it is precisely from here that Legacy Things continues its path: bringing back to light those silent mechanisms which, although born decades ago, still determine the behaviour of modern infrastructures.
Because ignoring the past does not make it harmless. It only makes it harder to recognise when it makes itself felt again.