InfoSec architect 101-Service account from prehistory

I’ve worked in the industry for many, many years. I used to believe that “service accounts” were basic knowledge for anyone in this field. But over time, I’ve discovered that many people—even developers and system administrators—don’t really understand what service accounts are or how they work.

In this blog post, I want to explain service accounts using a hands-on approach. I’ll use a simple Windows-based lab environment to show how service accounts work in a traditional Microsoft IT setup.

Yep, I know this feels like technology from the Stone Age—I’ll write another post in the future about service accounts in the cloud.

So, why Do We Need Service Accounts?

Imagine this situation: You’re an IT admin at a company. Hundreds of employees need to access systems like databases, file servers, and email every day. If every system has its own username and password, it becomes a nightmare to manage.

Even worse, some backend applications need to connect to a database automatically.

Should we store the database password inside the code? -- Of course not! That’s just asking for trouble.

This is where service accounts come in.

The Pain of Not Using Service Accounts

In theory, we can connect to SQL Server like this:

sqlcmd -S ServerName -U username -P password

This method brings all kinds of headaches:

• Passwords are stored in config files or connection strings. If the password changes, you need to update all systems.
• Developers and DevOps may see the plain text passwords. Log files may accidentally capture them too.
• Many apps share the same DB account—you can't track who’s doing what, and fine-grained access control becomes impossible.
• Every new app or server needs new credentials, and you have to manage them manually on each machine.

What Is a Service Account?

In a Windows domain environment, a service account is a special type of user account created to run applications or services. It’s not for logging in like a normal user—it gives services their own digital identity.

Each service has its own account—just like each employee has an ID card.

Example:

DistinguishedName : CN=sql svc.,CN=Users,DC=supasaf,DC=com
SamAccountName    : sqlsvc
UserPrincipalName : sqlsvc@supasaf.com

You can give a service account only the access it needs—nothing more.

Because it doesn’t log in like a human user, it’s more secure.
Service accounts also work beautifully with Kerberos, a secure way to authenticate without using passwords.

But wait—what is Kerberos?

The Technology Behind: Kerberos

Kerberos is a network authentication protocol used in Windows domains. It uses symmetric encryption and a ticket-based system. Sounds fancy, right? But it’s actually pretty simple (well… sort of).

Kerberos has three main components:

• KDC (Key Distribution Center) – gives out keys and tickets
• AS (Authentication Server) – checks your identity
• TGS (Ticket Granting Server) – gives you access to services

In a Windows domain, all three live on the same machine: the Domain Controller (DC). So really, it’s just Active Directory in disguise :)

The Authentication Flow (with bad iPad drawing, sorry!)

1. User logs in and gets a TGT (Ticket Granting Ticket)
2. User uses the TGT to request a SGT (Service Granting Ticket) from the TGS
3. User sends the SGT to the service (like SQL) to get access—no password needed

Important Kerberos Concepts: SPN, TGT, and SGT

SPN (Service Principal Name): A unique name for a service in the domain.

Example: MSSQLSvc/SupaServer.supasaf.com:SQLEXPRESS

• MSSQLSvc: The type of service (SQL Server)
• SupaServer: Hostname
• SQLEXPRESS: SQL instance name

SPNs must be set correctly for Kerberos to work properly.

TGT (Ticket Granting Ticket): The first ticket you get when you log into the domain.

Example:

Client: Test User @ SUPASAF.COM Server: krbtgt/SUPASAF.COM Flags: forwardable, renewable, initial, preauth

SGT (Service Granting Ticket): Used to access actual services like SQL or LDAP.

Example:

Client: Test User @ SUPASAF.COM Server: LDAP/SupaServer.supasaf.com/supasaf.com Flags: forwardable, preauth, ok as delegate

No passwords, no headaches—just tickets!

Lab Demo: Passwordless SQL Authentication with Service Account

To show how all this works, I built a simple test environment using Hyper-V:

If all goes well, we can connect to SQL Server using sqlcmd, without typing any password.

sqlcmd -S SupaServer.supasaf.com\SQLEXPRESS -E

Thanks to Kerberos and the service account, this works securely and without any hardcoded password.

Bonus Tip: The klist Command

The klist command is a built-in Windows tool used to view and manage Kerberos tickets.

When you log into a Windows domain, the system automatically gets a TGT (Ticket Granting Ticket). Later, when you access services like SQL Server or LDAP, it requests SGTs (Service Granting Tickets) from the domain controller.

All these tickets are stored in your session—and you can see them with klist.

Final Thoughts: Why Hands-On Is Still Important

We live in the age of AI. Yes, you can ask AI to explain anything. But I believe there’s a big difference between reading something and doing something.

Knowledge becomes real when it turns into muscle memory.

So go ahead—build a tiny lab, break things, and make Kerberos your best friend (or at least a friendly ghost from the 80s).