We were sitting over coffee, and I brought up something that had been bugging me for a while: how does Single Sign-On actually work under the hood, especially on Linux? I’ve used SSO every single day of my working life, on Windows, on cloud consoles, on internal tools, but I had never really sat down and understood the mechanics of it.

So I called up my friend, mentor, and Linux expert, Nishant. What started as a quick question turned into a two-hour conversation covering LDAP, Kerberos, SSSD, PAM, tokens, and eventually Windows PRTs and Intune Autopilot too. I’m writing this article the way we discussed it, with real examples, so it’s easier to follow than a textbook definition.

Let’s start from the beginning.

Why “Seamless” SSO Feels Like Magic

Think about your own workday. You turn on your laptop, type your password once (or use your fingerprint), and after that, Outlook opens without asking for credentials, Teams is already logged in, SharePoint loads your files, and even your company’s internal portal recognizes you instantly. You never see a login box again for the rest of the day.

That experience isn’t magic. It’s the result of a token being issued once, at login, and quietly reused by every application afterward. On Windows, that token is called the Primary Refresh Token, or PRT. On Linux, the closest equivalent is a Kerberos Ticket Granting Ticket, or TGT. Both do the same fundamental job: prove your identity once, then let everything else trust that proof without asking you again.

Nishant put it simply: “SSO isn’t really about logging in once. It’s about your operating system holding onto a proof of identity and handing it to apps on your behalf, silently, every single time they ask.”

How Windows Handles This: The PRT Story

Let’s use an example to make this concrete. Say Shivam Tiwari, an engineer at Cloud Knowledge, gets a brand-new laptop. His email is shivam.tiwari@cloudknowledge.in, and the company uses Microsoft Entra ID (formerly Azure Active Directory) to manage identities.

Here’s what happens step by step:

1. Shivam powers on the laptop for the first time. Instead of a generic Windows setup screen, he’s greeted by Windows Autopilot, which we’ll come back to shortly.
2. He signs in with shivam.tiwari@cloudknowledge.in and his password, along with MFA if the company enforces it.
3. Behind the scenes, Windows talks to Entra ID and receives a Primary Refresh Token. This PRT is bound to the device and to Shivam’s identity together, it isn’t just a floating credential, it’s tied to that specific machine.
4. The PRT gets cached securely by the Cloud Authentication Provider (CloudAP) plugin inside the Local Security Authority Subsystem Service (LSASS), and it’s protected by the machine’s TPM (Trusted Platform Module) wherever available.

From this point forward, every time an app like Outlook, Teams, OneDrive, or even the Edge browser needs to authenticate Shivam, it doesn’t ask him to log in again. Instead:

• The app requests an access token from the Web Account Manager (WAM) on Windows.
• WAM uses the cached PRT to silently request a fresh access token from Entra ID.
• Entra ID validates the PRT, checks conditional access policies (is the device compliant, is MFA satisfied, is the location trusted), and issues a short-lived access token, usually valid for about an hour.
• The app uses that access token to call Microsoft Graph or whatever backend service it needs.

Shivam never sees a login prompt. He just opens Outlook, and his inbox is already there. That’s the PRT doing its job.

What Makes the PRT Special

A few things make the PRT more powerful than a normal access token:

It’s long-lived but renewable. A PRT typically lasts up to 14 days, and it silently refreshes itself as long as Shivam keeps signing in and using the device normally. He never notices this refresh happening.

It’s device-bound. The PRT is cryptographically tied to the device’s identity, not just Shivam’s username and password. If someone stole his password but didn’t have his laptop, they still couldn’t reuse his PRT elsewhere.

It carries device state. When Entra ID issues an access token based on the PRT, it can check whether the device is Intune-compliant, encrypted, and running the required security baseline, all as part of Conditional Access. This is why a company can say “only compliant devices can access company email” and have it enforced automatically, without asking the user anything extra.

It powers every Microsoft app quietly. Outlook, Teams, OneDrive, Word, Excel, the Company Portal app, all of them ask WAM for a token instead of prompting Shivam directly. This is why, once you’re signed into Windows with a work account, everything downstream just works.

Where Intune Autopilot Comes In

Now here’s the part that ties everything together, and the part Nishant got genuinely excited explaining.

Before Shivam even opens his laptop, someone in the IT team at Cloud Knowledge has already registered that device’s hardware hash with Windows Autopilot, either through the vendor directly (Dell, HP, Lenovo all support this) or by uploading it manually to Intune.

When Shivam powers on the laptop for the first time and connects to Wi-Fi, Autopilot recognizes the device automatically, based on that hardware hash, and instead of the generic “Hi, let’s get you set up” Windows setup wizard, he’s shown a branded Cloud Knowledge sign-in screen. He enters shivam.tiwari@cloudknowledge.in, and from there, everything happens automatically:

• The device joins Microsoft Entra ID.
• The device automatically enrolls into Intune for management, no separate enrollment step required.
• Intune pushes down all assigned configuration profiles: Wi-Fi settings, VPN profiles, security baselines, BitLocker encryption policies.
• Required applications get installed silently: Teams, Outlook, company VPN client, endpoint protection, whatever the IT team has assigned to Shivam’s user group.
• Compliance policies are evaluated: is BitLocker on, is the OS version current, is Defender running. If everything checks out, the device is marked “compliant” in Intune.

This entire flow is called a “zero-touch” or “self-deploying” experience, and it’s exactly why it’s often described as autopilot. Shivam never talks to IT. He never installs anything manually. He just signs in once, and by the time the desktop loads, his laptop is fully configured, secured, and compliant, ready for work.

And this is where the PRT and Autopilot connect. Once the device is Entra-joined and compliant, that same PRT we talked about earlier becomes the trust anchor for every future silent sign-in and Conditional Access decision. Autopilot sets the stage by getting the device properly joined and compliant, and the PRT is what carries that trust forward, invisibly, every single day after.

Nishant summed it up well: “Autopilot builds the identity and trust relationship between the device and the company. The PRT is what keeps proving that trust exists, every single time an app asks.”

Bringing It Back to Linux

This is where our conversation circled back to where it started. Linux doesn’t have Autopilot or a native PRT system, but the philosophy is remarkably similar, just built from different, mostly open-source, pieces.

If Cloud Knowledge had Linux workstations too, here’s roughly how the equivalent flow would look for an engineer with the same identity, shivam.tiwari@cloudknowledge.in:

1. The Linux machine is joined to a directory, either FreeIPA (open-source identity management, similar in spirit to Active Directory) or directly to Entra ID via tools like himmelblau or hybrid Kerberos/LDAP bridges, or joined to on-prem Active Directory using realmd and sssd.
2. SSSD (System Security Services Daemon) becomes the equivalent of WAM on Windows. It’s the background service that talks to the directory, caches credentials, and hands out tickets to whatever asks.
3. When Shivam logs into his Linux workstation with his domain credentials, Kerberos issues him a TGT (Ticket Granting Ticket), the rough equivalent of a PRT. It’s cached in memory (typically in a kernel keyring or KCM cache), not written to disk in plaintext.
4. From there, any service that trusts Kerberos, SSH into another company server, an internal Git server, a shared NFS mount, an internal web app configured for SPNEGO/Kerberos auth, all accept that TGT to issue short-lived service tickets automatically. Shivam doesn’t type his password again.

The pattern is the same shape as Windows: authenticate once, cache a strong proof of identity, and let every subsequent request quietly redeem that proof for short-lived, service-specific tokens.

The Full Token Vocabulary, Compared Side by Side

By this point in the conversation, Nishant sketched out a rough comparison on a napkin, and I think it’s worth writing out properly:

Session Token
On Windows, this is your interactive logon session, managed by the Local Security Authority. On Linux, it’s your PAM-managed login session, tracked by systemd-logind, tied to your terminal or graphical session.

Primary Refresh Token (Windows) vs Kerberos TGT (Linux)
Both are the master credential issued after your first successful login. Both are long-lived, renewable, and used to silently obtain shorter-lived tokens for individual applications, without asking you to log in again.

Access Token
On Windows, this is what WAM requests from Entra ID using the PRT, short-lived (about an hour), scoped to a specific resource like Microsoft Graph. On Linux, this is closer to a Kerberos service ticket, or in OIDC-based setups (like Keycloak or Okta integrated with Linux via pam_oidc or oauth2-proxy), a genuine OAuth2 access token.

Refresh Token
On Windows, this concept is essentially absorbed into the PRT itself, since the PRT already behaves like a long-lived refresh mechanism. On Linux, in OIDC-based SSO setups, this is a literal OAuth2 refresh token, used by the client to silently fetch a new access token when the old one expires.

Where These Tokens Actually Live

Nishant was firm on this point: tokens should never sit around as plaintext files, on either operating system.

On Windows, the PRT lives inside LSASS memory and is protected by CloudAP, with hardware-backed protection through the TPM when available.

On Linux, Kerberos tickets live in a credential cache, most modern distributions use KEYRING or KCM (Kerberos Credential Manager) rather than the old flat file cache, specifically to avoid leaving tickets readable on disk. SSSD’s own cache lives under /var/lib/sss/, encrypted, and used mainly to allow offline logins when the domain controller can’t be reached. OAuth or OIDC tokens, when used for cloud-integrated Linux SSO, typically end up in the user’s session keyring or a proper secrets service like GNOME Keyring or KWallet, never a plaintext config file, if the setup is done correctly.

A Realistic Hybrid Example

To close the loop, let’s imagine Cloud Knowledge as a real, growing company with both Windows and Linux users.

Shivam Tiwari, shivam.tiwari@cloudknowledge.in, gets a Windows laptop through Autopilot on day one. He signs in, the device auto-joins Entra ID, Intune pushes down policies, and a PRT quietly powers his entire day of silent sign-ins across Outlook, Teams, and internal web apps protected by Conditional Access.

A colleague on the platform engineering team gets a Linux workstation instead. That machine is joined to the company’s FreeIPA domain. She logs in once, gets a Kerberos TGT, and from there SSHes into build servers, pulls from an internal Git server, and mounts a shared file system, all without typing her password again, because SSSD and Kerberos are quietly handling ticket requests behind the scenes.

Two completely different technology stacks, Microsoft’s cloud identity platform on one side, open-source Kerberos and LDAP on the other, but the underlying idea is identical: authenticate once, cache a strong proof of that identity locally and securely, and let every application silently redeem that proof instead of asking the human to log in again and again.

Final Thoughts

What struck me most from this conversation with Nishant wasn’t any single technical detail, it was realizing that “seamless login” isn’t one feature. It’s an entire chain of trust: a directory service that knows who you are, a protocol that proves it without repeatedly exposing your password, a local cache that holds that proof securely, and a policy engine (Conditional Access on Windows, or PAM rules on Linux) that decides what that proof is allowed to unlock.

Autopilot and PRTs make this practically invisible on Windows. LDAP, Kerberos, and SSSD make it just as invisible on Linux, using a completely different toolset built on open standards. Once you see both sides laid out next to each other, the “magic” of never seeing a login screen stops feeling like magic, and starts feeling like good engineering.

Thanks again to Nishant for walking through all of this so patiently. If you’re setting up SSO for a mixed Windows and Linux environment at your own company, I’d genuinely recommend having this exact conversation with someone who’s implemented it hands-on, it clears up more in two hours than any documentation page will.

This article is part of the Cloud Knowledge identity and access series. For more deep dives into IAM, cloud security, and DevOps practices, visit us at cloudknowledge.in.

I originally shared a shorter version of this breakdown on LinkedIn: Decoding Seamless SSO on Linux: LDAP, Kerberos & Tokens Explained.