Squid-Proxy auf WSL mit Kerberos

Squid IP-ACLs

Squid hat von Hause aus einige Subnetze schon vordefiniert, die ich einfach in ACLs nutzen kann. Dazu nutze ich den NANO-Editor.

$ sudo nano /etc/squid/squid.conf

In der Datei finden Sie z.B. folgende Definitionen, die aber nur vorbereitet sind.

acl localnet src 0.0.0.1-0.255.255.255  # RFC 1122 "this" network (LAN)
acl localnet src 10.0.0.0/8             # RFC 1918 local private network (LAN)
acl localnet src 100.64.0.0/10          # RFC 6598 shared address space (CGN)
acl localnet src 169.254.0.0/16         # RFC 3927 link-local (directly plugged) machines
acl localnet src 172.16.0.0/12          # RFC 1918 local private network (LAN)
acl localnet src 192.168.0.0/16         # RFC 1918 local private network (LAN)
acl localnet src fc00::/7               # RFC 4193 local private network range
acl localnet src fe80::/10              # RFC 4291 link-local (directly plugged) machines

In der Konfiguration habe ich bei "http_access" ein "http_access allow localnet" addiert:

# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed

# Diese Zeile habe ich addiert, dass die in "localnet" definierten Netzwerke zugreifen dürfen
http_access allow localnet

http_access allow localhost

# And finally deny all other access to this proxy
http_access deny all

Damit die Änderung aktiv wird muss Squid einmal neu gestartet werden. Wenn sie einen Fehler bekommen, dann können Sie sich direkt die Protokolle anschauen. Meist ist ein Tippfehler in der Konfiguration

# Neu starten
$ sudo systemctl restart squid

# Fehleranalyse 1
$ systemctl status squid.service

# Fehleranalyse 2
$ journalctl -xeu squid.service

Port Forwarding

Wenn ich den Squid unter WSL auch von anderen Systemen im LAN erreichen möchte, muss ich einen Port des Hosts auf das WSL-System weiterleiten. Das geht mit Windows Bordmitteln:

#Portforwarding von HostIP auf WSL einrichten. Zur Lesbarkeit umgebrochen
netsh interface portproxy add v4tov4 
   listenport=3128 
   listenaddress=0.0.0.0 
   connectport=3128 
   connectaddress=172.21.233.163

• PortProxy - ReverseNAT mit Windows
• Port Forwarding WSL 2 to Your LAN
  https://jwstanly.com/blog/article/Port+Forwarding+WSL+2+to+Your+LAN/

Windows Firewall

Zuletzt muss ich die Windows Firewall auf meinem Host mitteilen, dass er eingehende Verbindungen auf Port 3128 zulassen soll. Das geht z.B. mit:

New-NetFirewallRule `
   -DisplayName "WSL2 SQUID Bridge" `
   -Direction Inbound `
   -Action Allow `
   -Protocol TCP `
   -LocalPort 3128

Erreichbarkeit testen

Nun sollten Sie auch von eine anderen Client im Netzwerk den Squid erreichen können. Sie könnten das z.B. per PowerShell risikolos testen.

#Einfacher Test auf dem WSL Host zu Ubuntu
Invoke-webrequest https://www.msxfaq.net -Proxy http://172.31.61.86:3128

#Einfacher Test von einem anderen System auf den WSL Host über Firewall und Port Forwarding zu Ubuntu
Invoke-webrequest https://www.msxfaq.net -Proxy http://192.168.178.10:3128

Wireshark

Die einfache unverschlüsselte Verbindungen ist auch einfach in Wireshark zu sehen. Nach dem klassischen TCP SYN ACK RES-Handshake sehen wir den GET an den Proxy, der aber im Gegensatz zu einem Zugriff auf eine Webseite die komplette URL und nicht nur den Pfad enthält.

Der Proxy holt die Datei ohne weitere Authentifizierung (nicht sichtbar) und liefert Sie in der 5. Zeile zurück. Bei der MSXFAQ ist das nur eine "301" Umleitung und so sehen wir dann auch direkt, wie ein TLS-Handshake aufgebaut wird. Der Client sendet einen "CONNECT", damit der Proxy eine ausgehende Verbindung zum Ziel aufbaut, die dann mit einem 200 hergestellt wird.

Danach sehen wir dann den klassischen TLS Handshake, über den dann die Daten transparent übertragen werden

• TCP SYN ACK RES
• TLS Handshake mit NetMon

Password-Datei für Benutzerdaten

Irgendwo muss ich ja die Benutzer mit dem Kennwort hinterlegen. Da ich auf der Ubuntu-VM keine weitere Benutzer verwalte und auch keinen Apache betreibe, nutze ich hierfür eine eigene Datei. Zuerst lege ich eine "passwords"-Datei wie folgt an:

# apache2-utils für den Befehl htpasswd installieren
$ sudo apt-get install apache2-utils

# Datei anlegen und Berechtigung anpassen
$ sudo touch /etc/squid/passwords
$ sudo chown proxy: /etc/squid/passwords
$ sudo chmod 640 /etc/squid/passwords

#password-Datei anlegen mit zwei Usern
$ sudo htpasswd -cb /etc/squid/passwords user1 Password1
$ sudo htpasswd -b /etc/squid/passwords user2 Password2

In der Datei gibt es nun zwei Benutzer mit dem hier sichtbaren Kennwort.

Squid Konfiguration

Nun muss ich Squid noch anweise, diese Datei zu nutzen.

$ sudo nano /etc/squid/squid.conf

In der Konfiguration addiere aktiviere ich nun an den passenden Stellen:

# unter # OPTIONS FOR AUTHENTICATION 
auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwords
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 24 hours
auth_param basic casesensitive off

acl authenticated proxy_auth REQUIRED

http_access allow authenticated

Achten sie darauf, dass z.B. das "authenticated" bei "http_access" auf den Eintrag "acl authenticated ..." referenziert und wenn Sie den Namen ändern, müssen Sie ihn bei beiden Einträgen anpassen.

Squid Neustart

Auch danach ist wieder ein Neustart des Squit zum Laden der Änderungen erforderlich.

# Squid neu starten
$ sudo systemctl restart squid

# Squid Sstatus abrufen
$ sudo systemctl status squid

Wenn Sie sich nicht vertippt haben, sollte Squid wieder laufen.

Kontrolle Anonym

Ein anonymer Zugriff per PowerShell wird nun mit einem 407-Fehler quittiert.

Invoke-Webrequest `
   -Uri http://www.msxfaq.net `
   -Proxy http://192.168.102.183:3128

Wireshark zeigt die 407-Antwort und auch die angebotenen Authentifizierungsverfahren.

Die PowerShell versucht aber keine automatische Anmeldung.

Kontrolle Basic Authentication

Natürlich will ich auch die Anmeldung prüfen. Zuerst nutze ich dazu die PowerShell und gebe die ProxyCredentials an:

PS C:> Get-Credential user1

PowerShell credential request
Enter your credentials.
Password for user user1: *********

PS C:\> Invoke-Webrequest  http://www.msxfaq.net -Proxy http://192.168.102.183:3128 -ProxyCredential $cred

StatusCode        : 200
StatusDescription : OK
Content           : <!doctype html>
                    <html lang="de">
                    <!-- #BeginTemplate "msxfaq2023.dwt" -->
.....

Ein Versuch mit "-ProxyUseDefaultCredentials" funktioniert aber nicht, da der Proxy nur Basic anbietet und die Powershell keinen Zugriff auf mein Kennwort hat. Der Proxy müsste daher Negotiate/Kerberos/NTLM unterstützen.

Der Firefox-Browser erlaubt unabhängig von Windows eine Konfiguration des Browsers. Hier sehe ich dann auch direkt den 407 als Dialogbox:

Wenn ich hier nun Benutzername und Kennwort eingebe und die Verbindung zum Proxy nicht TLS-verschlüsselt ist, können Sie diese Daten in Wireshark einfach mitlesen:

Vorarbeiten

Die bisher beschriebenen Vorarbeiten bleiben unverändert erhalten, d.h.

• WSL installieren
• Squid installieren
• Port-Weiterleitung von 3128 auf die WSL-IP
• Firewall für eingehende Pakete auf 3128

AD-User

Damit der KDC ein Ticket für Squid ausstellen kann, muss es ein passendes Objekt im Active Directory geben, damit dort ein SPN aber auch ein Credentials hinterlegt werden. Das ausgestellte Ticket wird nicht nur vom KDC signiert sondern auch mit den Daten für das Zielsystem geschützt. Das Objekt kann ein AD-Benutzer oder Computer sein.

Ich ziehe Computerkonten vor, da diese sich weder "interaktiv" anmelden können noch "Domain User" sind. Sie sind daher erst einmal sicherer. Group Managed Service Accounts gehen meines Wissens hier nicht und Sie sollten auch wissen, dass der Squid damit nicht "Domainmitglied" ist. Er bekommt also keine Gruppenrichtlinien o.ä.

Sie müssen das Computerkonto nicht anlegen. Das erfolgt gleich über die WSL.

Linux und Kerberos

Beachte dazu auch die Seite Kerberos mit Linux und AD

Einen Windows Desktop können Sie ja in die Domain aufnehmen und damit vertraut der dem Active Directory. Ein Linux-System ist erst einmal ein Einzelsystem, aber kann mit zentralen Verzeichnisdiensten (z.B. NIS/YellowPages) oder auch Windows Domains verbunden werden. Ich muss dem Linux beibringen, wo es die Kerberos-Dienste findet, denn eine DNS-Abfrage über den "_msdcs"-Baum findet nicht statt. Die Vertrauensstellung zum AD muss ich herstellen, in dem ich die Datei "/etc/krb5.conf" anlege oder editiere.

$ sudo nano /etc/krb5.conf

Hier definiere ich die REALMs, also die AD-Domain und die dazu hinterlegten Server. Hier ein Beispiel mit TCP Enforcement:

[libdefaults]
   default_realm = MSXFAQ.NET
   dns_lookup_kdc = no
   dns_lookup_realm = no
   default_tgs_enctypes = aes256-cts-hmac-sha1-96
   default_tkt_enctypes = aes256-cts-hmac-sha1-96
   permitted_enctypes = aes256-cts-hmac-sha1-96

[realms]
   MSXFAQ.NET = {
      kdc = 192.168.100.11:88
      admin_server = 192.168.100.11:464
}

[domain_realm]
   .MSXFAQ.NET = MSXFAQ.NET
   MSXFAQ.NET = MSXFAQ.NET

[logging]
   kdc = FILE:/var/log/kdc.log
   admin_server = FILE:/var/log/kadmin.log
   default = FILE:/var/log/krb5lib.log

Eine Variante mit DNS-Namen statt IP-Adressen schwächeren Cryptoverfahren und zwei DCs wäre:

[libdefaults]
    default_realm = MSXFAQ.NET
    default_keytab_name = /etc/squid/squiduser.keytab
    default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
    default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
    permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5

[realms]
    MSXFAQ.NET = {
        kdc = dc01.msxfaq.net
        kdc = dc02.msxfaq.net
        admin_server = dc01.msxfaq.net
        admin_server = dc02.msxfaq.net
        default_domain = msxfaq.net
    }

[domain_realm]
    .msxfaq.net = MSXFAQ.NET
    msxfaq.net = MSXFAQ.NET

Es müssen aber immer die Server oder Domains angegeben werden. Die erweiterten DNS-Einträge von Windows mit "_msdcs" werden nicht genutzt.

Sie können aber auch die DNS-Anfrage für KDC und REALMs aktivieren:

[libdefaults]
   dns_lookup_kdc = no
   dns_lookup_realm = no

Dann sucht das Linux wird auch Windows Clients nach den SRV-Records "_kerberos._udp.<domain>", "_kerberos._tcp.<domain>" und "_kpasswd._udp.<domain>", "_kpasswd._udp.<domain>". Diese Einträge können Sie recht schnell mit "nslookup -q=SRV _kpasswd._tcp.msxfaq.de" auf der Konsole abprüfen.

• Hostnames for KDCs
  https://web.mit.edu/kerberos/krb5-1.4/krb5-1.4.1/doc/krb5-admin/Hostnames-for-KDCs.html

Diese Vorarbeiten sind zwingend, damit Linux überhaupt weiß, wie es mit wem eine Kerberos-Kommunikation aufbauen kann.

• Configuring a Squid Server to authenticate against Kerberos
  https://wiki.squid-cache.org/ConfigExamples/Authenticate/Kerberos
  Hier wird zwar AES aktiviert aber RC4/DES nicht deaktiviert.

KTPASS und KEYTAB-Datei

Squid muss sich am AD natürlich legitimieren. Dazu nutzt er wie alle anderen "Memberserver" ein Computer/User-Konto und braucht die Zugangsdaten dazu. Diese werden auf Linux in einer KEYTAB-Datei hinterlegt. Es gibt zwei Optionen, die Keytab-Datei zu erzeugen:

• KTPASS auf Windows
  Der Windows Domain Admin legt im Active Directory ein User oder ComputerObjekt an und erstellt auf dem Domain Controller eine KEYTAB-Datei, die er zum Squid-Server bringt
• msktutil auf Linux
  Sie können aber auch direkt auf dem Linux-Host sich als "Domain Admin" an Windows anmelden und mit msktutil eine KEYTAB-Datei erzeugen.

KEYTAB mit Linux und Computerkonto

Der Weg über Linux erscheint mir für viele Anwender einfacher und beschreibe ich daher zuerst. Es sind im Prinzip nur einige Befehle, die Sie auf der WSL Kommandozeile passende angeben müssen. Zuerst installieren wir die Kerberos User Parts und MSKTUTIL.

#Installieren der Pakete. Kann je nach Distribution abweichen.
$ sudo apt install msktutil krb5-user

Dann melden wir uns mit KINIT einmal am DC an. Damit haben wir dann ein Ticket für den nächsten Schritt. zudem sehen wir hier gleich, dass dier kerb5.conf-Datei korrekt ist und lassen uns das Ticket anzeigen.

$ sudo kinit administrator@msxfaq.net
$ sudo klist

Wenn Sie hier schon Fehler bekommen, dann sollte Sie noch einmal ihre KRB5.CONF prüfen. Tippfehler, Gross/Kleinschrift, falsche IP-Adressen oder Verschlüsselungsverfahren sind die häufigsten Fehler. Im Extremfall müssten sie mit Wireshark die Anmeldung mit dem Filter "port 88" mitschneiden um den Fehler zu sehen. Hier ein Beispiel:

Zuerst versucht es der Client per UDP aber mit "KRB5KRB_ERR_RESPONSE_TOO_BIG schaltet er auf TCP. Der Client sendet dann ein AS-REQ über TCP und bekommt acuh ein AS-REP zurück. In den Details können Sie dann die verwendeten Cipher-Verfahren einsehen. Die erfolgreiche KDC-Verbindung bedeutet, dass die meisten Einstellungen in der krb5.conf schon mal korrekt sind.

Dennoch kann z.B. ein "kinit: KDC reply did not match expectations while getting initial credentials" zurückgegeben werden.

$ sudo msktutil -c -b "CN=COMPUTERS"  \
   -s HTTP/squidproxy.msxfaq.net  \
   -k /etc/squid/squidproxy.keytab  \
   --computer-name SQUIDPROXY  \
   --upn HTTP/squidproxy.msxfaq.net  \
   --server dc01.msxfaq.net  \
   --enctypes 24  \
   --verbose


-- init_password: Wiping the computer password structure
-- generate_new_password: Generating a new, random password for the computer account
-- generate_new_password: Characters read from /dev/urandom = 75
-- create_fake_krb5_conf: Created a fake krb5.conf file: /tmp/.msktkrb5.conf-vfWOVY
-- destroy_g_context: Destroying Kerberos Context
-- initialize_g_context: Creating Kerberos Context
-- finalize_exec: SAM Account Name is: SQUIDPROXY$
-- try_machine_password: Trying to authenticate for SQUIDPROXY$ with password
-- create_default_machine_password: Default machine password for SQUIDPROXY$ is squidproxy
-- try_machine_password: Error: krb5_get_init_creds_keytab failed (Preauthentication failed)
-- try_machine_password: Authentication with password failed
-- try_user_creds: Checking if default ticket cache has tickets
-- finalize_exec: Authenticated using method 5
-- LDAPConnection: Connecting to LDAP server: nawdc01.msxfaq.net
SASL/GSSAPI authentication started
SASL username: Admin@msxfaq.net
SASL SSF: 256
SASL data security layer installed.
-- ldap_get_base_dn: Determining default LDAP base: dc=MSXFAQ,dc=DE
-- ldap_check_account: Checking that a computer account for SQUIDPROXY$ exists
-- ldap_check_account: Checking computer account - found
-- ldap_check_account: Found userAccountControl = 0x1000
-- ldap_check_account: Found supportedEncryptionTypes = 28
-- ldap_check_account: Found dNSHostName = fc-desktop.msxfaq.net
-- ldap_check_account: Found Principal: HTTP/squidproxy.msxfaq.net
-- ldap_check_account: userPrincipal specified on command line
-- ldap_check_account_strings: Inspecting (and updating) computer account attributes
-- ldap_check_account_strings: Found userPrincipalName = HTTP/squidproxy.msxfaq.net@msxfaq.net
-- ldap_check_account_strings: userPrincipalName should be HTTP/squidproxy.msxfaq.net@msxfaq.net
-- ldap_check_account_strings: Nothing to do
-- ldap_set_supportedEncryptionTypes: No need to change msDs-supportedEncryptionTypes they are 28
-- ldap_set_userAccountControl_flag: Setting userAccountControl bit at 0x200000 to 0x0
-- ldap_set_userAccountControl_flag: userAccountControl not changed 0x1000
-- ldap_get_kvno: KVNO is 1
-- set_password: Attempting to reset computer's password
-- set_password: Try change password using user's ticket cache
-- ldap_get_pwdLastSet: pwdLastSet is 133469330611457545
-- set_password: Successfully set password
-- ldap_add_principal: Checking that adding principal host/fc-desktop.msxfaq.net to SQUIDPROXY$ won't cause a conflict
Error: Another computer account (CN=FC-DESKTOP,OU=Clients,DC=msxfaq,DC=de) has the principal host/fc-desktop.msxfaq.net



# Rechte auf Keytab-Darei anpassen, damit Squid diese lesen darf
$ sudo chgrp proxy /etc/squid/squidproxy.keytab
$ sudo chmod g+r /etc/squid/squidproxy.keytab

# Danach kann ich meine Tickets des Administrator im Cache wieder löschen
$ kdestroy

Über Active Directory User und  Computer sollten Sie dann das Computerobjekt sehen:

Alternativ geht auch einfach eine CMD-Shell mit SETSPN:

setspn -T * -F -Q */squidproxy.msxfaq.net
Die Gesamtstruktur "DC=msxfaq,DC=net" wird überprüft.
CN=SQUIDPROXY,CN=Computers,DC=msxfaq,DC=net
        HTTP/squidproxy.msxfaq.net

Bestehender SPN wurde gefunden.

Der SPN ist entsprechend gepflegt aber der UPN ist ungewöhnlich.

Wenn Sie Squid auf WSL nutzen, dann versucht MSKTUTIL auch den Windows Hostnamen als SPN zu addieren. Das klappt dann nicht, da der SPN ja nur einem Objekt vergeben werden kann.

KEYTAB mit Windows

Alternativ können Sie mit KTPASS.EXE, welches auf dem Domain Controller standardmäßig vorhanden ist, eine KEYTAB-Datei erstellen. (Zur Lesbarkeit umgebrochen)

# Anlegen der Datei mit dem ersten Namen
ktpass.exe 
   /princ HTTP/squidproxy.msxfaq.net@msxfaq.net 
   /mapuser squiduser@msxfaq.net
   /pass *
   -crypto AES256-SHA1
   +dumpsalt
   -setupn
   -setpass
   -ptype KRB5_NT_PRINCIPAL
   /out squiduser.keytab

# Erweitern der Datei mit einem zweiten SPN
ktpass.exe 
   /princ HTTP/squid@msxfaq.net
   /mapuser squiduser@msxfaq.net
   /pass *
   -crypto AES256-SHA1
   +dumpsalt
   -setupn
   -setpass
   -ptype KRB5_NT_PRINCIPAL
   /out squiduser.keytab
   /in squiduser.keytab

Durch den Eintrag "/pass *" werde ich bei der Generierung nach dem Kennwort gefragt.

Kontrollieren Sie beim Benutzerobjekt, dass der SPN addiert wurde:

Die so erzeugte KEYTAB Datei müssen Sie nun natürlich noch auf das Linux-System kopieren, z.B. indem Sie die Datei zuerst auf den Windows Host des WSL übertragen und dann mittels Mountpoint importieren:

# Paket fuer KLIST installieren
$ sudo apt install krb5-user

# keytab-Datei aus Mountpoint kopieren
$ sudo cp /mnt/c/users/fc/squiduser.keytab /etc/squid/squiduser.keytab

$ sudo chown root:proxy /etc/squid/squiduser.keytab
$ sudo chmod 640 squid /etc/squid/squiduser.keytab

• Kerberos SPN
• KTpass
  https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ktpass
• Copy files from Windows to your WSL instance
  https://megamorf.gitlab.io/2021/08/11/copy-files-from-windows-to-your-wsl-instance/

Ich nutze im weiteren Prozess das Computerkonto mit /etc/squid/squidproxy.keytab, welches ich über msmkutil auf dem Linux Subsystem direkt erstellt habe.

Keytab in Squid einbinden

Zuerst schaue ich mal in die KEYTAB-Datei und sie zeigt mehrere Schlüssel für die UPNs und den Computer aber auch welche für den Host selbst, die aber nicht funktionieren werden.

# Anzeige der Konfiguration
$ sudo klist -e -k /etc/squid/squidproxy.keytab

$ sudo klist -e -k /etc/squid/squidproxy.keytab
[sudo] password for fcarius:
Keytab name: FILE:/etc/squid/squidproxy.keytab
KVNO Principal
---- --------------------------------------------------------------------------
1 SQUIDPROXY$@MSXFAQ.NET (aes128-cts-hmac-sha1-96)
1 SQUIDPROXY$@MSXFAQ.NET (aes256-cts-hmac-sha1-96)
1 HTTP/squidproxy.msxfaq.net@MSXFAQ.NET (aes128-cts-hmac-sha1-96)
1 HTTP/squidproxy.msxfaq.net@MSXFAQ.NET (aes256-cts-hmac-sha1-96)
1 host/fc-desktop@MSXFAQ.NET (aes128-cts-hmac-sha1-96)
1 host/fc-desktop@MSXFAQ.NET (aes256-cts-hmac-sha1-96)

Eine zweite Prüfung ist die Überprüfung der Authentifizierung.

$ sudo kinit -V -k -t /etc/squid/squidproxy.keytab HTTP/squidproxy.msxfaq.net@MSXFAQ.NET
Using default cache: /tmp/krb5cc_0
Using principal: HTTP/squidproxy.msxfaq.net@MSXFAQ.NET
Using keytab: /etc/squid/squidproxy.keytab
Authenticated to Kerberos v5

Hier sollte kein Fehler zu sehen sein.

Während meiner Konfiguration und Tests habe nicht natürlich einige Fehler durchlaufen. Hier ein paar Beispiele:

Verschiedene Fehler sind denkbar:

• kinit: Client 'HTTP/squidproxy.msxfaq.net@msxfaq.net' not found in Kerberos database while getting initial credentials
  Hier sollten Sie mit Wireshark sehen, dass Linux auf den KDC zugreift.
  
  Der Fehler "KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN" ist ein Hinweis, dass der SPN im AD nicht gefunden wird.

Es gibt sicher noch viele andere Fehlerquellen, auf die ich noch nicht gestoßen bin

• KDC_ERR_C_PRINCIPAL_UNKNOWN Returned in S4U2Self Request
  https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/kdc-err-c-principal-unknown-s4u2self-request
• Broadcom: Error "KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN"
  https://knowledge.broadcom.com/external/article/169106/error-krb5kdc_err_s_principal_unknown.html

Squid für Kerberos einrichten

Der nächste Schritt ist wieder die Konfiguration der Authentifizierung in Squid. Wir brauchen wieder den Editor.

$ sudo nano /etc/squid/squid.conf

Hier muss ich drei Abschnitte addieren.

# Konfiguration von Kerberos mit de Helper und der Datei
auth_param negotiate program /usr/lib/squid/negotiate_kerberos_auth -k /etc/squid/squidproxy.keytab -s HTTP/squidproxy@msxfaq.net -s GSS_C_NO_NAME
auth_param negotiate children 10
auth_param negotiate keep_alive on

# Konfiguration einer ACL, damit ProxyAuth erforderlich ist. 
# Der Eintrag ist eventuell durch die BasicAuth schon da
acl authenticated proxy_auth REQUIRED

# Anlegen eienes Allow HTTP_Access-Eintrags vor einem DENY
http_access allow authenticated

Die erste Zeile definiert Negotiate und verweist auf den helper "negotiate_kerberos_auth", der Zugriff auf die Keytab-Datei braucht und welcher SPN genutzt wird. Eventuell müssen Sie je nach Linux-Distribution prüfen, mit welchem Benutzer der SQUID-Prozess läuft und ggfls. die Rechte auf die Datei mit CHOWN und CHMOD anpassen.

Ich habe am Anfang auch einfach mal den User "Proxy" als Besitzer angeben und mit CHMOD 777 alle die Leserechte gegeben. Wenn dann die Anmeldung geklappt hat, sollten Sie die Rechte aber wieder zurückbauen, denn die keytab ist schützenswert!

Natürlich ist auch nach dieser Änderung ein Neustart von Squid erforderlich.

sudo systemctl restart squid
systemctl status squid.service

DNS-Eintrag oder Host

Kerberos funktioniert nur mit einen DNS-Namen und nicht über die Angabe einer IP-Adresse als Proxy. Ich kann daher auf den Clients einen lokale Hosts-Datei pflegen aber bequemer ist natürlich ein DNS Eintrag:

squidproxy.mxsfaq.de   A  192.168.102.183

Achten Sie darauf, dass es sich um einen A-Record und nicht um einen CNAME handelt, denn beim CNAME wird der Name des WSL-Hosts aufgelöst und der hat ein anderes Kennwort, so dass die dafür ausgestellten Kerberos-Tickets nicht von Squid decodiert werden können.

• CNAME vs. A-Record
• Kerberos mit Browsern

Testen

Auch hier nutze ich erst mal wieder die PowerShell, bei der ich nun die integrierte ProxyAuthentifizierung aktiviere. Diesmal muss ich aber den den Namen und nicht die IP-Adresse des Proxy-Servers nutzen.

Invoke-Webrequest `
   -Uri http://www.msxfaq.net `
   -Proxy http://squidproxy.msxfaq.net:3128 `
   -ProxyUseDefaultCredentials 

Diese kurze Zeile prüft direkt und indirekt gleich mehrere Dinge:

• Erreichbarkeit des Proxy
  Der Weg von meinem Client zum ProxyServer kann aufgrund Namensauflösung, IP-Routing, Firewall oder einem falschen Port schon verhindert sein. Ein Fehlerbild sieht dann z.B.: so aus
  
• Fehler Bei Kerberos-Ticket
  Wenn die Anfrage vom Proxy beantwortet wird und ein 407-Fehler kommt dann würde ich zuerst einmal mit KLIST schauen, ob der Client sich überhaupt ein Kerberos-Ticket geholt hat
  
  Wenn hier kein Ticket zu sehen ist, dann liefert der Proxy entweder nicht mit, dass er Kerberos unterstützt oder der SPN ist doch nicht korrekt gesetzt worden. Was der Squid-Server zu ihnen sendet, können Sie mit Wireshark bei Verzicht auf HTTPS gut sehen. Leider liefert Invoke-WebRequest den Header des 407-Fehler nicht. Das geht aber dann mit dem folgenden Skript:

$url = "http://www.msxfaq.de"
$proxyUrl = "http://squid.msxfaq.de:3128"
 
$request = [System.Net.HttpWebRequest]::Create($url)
$request.Proxy = New-Object System.Net.WebProxy($proxyUrl, $false)
$request.Proxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials
 
try {
    $response = $request.GetResponse()
}
catch [System.Net.WebException] {
    $errorResponse = $_.Exception.Response
    $errorResponse.Headers.GetValues("Proxy-authenticate") 
}

Die Ausgabe liefert die Authentication-Header. Sollte hier kein "Negotiate" mit erscheinen, dann prüfen Sie die Konfiguration in der squid.config unter "auth_param negotiate ". Sollte hier aber "Negotiate" kommen und der Client entsprechend ein Ticket an den Squid senden, dann hat Squid wohl ein Problem bei der Auswertung des übermittelten Kerberos-Tickets

• Squid Logs
  Dann müssen wir auf Squid in die Logs schauen. Interessant ist hier dann die Datei /var/log/squid/cache.log. Die folgende Fehlermeldungen weist auf Berechtigungen oder Tippfehler bei der Keytab-Datei hin.
  
  Auch Rechte auf die Keytab können hinderlich sein, speziell bei Nutzung der Computer Keytab "ERROR: keytab file /etc/krb5.keytab is not accessible "
  
• Ansonsten können Sie in der squid.conf bei "auth_param negotiate program /usr/lib/squid/negotiate_kerberos_auth -k" noch den Wert "-d" für Debug addieren. Dann sehen sie noch mehr Einträge. Bei mir erscheinen dann alle RIDs im Ticket
  
  So sieht dann natürlich eine erfolgreiche Kerberos-Abfrage aus.

Weitere Fehlermeldungen reiche ich nach, wenn Sie auftreten.