Chapter #5 - Illusion
Reality does not change, only the point of observation does
Versione italiana disponibile qui → [IT]
April 1983. A year earlier, Imagination had been playing “Just an Illusion”, and without knowing it they were giving the perfect title to what would become a milestone in entertainment.
I do not remember what I was doing. I was six years old and certainly did not yet have a keyboard in my hands. But that feeling I remember well, because when the brain realizes it has been fooled, it makes a note of it for later.
We are in New York City, on Liberty Island. The show is ready, the lights are on, and thousands of people are about to witness something impossible. The world-famous David Copperfield has a very ambitious act in store: making the Statue of Liberty disappear live.
The show begins, tension builds, a large curtain drops and the “magic” happens. A few minutes pass, the curtain slides to the ground and… the statue is gone!
The illusion has taken place. Or at least it has for the audience. Those who know what happens behind the scenes know that the statue has not moved, it is the audience that has been moved.
Reality does not change, what changes is the point from which you observe it.
Turning the spotlight on the IT world, 1983 was a year full of ferment. On January 1st Arpanet, which would later become the Internet, adopts the TCP/IP protocol. At Microsoft, MS-DOS 2.0 is released and, at the end of the year, Windows is announced, long before the world would actually see it.
So many small seeds that would put down deep roots in modern IT. And that, in that moment, gave the illusion of already holding the future in one’s hands.
Forty years later, illusions are still with us, only more sophisticated. Today’s case does not show up as a clear error, but as a “strange” behaviour that seems to turn logic upside down… until we decide to change perspective.
The “strange” case
2026. A customer, a member server, an apparently ordinary need.
On that machine a software module needs to be installed which, in order to do its job, requires two things:
· being a local administrator
· being able to perform some operations on Active Directory through the Remote Server Administration Tools (RSAT)
It is a request that anyone working in IT has seen dozens of times. Nothing that requires particular attention, apart from defining the precise delegation on Active Directory.
We proceed following the Principle of Least Privilege (POLP):
· a gMSA is created
· it is configured to run the service
· for the “local” operations it is added to the Administrators of the member server
Not a Domain Admin, not a personal account, no rushed solutions. It is the classic service identity, for which we are building the delegations needed to make it work.
Then we get to the most delicate operational part: the minimum permissions on Active Directory.
The RSAT are installed on the server, the Active Directory Users and Computers (ADUC) console is opened directly from there, and the consultant starts configuring the necessary delegations.
So far everything is straightforward: the gMSA is a normal domain user, it is a local admin only on that server, and the goal is to assign it a few targeted permissions on specific OUs.
In a POLP context, however, every delegation must be certified in the field.
So we move on to checking which effective permissions that account receives on the Active Directory tree, and it is at that point that something happens that should not happen: the gMSA seems to have rights well beyond the delegation just set.
We open an Organizational Unit > Properties > Security > Advanced > Effective Access.
We look at the permissions received by the gMSA, and it is all really strange: the interface says the account has “almost-full” permissions over the entire tree!
We re-check the account: it is a member only of the Domain Users.
The consultant has an intuition: what if we try removing the account from the local administrators of the member server?
No sooner said than done, we run a new check, and that is where things get even stranger: now the permissions on the Active Directory tree are correct.
That is when the matter lands on my desk. The consultant is rather confused: how can a local membership influence domain permissions? It is the world turned upside down!
I think over the information I have received, and in my mind an idea begins to take shape, one whose roots reach back to that distant 1983:
the behaviour is not real, we are facing an illusion!
The illusion revealed
Common logic says that a local membership cannot have effects on a directory that lives elsewhere. And yet, the checks seem to confirm it.
The system is saying that that identity, from that point of observation, is no longer a simple service with minimal privileges. Quite the opposite.
And this is exactly where the illusion becomes interesting, because if reality has not changed, then something else has.
And, as with the Statue of Liberty, the right question is not “what happened”, but:
“where are we looking from”?
The idea in my head becomes more and more present, and I ask the consultant: put things back the way they were, let us make sure the problem is present, then let us change our point of observation.
With the user put back into the local administrators of the member server, we verify that the “effective access” shows full permissions.
At that point I ask: shall we open the ADUC from a Domain Controller and run the same check from there?
As is clear from the image, the effective access is absolutely consistent with the delegation, there is no longer any trace of the almost-full permissions.
By changing perspective, the result changed, and this confirms the illusion.
But what, then, is creating this illusion?
I look at the consultant with a slight smile and tell him: I understand what happened, the test we just ran is the confirmation, it is a matter of Security Identifiers (SID).
I ask him to perform these two operations:
· from the member server, show the SID of the local Administrators group
· from the Domain Controller, show the SID of the built-in domain local Administrators group
And there is the illusion explained: the SID in the two cases is exactly the same!
Here is the Legacy Thing coming to the surface, once again we are facing one of those subtle default mechanisms that have been there for decades and whose memory has been lost: the well-known SIDs.
What they are and why they are still there
We already dealt with the concept of the Security Identifier (SID) in chapter 2, so I will not go back over it. What matters here is a very particular category of them: the well-known SIDs.
The vast majority of SIDs are born “unique”: they are generated at the exact moment the object is created, by the Local Security Authority (LSA) for the local objects of a machine or by the Domain Controller for domain objects, and are never reused to identify anyone else. The well-known SIDs do exactly the opposite: they have a fixed value, identical on any system. They are not generated: they simply exist.
There is even a precise date to which their practical debut can be traced. SIDs are not born with Active Directory, nor with some intermediate version of Windows: they arrive already with Windows NT 3.1, the very first release of the NT family, shipped on July 27, 1993.
They were an integral part of the new security model designed by Dave Cutler’s team, the one built on access tokens and access control lists (ACL). In other words, when we talk about well-known SIDs we are not looking at a recent detail, but at a piece of architecture that has been with us, substantially unchanged, for over thirty years.
But where does the rule that imposes those fixed values come from? Who decided it, and where is it written? It is not an informal convention, nor a choice left to the individual implementation: it is set down in black and white in an official specification. The well-known SIDs are listed, one by one, in the [MS-DTYP] Windows Data Types document, in the section dedicated to the Well-Known SID Structures, where it is explicitly stated that their values “remain constant across all operating systems”.
It is one of Microsoft’s Open Specifications, that is, the protocol documentation designed so that anyone can implement the same model in an interoperable way. In other words, it is not that “Windows does it this way”: it is that anyone who wants to speak the same language is required to use exactly those numbers.
And here we come to a point that often surprises: the SID is not exclusive to the Windows world. The documentation itself distinguishes two families. On one side there are the universal well-known SIDs, which are meaningful “on all secure systems that adopt this security model, including operating systems other than Windows”, such as Everyone / World (S-1-1-0) or Creator Owner (S-1-3-0), the latter used as a placeholder in inheritable ACEs. On the other side there are the Windows-specific ones, including the BUILTIN groups.
That this is not just theory is confirmed in the field: implementations such as Samba, which today can act as an Active Directory Domain Controller on Linux, reason with exactly the same SIDs. For them the local Administrators group is the identical S-1-5-32-544, and components like winbind exist precisely to map those SIDs onto the UID/GID of the Unix world.
The security model, in short, crossed the boundaries of Windows long ago.
Let us go back to our case. The Administrators group of the “built-in domain” has a very specific well-known SID: S-1-5-32-544. It is worth reading it piece by piece: the 5 is the NT authority, the 32 identifies precisely the built-in domain, and the 544 is the RID of the Administrators group.
Always that one: on the member server, on the Domain Controller, on the consultant’s laptop. Identical, and not by chance.
The detail that generates the illusion lies entirely in that shared value. On a member server, S-1-5-32-544 is the group of the local administrators of that machine, and nothing more. On a Domain Controller, however, the “built-in domain” coincides with the domain itself: that same identical SID represents there the administrators of the domain, with all the authority over the directory that comes with it.
When the Effective Access is calculated from the member server, the tool sees that the gMSA belongs to S-1-5-32-544 and compares it with the ACLs of Active Directory, where that same SID enjoys full permissions. The tool does not know, and cannot know, that “that 544, seen from here, is only valid locally”. It puts together two different contexts that share the same label and returns an inflated picture. It is enough to move the point of observation to a DC for the ambiguity to disappear: from there the context is only one, and the numbers add up.
So why, after decades, are they still there? For the same reason you do not switch language halfway through a conversation. The well-known SIDs are one of the fundamental bricks of the authorization model: inherited ACEs, access tokens, delegations, default permissions, everything rests on them. Changing them would mean breaking compatibility with anything written in the last thirty years, and not only on the Windows side. They are stable by design: it is the specification itself that binds them to remain constant over time and across different systems.
They are not, therefore, an error, nor an oversight left lying around out of laziness. They are exactly what they were meant to be. The problem is not the SID: it is that we, faced with an interface, tend to read a label while forgetting where we are looking at it from. And the point of observation, as usual, is everything.
What it taught us
The first lesson this case leaves us is only simple in appearance: the tool was not lying. The Effective Access did exactly its job, it calculated the access starting from what it saw from that point, and it answered in a formally correct way. The problem is that we were looking for another truth, that of the real permissions on the directory, and it had never promised to tell us that one. So I come back to that motto I have already used in these pages, because there is no better summary: IT systems do not do what you want, they do what you tell them to do. We had effectively asked that tool “tell me what you see from here”, and it, with implacable consistency, answered exactly that. The illusion was not in the software, but in having mistaken its answer for the question we had in our heads.
The second lesson concerns the way we react when facing an “impossible” behaviour. The instinct, almost always, is to immediately look for a culprit: a bug, a wrong configuration, a compromise, something that “broke”. But in this case nothing had broken, and no hunt for a culprit would have led anywhere. The turning point came only when we stopped asking ourselves “what happened” and started asking “where are we looking from”. Moving the point of observation, from the member server to the Domain Controller, made the anomaly vanish exactly as the Statue of Liberty returned to its place the moment the audience realized it had moved. The consultant, faced with those impossible permissions, had exclaimed “it is the world turned upside down!”. And that is precisely where the lesson lies:
When the world seems absurdly upside down, almost always it is not the world that has flipped over: it is your point of observation that is wrong.
Before believing that it is reality spinning the wrong way, it is worth checking where we are looking at it from.
There is, finally, a third lesson, and it is the one that holds the entire series together: legacy is not a defect, it is lost memory. The well-known SID was not an error left there out of laziness, it was exactly what it was meant to be, stable by design for over thirty years. What was missing was not the correctness of the system, but our knowledge of the model, knowing that that 32 means “built-in domain” and that that 544 is worth the exact same number in different worlds. It is the same thread that runs through all these chapters. The guardian of AdminSDHolder rewriting permissions no one was asking for anymore, the trusts born to give shape to trust and turned into an invisible constraint, the Domain Controller that seemed to lie while it was telling the truth. Every time, the point was not that the system was broken. The point was that the system kept doing what it had been designed to do, while we had lost part of the memory of that design.
Perhaps this is the real illusion of legacy systems: they do not deceive us by hiding, they deceive us by staying in plain sight, so obvious and silent that we stop really looking at them. They keep answering with precision, but we have forgotten the question they were answering. And so, as in front of the Statue of Liberty, the only way to recognize the trick is not to stare more intensely at the same spot, but to have the humility to move and ask ourselves where we are looking from.
And it is exactly from here that Legacy Things continues its journey: bringing back to light those silent mechanisms that, although born decades ago, still govern the behaviour of modern infrastructures. Not out of nostalgia, but because ignoring them does not make them harmless. It only makes them better at showing us things that do not exist.