Univention Bugzilla – Bug 24277
Kerberos-Authentifizierung bei Windows-Clients, die gegen Samba 4 gejoint wurden
Last modified: 2012-03-04 14:33:55 CET
Die Kerberos-Authentifizierung funktioniert aktuell noch nicht. Folgende Schritte sind nötig, um sie prinzipiell einzurichten (der Fehler folgt unten( 1. Hinzufügen eines Service Principals anhand von https://hutten.knut.univention.de/mediawiki/index.php/UCS-3.0-Samba4#Kerberos_servicePrincipalName_hinzuf.C3.BCgen und der angehängten proxy.ldb 2. Die Keytab muss für den Squid-Prozess lesbar sein: chown proxy: /var/lib/samba/private/proxy.keytab 3. Einbindung des Kerberos-Auth-Helpers in die Squid-Konfiguration: auth_param negotiate program /usr/lib/squid3/squid_kerb_auth auth_param negotiate children 10 auth_param negotiate keep_alive on 4. Die zusätzliche Keytab muss von Squid eingelesen werden. Dazu muss folgendes in das Init-Skript integriert werden: KRB5_KTNAME=/var/lib/samba/private/proxy.keytab export KRB5_KTNAME 5. Im zugreifenden Client muss zwingend der FQDN des Proxy-Servers eingetragen werden, wenn da eine IP dirn steht, wird ntlm versucht. Wenn NTLM verwendet wird, steht in der cache.log eine Zeile ala "Error validating user via Negotiate. Error returned 'BH received type 1 NTLM token'" Man kann die Authentifizierung auch direkt testen, ohne über den Squid zu gehen: - Anmelden als User - Aufruf von usr/lib/squid3/squid_kerb_auth_test fqdn-vom-proxy - Es gibt dann eine Zeile ala Token: YIIEzgYGKwYBBQUCoIIEwjCCBL6gHzAdBgkqhkiG9xIBAgIGBSsFAQUCBgkqhkiC9xIBAgKiggSZBIIElWCCBJEGCSqGSIb3EgECAgEAboIEgDCCBHygAwIBBaEDAgEOogcDBQAAAAAAo4IDrGGCA6gwggOkoAMCAQWhDBsKU1FVSUQ0LkpNTaIkMCKgAwIBA6EbMBkbBEhUVFAbEXNhbWJhNC5zcXVpZDQuam1to4IDZzCCA2OgAwIBF6EDAgEBooIDVQSCA1EBxu8Y0aXb0bfcVqya4F5NUcvfS5sHWWErdTwKU6GEMwUuqWwYN7FQ8LeN933LxOEfRBuoeAxGraDU4eIAIhumKe3+HOR9uL8fhDVe2lyrlFQT5McoiB02nWFPdu5hPoj+HHJhfFVOK9LjA/fxCMaOv4hqLpNLqfQePnbqfGtS4Gm1ethOoz1XGz4uqkTG730/pG/Gj0fXq4eQEXC9gYH/0dnjM2FPcKeAzKj9h7KnpBPrIfMkjs8I2GbUrEECe0fLAzJiDODYeKAUws89av63kR9DAPb+NXHaOOeH/Dvbw6/298O1gI9gtHs4XshNnicVwNlaHzWD5Szk8UwxoDH2wVpPMCuUWoC9L9qNnOOooc3BvQZOQedWLGMwh9NakDOnAvBqHpVs1HDGRCc/wJOV1lDsLWIEGaJPFywM3uUYIG0lpkyIlUhz1B5t9o/R4AMnH7aO0tBoqmyvdjsJgtDHMxdvQHAN0+lcOo8xDaT5kfS/ZP5eAA/zJkNs/NibvIGmfTrUvYTHBsLOBJkz/PN4ATltlSaVqdPs27onypBPZbjEHHFvBN69+Dx5euaorjoSpyGZQHgrEbH92jfystMJ+z1q7CjsLhoux2tVrK+yT4fJz4HYWz5n6Ka496y7q9U7Jmnw0qWFOybl8duCYi7qO6zPYzUvMvMNTCN64uOSUW1ttt8mh+l925VmTGbGVdTYfCh6OpT0Mxuk4LR/Izdiuxe59FvpxQSSXIjo5lAoj2m51OVUccyRsRbTJRuSsf4eDw75HR1OJvp3Uf4xIY5SZ0OpNCDGpFGp1ZAl+zCe1tmPNDUjkrAJhIydJRkfNP+DbAOkTcYuDebIGNI2jcTb4HeEtI1dRuXG3lLKFi7kE56/QH1gNWizW5mZhm5ZuPWfnyHN09cjNaBKX6WZ4tETCWwqzLM1xuGamdjw6ccLuLJpE34QJUaKnNwXyo9fOcQ5AOYP1OXLKV/3KhyHNpRg4XqAn1C2yo0AUO7TZTPxmjjKJymW8+W2BrH5i5F2MUMbAT51n9XunKEwn2Lqc/1RA6BTNAK7yi2KiUHNrmPgNR49uetRpYAzGRLakirIn7sLytDGiHAUyis8uJE25nY4/bFGwOH9Tr/Wf44MDjLb15GkgbYwgbOgAwIBF6KBqwSBqI7OtVy5fCRsEHG+I3DRp7rpDMvoqGxCEd2poA+RaxE2NG/048pQn4AgWrI/e6jW+kO3IZ6wadCCyQl8uUw2JjiPXl2+wQXtnSKB7T5HjjCKKRa6v1ICm4cn9YHHvz4G0BhoOInuUMbqHcFEnkIOEQSN00WOObApBbVHqYUh0DgJEvP2awMne3HBUIL8YRh4KdlmMVbdY204S9SHWcBP4zkTK53FygX9FQ= - Aufruf von /usr/lib/squid3/squid_kerb_auth -d Hier gibt man dann "YR " und das obige Token ein. Der Fehler, der auftritt ist squid_kerb_auth: ERROR: gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information. Ich habe das Auth-Helper-Modul testweise gepatcht, so dass der Rückgabewert minor_code ausgegeben wird: Der Fehlercode ist 100001. Dazu findet sich im Netz außer einem Posting auf der Kerberos-Liste ohne Replies nichts: http://mailman.mit.edu/pipermail/kerberos/2011-May/017186.html
univention-squid ist jetzt für ucs3.0-1 so angepasst, das auf Samba4 DCs ein Service Prinzipal HTTP/$fqdn angelegt wird. Dies geschieht in einem zweiten Joinscript, das nach univention-samba4 läuft. Per UCR-Variable squid/krb5auth=yes lässt sich dann die Kerberos-Authentifikation in der squid3/squid.conf aktivieren. Der SPN HTTP/$domainname wird aktuell nicht angelegt um Kollisionen zu vermeiden. Im Falle von DNS ist das laut Upstream-Aussage auch nicht notwendig. Auf UCS Samba Memberservern in einer Samba4 Domäne funktioniert das so noch nicht, da die aktuell im Joinscript verwendete Methode zum Anlegen des SPN und zum extrahieren der Keytab lokale Samba-Datenbanken veraussetzt. Entweder man verwendet dazu eine ähnlichen Ansatz wie in univention-heimdal, indem man die keytab z.B. auf dem DC generieren lässt, der den S4 Connector betreibt, und sie dann per Listener auf den Memberserver kopiert oder man findet einen Weg, die keytab mit python-univention-heimdal direkt auf dem Memberserver aus seinen krb5keys zu generieren, die er ja aus dem LDAP auslesen kann.
Auf UCS Samba Memberservern in einer Samba4 Domäne funktioniert das jetzt ebenfalls. Dort wird der Account für den Service Prinzipal per UDM im Joinscript angelegt statt per samba-tool und anschliessend per univention-create-keytab Skript (aus univention-heimdal-common) eine Keytab direkt auf dem Memberserver erzeugt.
Das funktionierte in den bisherigen Tests gut, auch mit Firefox. Zum Test: 1. Serverseitige Konfiguration: univention-run-joinscripts # Der Service Account muss angelegt werden ucr set squid/krb5auth=yes /etc/init.d/squid3 restart 2. Im zugreifenden Client muss zwingend der FQDN des Proxy-Servers eingetragen werden, wenn da eine IP drin steht, wird ntlm versucht. Falls diese Anpassungen noch aus ucs3.0-1 herausgenommen wird, muss der Changelog-Eintrag auch entfernt werden: \item Kerberos authentication against Squid proxies run in Samba 4 domains can be enabled by setting \ucsUCRV{squid/krb5auth} to \emph{yes}. It is advisable to run \ucsName{univention-run-join-scripts} once after upgrade to ucs3.0-1, to ensure that the necessary HTTP proxy service account is created (\ucsBug{24277}).
Die Kerberos-Authentifzierung funktioniert: Ich habe einen Win7-Client gegen Samba 4 gejoint und die Kerberos-Authentifizierung wie beschrieben eingerichtet. Damit konnte nach einem Login mit dem dann generierten Ticket auf den Proxy zugreifen und der Benutzer wurde in der access.log zugeordnet: 1324638683.530 56 10.200.3.50 TCP_REFRESH_UNMODIFIED/200 89375 GET http://www.univention.de/uploads/tx_imagecycle/ucs_evolution2012_de.jpg jmm@QAI386.JMM DIRECT/88.198.15.85 image/jpeg 1324638683.539 42 10.200.3.50 TCP_REFRESH_UNMODIFIED/200 43892 GET http://www.univention.de/uploads/tx_imagecycle/ucs_neu-3-0_2012_de.jpg jmm@QAI386.JMM DIRECT/88.198.15.85 image/jpeg Getestet mit IE 8, Firefox 10 und Chrome 17. Changelog in Ordnung.
UCS 3.0-1 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"