November has arrived, and the morning and evening chill has set in for real. Many of you have probably started turning on the heat at the office.
With a warm cup of coffee in hand, we bring you Part 4 of the series, "Proxy Servers and Integrated Windows Authentication".

In the previous installment (Part 3), we took a deep dive into how the "trust relationship" is established when client PCs and servers join a domain. Now that you understand how computer accounts authenticate automatically with 120-character passwords, today's discussion of proxy servers should feel like a smooth continuation.

When building an intermediary proxy that monitors access to ChatGPT and Claude, the single most important requirement is reliable user identification. Even if you manage to intercept HTTPS traffic and record inputs and outputs, if you cannot tell whether the access came from "tanaka_t" or "yamada_h," the value of your audit log is cut in half.

In this installment, we explain in detail how running the proxy server itself as a domain member enables Kerberos ticket verification and transparent user authentication. From an environment you can build in one hour with the Windows build of Squid, to a full-scale implementation on Linux, to the inner workings of authentication helper programs, we cover the knowledge you need for implementation.

Pay particular attention to the three-stage authentication fallback mechanism: Negotiate/NTLM/Basic. It lets you build a flexible authentication foundation—single sign-on for in-office access, Basic authentication for VPN and external access. For running a generative AI monitoring service across diverse environments, this is truly essential technology.

Now, let's marshal everything we have learned so far and take on the challenge of building an enterprise-grade proxy authentication system!

Series Outline

Chapter 1: Understanding the Basic Concepts - Fundamentals of Active Directory and Kerberos/NTLM authentication

Chapter 2: Building the Domain Environment - Steps for building a test environment

Chapter 3: Joining Clients and Servers to the Domain - Detailed domain-join procedures

[★This installment★] Chapter 4: Proxy Servers and Integrated Windows Authentication

Chapter 5: Browser Configuration and Authentication - Configuration for each browser

Chapter 6: Troubleshooting - Common problems and solutions

Chapter 7: Security and Best Practices - Considerations for production environments

Chapter 8: Practical Configuration Examples - Integration examples with AI security tools

Chapter 4: Proxy Servers and Integrated Windows Authentication

4.1 Integrated Windows Authentication and Basic Proxy Server Configuration

What Is "Integrated Windows Authentication"?

First things first: "Integrated Windows Authentication"—what is it, exactly? Let's start there.

Integrated Windows Authentication (IWA) is a mechanism that automatically authenticates you to network resources—websites, proxy servers, and the like—using your Windows login credentials.

Its defining feature is single sign-on (SSO). Log in to Windows once in the morning, and that credential lets you access a variety of services without entering any additional passwords.

Integrated Windows Authentication is implemented primarily through two protocols:

• Kerberos authentication: the most secure and recommended method
• NTLM authentication: the fallback for environments where Kerberos cannot be used

In corporate environments, this mechanism reliably records "who accessed what, and when," making it an important technology from the standpoint of security auditing and compliance.

4.1.1 Why the Proxy Server Also Needs to Join the Domain

For a proxy server to identify users via Integrated Windows Authentication, the proxy server itself must also be joined to the AD domain.

This is the point that puzzles most people at first.

For example, an exchange like this happens:

Network admin: "I've set up the proxy server"
Security lead: "Log who accessed what"
Network admin: "I can tell you the IP address, but..."
Security lead: "I want it recorded by username"
Network admin: "Then the proxy needs to join the domain too"
Security lead: "Why? The proxy isn't the one doing authentication, is it?"

Let's look at the problems when the proxy is not domain-joined. The following explains why a proxy server that has not joined the domain cannot authenticate users.

[Proxy NOT joined to the domain]
User (Tanaka): "I want to access an external site"
PC: "Going through the proxy"
PC→Proxy: "I am JP\tanaka_t" (with Kerberos ticket)

Proxy: "A Kerberos ticket? What is this?"
Proxy: "I don't know the domain, so I can't verify it"
Proxy→DC: "Is this ticket genuine?"
DC: "Who are you? I don't talk to untrusted servers"

Result: user authentication fails
Proxy log: "Access from 192.168.1.50" (IP address only)

First, some background:

• When Tanaka logged in to his PC after arriving at the office in the morning, he already obtained a Kerberos ticket (something like an ID card)
• This ticket is an encrypted credential proving that "this really is Tanaka himself"
• But if the proxy is not joined to the domain, it has no idea what to do with this ticket

And here is the key part:

Proxy→DC: "Is this ticket genuine?"
DC: "Who are you? I don't talk to untrusted servers"

• The proxy tries to ask the DC (the domain controller) to verify the ticket, but...
• The DC will not communicate with servers it does not know (naturally, for security)
• This is because the "trust relationship" we covered in Part 3 does not exist

As a result:

Result: user authentication fails
Proxy log: "Access from 192.168.1.50" (IP address only)

is what we end up with.

Why This Is a Problem

From the perspective of a ChatGPT, Gemini, and Claude monitoring service like our own LLM-Audit (for convenience, referred to below as a "ChatGPT monitoring service"):

1. The audit log loses value
   • "Confidential information was sent to ChatGPT from 192.168.1.50" → impossible to identify whose action it was
   • With shared PCs used by multiple people, tracking becomes completely impossible
     
2. Security incident response becomes difficult
   • Even when a leak occurs, the responsible person cannot be identified
   • Nor do you know who should receive corrective guidance
     
3. Access control cannot be implemented
   • Controls like "Sales may use ChatGPT, Development may not" are impossible
   • Everything can only be controlled at the IP-address level

This is the essential reason the proxy server, too, must join the domain.

How a Domain-Joined Proxy Behaves

Now let's look at the opposite case: behavior when the proxy is domain-joined.

[Domain-joined proxy]
User (Tanaka): "I want to access an external site"
PC→Proxy: "I am JP\tanaka_t" (with Kerberos ticket)

Proxy: "I am JP\PROXY-01$"
Proxy→DC: "Please verify this Kerberos ticket"
DC: "Ah, PROXY-01$. You're a trusted member"
DC: "The ticket is genuine. This is tanaka_t"
Proxy: "Verified"

Proxy log: "tanaka_t accessed www.example.com"

As you can see, a domain-joined proxy server can
reliably identify users.

Where a non-joined proxy could only record "access from 192.168.1.50," a joined proxy records "tanaka_t accessed this."

"It takes this much work just to figure out who used it?"

We hear this a lot—and yes, it really is this much work.

The history of Microsoft authentication goes back to Windows NT, so it carries a great deal of historical baggage dating from those very early days.
If you are used to modern OpenID Connect (the "Sign in with Google" kind of thing), you may well find yourself thinking, "seriously?" ^^;

Get past this hardship, though, and in a ChatGPT monitoring service you gain real clarity: when confidential information is entered, you know exactly who entered it, enabling appropriate responses (guidance to the person, incident reporting, and so on). Per-user analysis also becomes possible when distinguishing legitimate business use from inappropriate use.

The Concept of a Chain of Trust

Why a "Chain of Trust" Is Necessary

In the world of Active Directory, all security rests on trust relationships. It resembles vouching for someone's identity in the real world: when deciding whether you can trust someone you have just met, an introduction from a mutual acquaintance puts you at ease—the same principle.

A Kerberos ticket is an encrypted credential, but not just anyone can verify its authenticity. Only "trusted members" of the same domain can. This is the essential meaning of domain joining: only by joining do you enter the "circle of trust."

For intermediary systems like proxy servers in particular, this chain of trust is critical. The user's PC and the proxy server do not form a direct trust relationship; instead, both trust the DC, and the DC trusts both—a triangular relationship through which trust is established indirectly.

So let's understand the chain of trust.

[Why domain joining is required - the chain of trust]
Security principles:
1. Users trust the DC
2. The DC trusts domain members
3. Domain members trust one another

Bank analogy:
- The bank (DC) knows its account holders (domain members)
- Account holders can transact with each other under the bank's guarantee
- Outsiders cannot take part in transactions

IT admin: "The proxy needs to join this circle of trust too"

This chain of trust makes the following possible:

1. Ticket verification - the proxy can confirm the authenticity of Kerberos tickets
2. User identification - the username can be reliably extracted from the ticket
3. Audit log integrity - the record "tanaka_t accessed this" is preserved in a tamper-proof form

For a ChatGPT monitoring service, this chain of trust allows you to reliably record who sent what information to ChatGPT, and when. Records can be kept not merely by IP address but under AD-guaranteed usernames, leaving an audit trail that satisfies compliance requirements.

4.1.2 How User Authentication Works

So how does user authentication actually work?

User authentication at a proxy server involves multiple protocols working in concert. Let's examine the mechanism in detail.

[Authentication flow - overview]
9 a.m.: Tanaka opens his browser
Tanaka: "Let's check the news"
Browser: "Proxy settings... proxy.jp.qualiteg.com:8080"

1. Browser→Proxy: "GET http://news.example.com"
2. Proxy: "Authentication required" (407 Proxy Authentication Required)
3. Browser: "Which authentication schemes can I use?"
4. Proxy: "Negotiate (Kerberos/NTLM) and Basic are available"
5. Browser: "Then I'll take the most secure one: Negotiate"

Kerberos Authentication in Detail

Let's start with the typical in-office case. By the time Tanaka logs in to his PC in the morning, the groundwork for authentication is in fact already done: the Windows login obtained a TGT (Ticket Granting Ticket).

The TGT is, so to speak, "an ID card for getting ID cards issued." It is used to obtain a dedicated service ticket for each service you access (file servers, proxies, and so on).

[Kerberos authentication flow]
Premise: Tanaka logged in to his PC in the morning
(At that point he already obtained a TGT = Ticket Granting Ticket)

1. Ticket request
Browser: "I need a service ticket for the proxy"
PC→KDC: "Please give me a ticket for HTTP/proxy.jp.qualiteg.com"
KDC: "Your TGT is valid. Here is your service ticket"

2. Sending the authentication header
Browser→Proxy:
GET http://news.example.com HTTP/1.1
Proxy-Authorization: Negotiate YIIGHgYGKwYBBQUCoIIG...(Base64-encoded ticket)

3. Ticket verification
Proxy: "Let me verify this ticket"
Inside the proxy:
- Check the ticket's signature
- Check the expiration
- Extract the user info: tanaka_t@JP.QUALITEG.COM

4. Access granted
Proxy: "Confirmed: this is tanaka_t"
Proxy→External: "Connecting to news.example.com"
Proxy log: "2024-01-20 09:00:15 tanaka_t ALLOW http://news.example.com"

The wonderful thing about Kerberos authentication is that

users never have to think about it

. No password entry is needed—everything is handled automatically. This is single sign-on (SSO) realized.

Falling Back to NTLM Authentication

However, Kerberos is not available in every situation. When the network environment changes—working from home, VPN connections, access while traveling—Kerberos's strict requirements can no longer be met.

At such times, the system automatically switches to NTLM authentication. NTLM uses a "challenge-response" approach and can operate in more flexible environments. It is not as secure as Kerberos, but it still provides adequate safety.

[When Kerberos is unavailable]
Situation: Tanaka connects from home over VPN

Tanaka: "Working from home, but going through the company proxy"

Problem:
Browser: "Cannot resolve the proxy's SPN (Service Principal Name)"
Browser: "Kerberos won't work—falling back to NTLM"

NTLM flow:
1. Browser→Proxy: "Authenticating with Negotiate (NTLM)"
2. Proxy→Browser: "Challenge: ABC123"
3. Browser: "Encrypting the challenge with the password hash"
4. Browser→Proxy: "Response: XYZ789"
5. Proxy→DC: "tanaka_t answered XYZ789 to ABC123—is that correct?"
6. DC: "Calculating... correct"
7. Proxy: "Authentication OK"

Thanks to this fallback capability,
a ChatGPT monitoring service can reliably identify users from any network environment.
From inside the office, Kerberos works seamlessly; over VPN, NTLM takes over—the optimal authentication method is selected automatically to fit the situation.

Why Fall Back to NTLM?

Kerberos's Strict Requirements

Kerberos is a highly secure authentication method, but its operating requirements are strict in proportion. Most important is the need for a "pre-established trust relationship."

Kerberos uses a mechanism called the SPN (Service Principal Name) to make explicit which service an authentication is for. For example, the SPN "HTTP/proxy.jp.qualiteg.com" uniquely identifies "the HTTP service running on proxy.jp.qualiteg.com." The SPN must be registered with the DC, and the client must be able to resolve it correctly.

With VPN connections or access from external networks, this name resolution often fails. Inability to reach the internal DNS, high network latency, the Kerberos port (88) blocked by a firewall—for many reasons, Kerberos's strict requirements can no longer be met.

NTLM's Flexibility

NTLM, on the other hand, operates on a relatively simple challenge-response mechanism: the proxy server sends a random string (the challenge), and the client encrypts it with the password hash and sends it back. This approach requires no advance ticket acquisition and no SPN resolution.

In short, NTLM can start authentication "on the spot." As long as the client and the proxy can communicate directly, the authentication process can complete.

The Business Continuity Perspective

In corporate IT, "cannot authenticate = cannot work" is a situation that must be avoided. Work must be able to continue across many circumstances: remote work, access from business trips, network outages.

That is why Windows integrated authentication uses a mechanism called "Negotiate": it tries Kerberos first and automatically falls back to NTLM if that fails. This balances security (Kerberos preferred) with availability (NTLM still authenticates).

From the standpoint of a ChatGPT monitoring service, too, this fallback capability matters. Remote workers connecting over VPN must also be reliably identified by username. Rely on Kerberos alone, and in those cases you fall back into "only the IP address got recorded again." With the NTLM fallback, users can be identified as "tanaka_t" from any connection environment, and proper audit logs can be kept.

Next, let's understand credential caching.

What Is the Authentication Cache?

The Problem with Authenticating Every Time

Opening a single web page actually generates a large number of HTTP requests: HTML files, CSS, JavaScript, images... it is not unusual for one page to fire 50-100 requests.

If we authenticated on every request:

• A DC query for every single image
• As many as 100 round trips to the DC for one page
• Page loads become extremely slow
• DC load increases explosively

How the Cache Works

So the proxy server temporarily remembers user information once authentication succeeds. This is the authentication cache.

[Optimizing for efficiency]
If we authenticated every time:
Tanaka: "Authenticating for every single image? Slow!"
Proxy: "Checking with the DC on every request... heavy load"

Authentication cache implementation:
Inside the proxy:
Cache table:
- IP address: 192.168.1.50
- User: tanaka_t  
- Authenticated at: 09:00:15
- Expires: 09:30:15 (30 minutes)

Next request:
1. Access from the same IP
2. Cache check: "That's tanaka_t, authenticated moments ago"
3. Skip the DC check
4. Fast processing

Caveat:
IT admin: "If the IP address changes, re-authentication is required"

4.1.3 How to Identify a User ID from an IP Address

The mechanism by which a proxy server identifies users from IP addresses is one of the important features of Integrated Windows Authentication.

Why Mapping IP Addresses to Usernames Matters

A proxy server's primary role is relaying client requests, but from a security-audit perspective, recording "who accessed what, and when" is critically important. Especially when monitoring access to generative AI services like ChatGPT, "there was access from 192.168.1.75" is not enough; you need to be able to say "Tanaka entered confidential information."

Traditional proxy servers could record only IP addresses due to technical constraints—the HTTP protocol itself carries no user identification. By implementing Integrated Windows Authentication, however, the proxy server obtains the username through the authentication process and can manage it mapped to the IP address.

This mapping is temporary and is held as a table inside the proxy server. When multiple requests arrive from the same IP address, the proxy consults this table to identify the user quickly instead of authenticating every time. This ties in closely with the "authentication cache" described earlier.

What matters is that this mechanism integrates information from two different layers: the network layer (IP addresses) and the application layer (user authentication). Traceability during incidents improves dramatically, and compliance requirements can be met.

Now let's look at the concrete behavior.

[Basic mapping]
Auditor: "Who was using IP address 192.168.1.75?"

The usual way:
1. Check the DHCP logs
2. Identify the MAC address at that time
3. Identify the PC from the MAC address
4. Check who was logged in on that PC

Auditor: "Way too much work..."

With Integrated Windows Authentication:
Proxy log: "09:15:30 tanaka_t 192.168.1.75 ALLOW http://..."
Auditor: "Crystal clear!"

Let's look at the process of binding authentication to an IP address.

[How it actually works]
1. TCP connection established
Client (192.168.1.75) → Proxy: "Connecting"
Proxy: "Recording source IP: 192.168.1.75"

2. HTTP request
GET http://example.com HTTP/1.1
Host: example.com
(No credentials at this point)

3. Authentication request
Proxy→Client: "407 Authentication required"

4. Request with credentials
GET http://example.com HTTP/1.1
Proxy-Authorization: Negotiate YII...
Proxy: "User identified from credentials: tanaka_t"

5. Mapping complete
Proxy internal DB:
| IP address    | User ID   | Auth time |
|--------------|-----------|----------|
| 192.168.1.75 | tanaka_t  | 09:15:30 |

Let's see what happens when multiple users share the same PC.

[Behavior on a shared PC]
Morning: Tanaka logs in
Proxy log: "08:00 tanaka_t 192.168.1.100"

Noon: Tanaka logs off, Yamada logs in
Proxy: "Same IP, but the credentials changed"
Proxy log: "13:00 yamada_h 192.168.1.100"

Key points:
- Integrated Windows Authentication identifies the currently logged-in user
- When users switch, it updates automatically
- Even with the same IP address, users are distinguished by username

4.2 Implementation with Squid

4.2.1 Advantages of the Windows Build of Squid

Why Platform Choice Matters

When building a proxy server, many organizations end up debating "Linux or Windows?" Squid was originally developed for Unix/Linux, but when integration with an Active Directory environment is the goal, the Windows build actually has major advantages.

The greatest advantage of the Windows build of Squid is that it can directly use Windows' native SSPI (Security Support Provider Interface). SSPI is an API that abstracts Windows' authentication features; using it, Kerberos/NTLM authentication is handled natively. The Linux build, by contrast, must combine multiple components—Samba, Winbind, Kerberos—to achieve the same thing, and configuration complexity increases dramatically.

For use cases like ChatGPT monitoring in particular, rapid deployment and stable operation are required. The Windows build integrates immediately into an existing AD environment and works naturally with Windows management tools and event logs. Shorter build time also matters in the sense of getting security measures in place sooner.

Let's look at the concrete differences.

[The platform debate]
CTO: "I want to deploy a proxy server"
Linux admin: "Squid has a solid track record. Let's build it on Linux"
Windows admin: "But considering AD integration, Windows would be..."
CTO: "So which is it?"

Enter the Windows build of Squid:
IT admin: "Actually, Squid has a Windows build too"
Both: "What!"

The Concrete Difference in Configuration Effort

The most striking difference between the Windows and Linux builds is the time and effort configuration takes. On Windows, you join the domain through the GUI just as with any Windows server, then lightly edit Squid's configuration file, and it works. On Linux, you must write multiple configuration files precisely and verify that all the components cooperate.

[Ease of AD integration]
Steps on Linux:
1. Configure Kerberos (/etc/krb5.conf)
2. Configure Samba (/etc/samba/smb.conf)
3. Join the domain (net ads join)
4. Configure Winbind
5. Configure the authentication helper
Linux admin: "That took a whole day..."

Steps on Windows:
1. Ordinary domain join (GUI)
2. Edit Squid's configuration file
Windows admin: "Done in an hour!"

Installation and Basic Configuration

Installing the Windows build of Squid is just a matter of running an installer, like any typical Windows application. It also registers itself automatically as a service, so Windows administrators get to work in a familiar environment.

[Installation steps]
1. Download
IT admin: "Download the Windows build from Diladele's site"
https://docs.diladele.com/

2. Run the installer
- Run squid-4.x-windows-x64.msi
- Install location: C:\Squid
- Registered automatically as a service

3. Initial configuration
Edit C:\Squid\etc\squid\squid.conf

Configuring Integrated Windows Authentication is as simple as specifying the path to the authentication helper. Because SSPI is used, Windows handles the complex authentication mechanics for you.

[Integrated Windows Authentication settings]
# Basic settings in squid.conf

# Define the authentication scheme
auth_param negotiate program C:/Squid/lib/squid/negotiate_sspi_auth.exe
auth_param negotiate children 10
auth_param negotiate keep_alive on

# Access control
acl authenticated proxy_auth REQUIRED
http_access allow authenticated
http_access deny all

# Port settings
http_port 8080

# Log settings (record usernames)
access_log C:/Squid/var/log/squid/access.log squid

IT admin: "That's all it takes to get Integrated Windows Authentication working"

Management as a Windows Service

The Windows build of Squid runs as a standard Windows service, so it can be controlled easily from PowerShell or the service management tools. This is a major operational benefit, and it integrates readily with existing monitoring tools and scripts.

[Running as a Windows service]
# Check the service
Service name: squidsrv

# Managing with PowerShell
# Check status
Get-Service squidsrv

# Stop / start
Stop-Service squidsrv
Start-Service squidsrv

# Configure automatic startup
Set-Service squidsrv -StartupType Automatic

Benefits:
- Standard Windows management methods
- Event log integration
- Automatic startup and recovery

4.2.2 Configuration with the Linux Build of Squid

Reasons to Choose Linux, and the Challenges

Not every organization runs Windows Server. Cost reduction, use of existing Linux infrastructure, an open-source orientation—there are many reasons to choose Linux. Fortunately, thanks to the Samba project's work, integration with Active Directory is possible on Linux as well.

That said, building on Linux carries the essential difficulty of **bridging two different worlds: Windows and Linux**. You must correctly configure multiple components—Kerberos settings, domain joining via Samba, authentication integration via Winbind—and make them work in concert.

[Why choose the Linux build]
Linux admin: "Linux servers are our standard here"
Security lead: "But AD authentication is a must"
Linux admin: "No problem, it works once configured. However..."

Required Packages and Their Roles

Achieving AD integration on Linux requires several packages, each with a specific role, working in concert: squid provides the proxy function, samba and winbind handle communication with AD, krb5 handles Kerberos authentication, and the various lib packages handle system integration.

[Preparation]
# Base packages
sudo apt update
sudo apt install squid samba winbind libpam-winbind libnss-winbind krb5-user

# Questions during installation
Default Kerberos version 5 realm: JP.QUALITEG.COM
Kerberos servers: dc01.jp.qualiteg.com dc02.jp.qualiteg.com
Administrative server: dc01.jp.qualiteg.com

Configuring Kerberos - The Authentication Foundation

Kerberos is the standard protocol for distributed authentication and the authentication foundation of Active Directory. Configuring Kerberos correctly on the Linux side lets it verify Windows Kerberos tickets. In the configuration file (/etc/krb5.conf), you specify the realm (domain) information and the location of the KDC (Key Distribution Center—that is, the DC).

[Configuring /etc/krb5.conf]
[libdefaults]
    default_realm = JP.QUALITEG.COM
    dns_lookup_realm = false
    dns_lookup_kdc = true
    forwardable = true

[realms]
    JP.QUALITEG.COM = {
        kdc = dc01.jp.qualiteg.com
        kdc = dc02.jp.qualiteg.com
        admin_server = dc01.jp.qualiteg.com
        default_domain = jp.qualiteg.com
    }

[domain_realm]
    .jp.qualiteg.com = JP.QUALITEG.COM
    jp.qualiteg.com = JP.QUALITEG.COM

# Test
kinit administrator@JP.QUALITEG.COM
Password: ********
klist  # check tickets

Joining the Domain with Samba

Samba is the software that brings Windows networking capabilities to Linux. The winbind component in particular translates between Windows SIDs and Linux UIDs/GIDs, integrating AD authentication into the Linux system. By joining the domain, this Linux server too becomes a full member of AD.

[Samba configuration and domain join]
# /etc/samba/smb.conf
[global]
    workgroup = JP
    security = ADS
    realm = JP.QUALITEG.COM
    
    idmap config * : backend = tdb
    idmap config * : range = 10000-20000
    
    winbind use default domain = yes
    winbind refresh tickets = yes

# Join the domain
sudo net ads join -U administrator
Enter administrator's password: ********

Using short domain name -- JP
Joined 'SQUID-PROXY' to dns domain 'jp.qualiteg.com'

# Start services
sudo systemctl enable winbind
sudo systemctl start winbind

# Verify
wbinfo -t  # trust relationship test
wbinfo -u  # list users

Configuring Authentication in Squid

With all the preparation done, it is finally time to add authentication settings to Squid. On Linux, you use the authentication helpers provided by Samba, such as negotiate_wrapper_auth and ntlm_auth. They perform Kerberos/NTLM authentication against AD and return the results to Squid.

[Configuring /etc/squid/squid.conf]
# Negotiate (Kerberos/NTLM) authentication
auth_param negotiate program /usr/lib/squid/negotiate_wrapper_auth \
    --kerberos /usr/lib/squid/negotiate_kerberos_auth \
    --ntlm /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param negotiate children 10
auth_param negotiate keep_alive on

# NTLM authentication (fallback)
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 10
auth_param ntlm keep_alive on

# Basic authentication (last resort)
auth_param basic program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic
auth_param basic children 5
auth_param basic realm Proxy Server
auth_param basic credentialsttl 2 hours

# ACL definitions
acl authenticated proxy_auth REQUIRED
http_access allow authenticated
http_access deny all

# Port settings
http_port 8080

# Logs (with usernames)
access_log /var/log/squid/access.log squid

Troubleshooting Points

Because the Linux build has more places to configure, isolating problems is also more complex. It is important to know the checkpoints: testing the authentication helpers directly, checking Kerberos tickets, time synchronization, permission settings, and so on.

[Common problems and fixes]
Problem 1: authentication doesn't work
# Test the authentication helper
/usr/bin/ntlm_auth --username=tanaka_t --domain=JP
Password: 
NT_STATUS_OK: Success (0x0)

Problem 2: Kerberos fails
# Check the SPN
klist -k /etc/squid/HTTP.keytab
# Time synchronization
timedatectl status

Problem 3: permission errors
# Check the Squid user
sudo usermod -a -G winbindd_priv proxy

4.2.3 The Role of Authentication Helper Programs

The Bridge Between Squid and the Authentication System

Within a proxy server's integrated authentication, the authentication helper is the most important—and least understood—component. Many administrators assume that "writing the auth settings in squid.conf makes it work," but in fact Squid itself knows nothing about the details of authentication.

Squid uses a modular design and delegates authentication processing to external programs (authentication helpers). This allows Squid to support various authentication backends—LDAP, RADIUS, Active Directory—without changing Squid's own code.

The authentication helper receives the credentials sent by the browser (a Kerberos ticket, an NTLM token, or a Basic-auth ID/password), verifies them against AD, and returns the result and the username to Squid. This mechanism is what makes it possible to record the username "tanaka_t" in access logs for ChatGPT.

[What is an authentication helper?]
Newcomer: "Doesn't Squid itself do the authentication?"
Senior: "Squid delegates authentication to authentication helpers"

Architecture:
Browser ←→ Squid ←→ Auth helper ←→ AD

Why:
- Squid is designed to be independent of authentication schemes
- Swapping the helper supports different authentication types
- Separation of authentication logic

Inside the Authentication Helper

Authentication helpers run as independent processes and communicate with Squid over standard input/output. Squid launches as many helper processes as specified by the "children" parameter and processes authentication in parallel. This keeps authentication from becoming a bottleneck even when many users access the proxy simultaneously.

[The actual communication flow]
1. Squid launches the authentication helpers
Squid: "Launching 10 instances of negotiate_sspi_auth.exe"
(the number specified by the children parameter)

2. Forwarding the authentication request
Browser→Squid: "Negotiate YIIGHgYGKwYBBQUCoIIG..."
Squid→Helper: "YR YIIGHgYGKwYBBQUCoIIG..."

3. Helper processing
Helper: "Querying Windows via SSPI"
Windows: "This is tanaka_t's ticket"
Helper→Squid: "OK user=tanaka_t"

4. Squid's processing
Squid: "Confirmed as tanaka_t. Access granted"

Differences Between the Windows and Linux Helpers

The Windows and Linux builds use different authentication helpers. The Windows build can use SSPI directly, making it simple and fast. The Linux build goes through Samba's ntlm_auth, adding slight overhead, but it is functionally equivalent.

[Windows-build authentication helpers]
1. negotiate_sspi_auth.exe
- Uses SSPI (Security Support Provider Interface)
- Supports both Kerberos and NTLM
- Windows only

2. basic_sspi_auth.exe  
- Verifies Basic authentication against AD via SSPI
- Passwords validated by AD

[Linux-build authentication helpers]
1. negotiate_wrapper_auth
- Tries both Kerberos and NTLM
- Automatically picks the appropriate one

2. ntlm_auth (part of Samba)
- NTLM/NTLMv2 authentication
- Talks to AD via Winbind

3. negotiate_kerberos_auth
- Kerberos only
- Requires a keytab file

Debugging and Troubleshooting

When authentication fails, running the authentication helper directly lets you isolate the problem. Enabling Squid's debug logging also reveals the details of the authentication process.

[Debugging authentication helpers]
# Manual test (Windows)
C:\Squid\lib\squid\negotiate_sspi_auth.exe -d

# Manual test (Linux)
echo "tanaka_t password123" | /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic

# Squid debug logging
debug_options ALL,1 29,9 # enable authentication debugging

# Check cache.log
tail -f /var/log/squid/cache.log | grep negotiate

4.2.4 Configuring Fallback to Basic Authentication

Why Multiple Authentication Methods Are Needed

Corporate network environments are diversifying. You must handle many scenarios: in-office access, remote work over VPN, access from business trips, access from BYOD (personal) devices.

Kerberos authentication is the most secure but works only inside the domain. NTLM is more flexible but still has limitations. Basic authentication is the most compatible but the weakest on security. Combining them lets you strike a balance between security and convenience.

Especially for uses like ChatGPT monitoring, "we couldn't authenticate, so no logs were captured" is a situation that must be avoided. The fallback mechanism ensures users can be identified reliably from any environment.

[Why fallback is needed]
Situation 1: a sales rep connects from a client's office
Sales: "I need to access company systems from the client's network"
Kerberos: "Not available outside the domain"
NTLM: "Difficult here too"
Basic auth: "Just enter your ID and password and you're in"

Situation 2: a personally owned device
Employee: "I need urgent access from my Mac at home"
Integrated auth: "Not possible—it isn't domain-joined"
Basic auth: "ID and password will do"

Setting Priorities Across Multiple Authentication Methods

Squid lets you enable multiple authentication methods at once and rank them. Clients automatically choose the most secure method they support. The order of the settings matters: list the more secure methods first.

[Settings in squid.conf]
# Authentication scheme priority
# 1. Negotiate (Kerberos/NTLM)
auth_param negotiate program C:/Squid/lib/squid/negotiate_sspi_auth.exe
auth_param negotiate children 10
auth_param negotiate keep_alive on

# 2. NTLM (when Kerberos is unavailable)
auth_param ntlm program C:/Squid/lib/squid/ntlm_sspi_auth.exe
auth_param ntlm children 10
auth_param ntlm keep_alive on

# 3. Basic (last resort)
auth_param basic program C:/Squid/lib/squid/basic_sspi_auth.exe
auth_param basic children 5
auth_param basic realm "Company Proxy - Enter JP\\username"
auth_param basic credentialsttl 2 hours

# Accept all authentication schemes
acl authenticated proxy_auth REQUIRED
http_access allow authenticated

Authentication Negotiation with the Browser

The choice of authentication method is negotiated automatically between the proxy and the browser. The proxy presents every available method, and the browser picks the best one. This process is normally invisible to users, but understanding it helps with troubleshooting.

[Negotiation with the browser]
1. First access
Browser→Squid: GET http://example.com
Squid→Browser: 407 Proxy Authentication Required
                Proxy-Authenticate: Negotiate
                Proxy-Authenticate: NTLM
                Proxy-Authenticate: Basic realm="Company Proxy"

2. The browser's decision
Office PC: "Negotiate works" → Kerberos authentication
Outside PC: "Negotiate won't work... only Basic" → shows a popup

3. Basic authentication flow
User: enters "JP\tanaka_t / password"
Browser: Base64 encoding
Browser→Squid: Proxy-Authorization: Basic SlBcdGFuYWthX3Q6UGFzc3dvcmQ=
Squid→Helper: JP\tanaka_t Password
Helper→AD: verify credentials
Helper→Squid: OK
Squid: access granted

Hardening Basic Authentication

Basic authentication is essentially plaintext (only Base64-encoded), so security measures are mandatory. Raise safety through defense in depth: HTTPS, restrictions on where it can be used from, and appropriate cache-lifetime settings.

[Risks of Basic authentication and countermeasures]
Risk:
Security lead: "Basic is just Base64 encoding. That's not encryption"

Example:
Proxy-Authorization: Basic SlBcdGFuYWthX3Q6UGFzc3dvcmQ=
↓ decode
JP\tanaka_t:Password

Countermeasure 1: use HTTPS
# Serve Squid over HTTPS
https_port 8443 cert=/etc/squid/cert.pem key=/etc/squid/key.pem

# Client-side setting
https://proxy.jp.qualiteg.com:8443

Countermeasure 2: restrict access
# Allow Basic auth only from specific networks
acl internal src 192.168.0.0/16
acl external src all

# All auth schemes allowed for the internal network
http_access allow internal authenticated

# Restrict Basic auth from outside
acl negotiate_auth proxy_auth REQUIRED
http_access allow external negotiate_auth
http_access deny external

Improving Usability

While maintaining security, user convenience also deserves attention. Setting appropriate credential cache lifetimes and showing clear error messages will reduce help desk inquiries.

Summary

In Part 4, we explained how joining the proxy server to the Active Directory domain enables reliable identification of who accessed generative AI services such as ChatGPT.

"It takes this much work just to figure out who used it?" is an honest question—but this chain of trust is precisely what underpins corporate security auditing. We learned that only by joining the domain can the proxy server verify Kerberos tickets, making it possible to record activity by username rather than IP address.

Next Time: Chapter 5, Browser Configuration and Authentication

Next time, we take a detailed look at configuration on the browser side—the part users actually touch.

We will answer questions end users often ask, such as "why does IE log me in automatically while Chrome asks for a password?" We cover practical topics including the intranet zone concept, configuration in Chrome and Firefox, and bulk configuration via Group Policy.

See you in Part 5!