Konfiguration der Authentifizierung an einem Windows Domaincontroller
per Kerberos Modul squid_kerb_auth.

Die aktuellen Windowsanmeldedaten werden zur Authentifizierung am Proxy durchgereicht (Pass-Through). Unterstützt wird das Pass-Through vom Firefox (ab 2.0) und Internet Explorer Version 7. Der Internet Explorer in der Version 6 unterstützt dies leider nicht. In dem Fall muss auf die LDAP-Authentifizierung zurückgegriffen werden.

In dem Beispiel wird von folgenden Daten ausgegangen:

Squid-Proxy OS: CentOS V. 5.2
Squid Version: squid-3.0.STABLE9-1.el5
Proxy Hostname: proxy.osnets.de
Windows Domäne: osnets.de
NT4 Domäne: OSNETS
Domaincontroller: dc01.osnets.de
AD Username: proxy.osnets.de

Das CentOS 5.2 Standard-RPM enthält nicht das Kerberos Modul (Stand 2009-02).
Alternativ dazu kann das Paket squid-30stable9-1el5i386.rpm installiert werden oder Squid manuell kompiliert werden.

Für die korrekte Funktion ist es wichtig, das alle Hostnames entsprechend im DNS angelegt sind und
die Server eine gemeinsame Zeitquelle verwenden.

Auf dem Domänencontroller wird als erstes der User proxy.osnets.de angelegt, über den dann später die Authentifizierung erfolgt. Der User muss lesend Zugriff auf das AD haben (Gruppe Domänenbenutzer)

Danach wird auf dem DC mit dem Programm ktpass die Kerberos Keytab-Datei erzeugt.
(Achtung! Case Sensitiv)

W2K3 SP1:

W2K3 R2 SP2:

Der Ptype funktioniert auch unter W2K3 R2 mit KRB5_NT_PRINCIPAL

Diese Datei wird nun auf dem Proxyserver in das Verzeichnis /etc/squid kopiert (User: squid, Modus 644)

Auf dem Proxyserver wird nun die Kerberos Konfigurationsdatei /etc/krb5.conf angepasst (Achtung! Case Sensitiv):

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = OSNETS.DE
dns_lookup_realm = true
dns_lookup_kdc = true

[domain_realm]
proxy.internal.iok.net = OSNETS.DE
[realms]
OSNETS.DE = {
admin_server = dc01.osnets.de
kdc = dc01.osnets.de
}

Danach wird die Umgebungsvariable für die Keytab definiert:

### SQUID Kerberos
export KRB5_KTNAME=/etc/squid/proxy.osnets.de.keytab

[root@proxy ~]# vi /etc/init.d/squid

### SQUID Kerberos
export KRB5_KTNAME=/etc/squid/proxy.osnets.de.keytab

Nun kann die Funktion der Kerberos-Authentifizierung auf dem Proxyserver überprüft werden:

OK, Kerberos funktioniert soweit.

Nun wird der Authentifizierungsmechanismus in der Squid-Konfiguration eingetragen:

### 1. Kerberos Auth gegen ActiveDirectory (PassThrough)
auth_param negotiate program /usr/lib/squid/squid_kerb_auth -d -s HTTP/proxy.osnets.de@OSNETS.DE
auth_param negotiate children 10
auth_param negotiate keep_alive on

### ACL alles
acl all src all

# ACL Proxy Authentifizierung
acl AD-AUTH proxy_auth REQUIRED

### Erlaube alles mit Authentifizierung
http_access allow AD-Auth

### Verbiete ansonsten alles
http_access deny all

Nun sollte unser Squid Proxy alle User am Active Directory per Kerberos authentifizieren.
Die Kerberos Authentifizierung kann auch noch mit einer LDAP-Authentifizierung erweitert, bzw. kombiniert werden. (z.B. Als Fallback-Auth für IE6 User). Zusätzlich können über die Gruppenmitgliedschaft der User Proxyberechtigungen erteilt werden.

Konfiguration der Authentifizierung an einem Windows Domaincontroller
per LDAP Modul squid_ldap_auth

Per LDAP-Auth werden die User gegen einen Windows Domänencontroller authentifiziert.
Pass-Through Authentifizierung funktioniert mit diesem Mechanismus leider nicht.
Zusätzlich können per LDAP Gruppenmitgliedschaften abgefragt werden und in entsprechenden
Regeln verwendet werden. In diesem Beispiel entscheidet die Mitgliedschaft in der Gruppe
GRP_PROXY_FULL darüber, ob ein User uneingeschräkten Zugriff über den Proxy bekommt, oder
auf gewisse definierte URL’s (und deren Subdomains) nicht zugreifen kann (*.ibey.de, *.qualle.de).

Squid-Proxy OS: CentOS V. 5.2
Squid Version: squid-3.0.STABLE9-1.el5
Proxy Hostname: proxy.osnets.de
Windows Domäne: osnets.de
Domaincontroller: dc01.osnets.de
AD Username: proxy.osnets.de
Bind-DN des LDAP-Users: cn=proxy.osnets.de, ou=Systemkonten, dc=osnets, dc=de
Container der Domänenbenutzer: ou=User, dc=osnets, dc=de
Container der ACL-Benutzergruppen: ou=Proxygroups,dc=osnets, dc=de
AD-Gruppe für vollen Proxy-Zugriff: GRP_PROXY_FULL

Das LDAP-Auth Modul ist auch in dem Standard CentOS RPM enthalten.
Allerdings verwenden wir zusätzlich Kerberos Auth, welches nicht enthalten ist.

Auf dem Domänencontroller wird als erstes die Sicherheitsgruppe GRP_PROXY_FULL angelegt.
Alle User die freiem Proxyzugang erhalten sollen, werden dann als Mitglied in die Gruppe aufgenommen.
Danach legen wir den User proxy.osnets.de an, über den dann später die Authentifizierung und Abfrage der Gruppen erfolgt. Der User muss lesend Zugriff auf das AD haben (Gruppe Domänenbenutzer). Der User befindet sich in der OU Systemkonten

Nun wird der Authentifizierungsmechanismus als 2. Mechanismus in der Squid-Konfiguration eingetragen:

### 1. Kerberos Auth gegen ActiveDirectory (PassThrough)
auth_param negotiate program /usr/lib/squid/squid_kerb_auth -d -s HTTP/proxy.osnets.de@OSNETS.DE
auth_param negotiate children 10
auth_param negotiate keep_alive on

### 2. LDAP-Authentifizierung gegen ActiveDirectory (Fall-Back)
auth_param basic program /usr/lib/squid/squid_ldap_auth -R -b “dc=osnets,dc=de” -D “cn=proxy.osnets.de, ou=Systemkonten, dc=osnets, dc=de” -w “KENNWORT” -f sAMAccountName=%s -h dc01.osnets.de
auth_param basic children 5
auth_param basic realm Proxy Authentifizierung
auth_param basic credentialsttl 5 minutes

Der Parameter credentialsttl gibt vor, wie lange Authentifizierungsdaten gecacht werden.

Zusätzlich werden nun die LDAP-Gruppenabfragen als Externe ACL definiert:

### AD-Gruppe GRP_PROXY_FULL
external_acl_type AD_GRP_PROXY_FULL %LOGIN /usr/lib/squid/squid_ldap_group -R -b “dc=osnets,dc=de” -D “cn=proxy.osnets.de, ou=Systemkonten, dc=osnets, dc=de” -w “KENNWORT” -f “(&(objectclass=person)(sAMAccountName=%v)(memberof=cn=GRP_PROXY_FULL,ou=Proxygroups,dc=osnets, dc=de))” -h dc01.osnets.de

Nun definieren wir noch die ACL’s und Regeln im Squid:

### ACL alles
acl all src all

### ACL Proxy Auth
acl AD-AUTH proxy_auth REQUIRED

### ACL Externe Gruppenabfrage AD_GRP_PROXY_FULL aus AD
acl ACL_AD_GRP_PROXY_FULL external AD_GRP_PROXY_FULL Proxygroups

### Eingeschraenkte Domains
acl Restricted_URLs dstdomain .ibey.de .qualle.de

### Verbiete Restricted_URL’s ohne Gruppenmitgliedschaft
http_access deny AD-Auth Restricted_URLs !ACL_AD_GRP_PROXY_FULL

### Erlaube Restricted_URL’s bei Gruppenmitgliedschaft
http_access allow AD-Auth Restricted_URLs ACL_AD_GRP_PROXY_FULL

### Erlaube den Rest mit Authentifizierung
http_access allow AD-Auth

### Verbiete ansonsten alles
http_access deny all

Wichtig ist, das in jeder Regel die ACL AD-Auth einbezogen wird, da ansonsten
keine Authentifizierung stattfindet.
Alle ACL’s einer Regel müssen zutreffen, damit die Aktion (allow oder deny) ausgeführt wird.

Registry Key für NTLM/Negotiate-Modus im IE:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\EnableNegotiotate = DWORD:0 to use NTLM, DWORD:1 for Kerberos.

Befehle:

Erhaltene Tickets ansehen:

Inhalt der Keytab auslesen:

Prüfen, ob der KDC korrekte Tickets sendet:

Links:
Squid ACL’s