Zammad: Einmalige Anmeldung

Erstellt am 20. Juni 2017  ·  30Kommentare  ·  Quelle: zammad/zammad

Infos:

  • Gebrauchte Zammad-Version: neueste
  • Verwendete Zammad-Installationsquelle: rpm
  • Betriebssystem: CentOS 7
  • Browser + Version: Firefox aktuell

Dies ist eine Frage zum Single Sign-On. Wir verwenden in unserem Unternehmen ein Microsoft Active Directory und die Anmeldung funktioniert problemlos mit ldap-sync.
Ich frage mich, ob SSO möglich wäre. Ich habe schon versucht, es mit nginx einzurichten, aber es funktioniert einfach nicht :-(

Gibt es eine einfache Möglichkeit, dies zu tun? Vielleicht hat einer von euch Zammad schon mit SSO eingerichtet? Wäre nett wenn jemand eine Anleitung oder ein paar Beispiele zur Umsetzung hat.

Vielen Dank im Voraus.

authentication documentation feature backlog prioritised by payment verified

Hilfreichster Kommentar

Single Sign-On ist dank @rlue endlich in develop gelandet ! Es wird in wenigen Wochen Teil der kommenden Version 3.2 sein. Bitte beachten Sie, dass die Aktualisierung von Zammad-Instanzen, die den develop Zweig verwenden, derzeit nicht funktioniert. Daran arbeiten wir. Sie können SSO jedoch in einem neuen Zammad-(Test-)System testen.

@MrGeneration können Sie bitte die Dokumentation erweitern, um die SSO-Konfiguration in Ihrem nächsten freien Zeitfenster abzudecken?

Alle 30 Kommentare

Hallo @jaeger13 ,

Dies ist natürlich möglich. Aber Sie müssen Apache httpd mit mod_auth_kerb verwenden, mit einer Konfiguration wie dieser:

<LocationMatch "/auth/sso">
  SSLRequireSSL
  AuthType Kerberos
  AuthName "Your Zammad"
  KrbMethodNegotiate On
  KrbMethodK5Passwd On
  KrbAuthRealms YOUR.REALM
  KrbLocalUserMapping on
  KrbServiceName HTTP/[email protected]
  Krb5KeyTab /etc/httpd/zammad.keytab
  require valid-user
</LocationMatch>

Abhängig vom gewählten uid-Attribut (ist sAMAccountName im obigen Beispiel) funktioniert es sofort.

Und Sie müssen Apache als Reverse-Proxy anstelle von nginx konfigurieren.

Solange das auth-Modul den authentifizierten Benutzernamen in der Umgebungsvariablen REMOTE_USER oder HTTP_REMOTE_USER zurückgibt, können andere Module wie auth_mellon usw. verwendet werden.

hth, Roy

Hey @rkaldung ,

Danke für deine schnelle Antwort. Ich werde es mit Apache und deiner Anleitung versuchen :-)
Obwohl ich mir wünschte, es gäbe eine Möglichkeit, dies mit nginx zu tun :-(

Danke!

Hallo @jaeger13 ,

Es gibt einen Weg mit nginx, aber im Moment ohne zu testen. @martini Deine zwei Cent dafür?

Hallo @rkaldung

Können Sie den Weg mit NGINX beschreiben? Das würde mich auch sehr interessieren. Danke.

Hallo @scimitar4444

@rkaldung bedeutet eine Implementierung auf Schienenebene wie https://github.com/jgraichen/omniauth-kerberos - dies muss jedoch zuerst in Zammad implementiert werden. 🤖

-Martin

@martini Es ist immer nur ein Commit entfernt 😜

Ich habe versucht, SSO mit Ihren Anweisungen zum Laufen zu bringen. Das Durchsuchen von http://myserver.mydom.local/auth/sso führt mich jedoch zurück zur Anmeldeseite. . . vermisse ich etwas?

Der Versuch, (Stanford) Webauth (und den LDAP-Benutzer) zu verwenden, führt zu demselben Fehler. Nach erfolgreicher Anmeldung in SSO erhalte ich die Zammad-Eingabeaufforderung zum Anmelden.
Verwendung: Ubuntu 16.04; Zammad 2.2.0; Apache, MariaDB; (REMOTE_USER wird von webauth gesetzt)

@rkaldung kennst du etw. Neu?

Habe eine Problemumgehung gefunden:

Problem: Das benötigte Modul in lib/sso/env.rb wird ohne die benötigte request.env von PUMA aufgerufen, daher ist 'REMOTE_USER' nicht verfügbar.

Problemumgehung:
'REMOTE_USER' aus request.env zu ENV in 'zammad/app/controllers/sessions_controller.rb' in der Funktion 'create_sso' hinzufügen

   # export required environment variables for sso
   ENV['REMOTE_USER'] = request.env['REMOTE_USER']
   ENV['HTTP_REMOTE_USER'] = request.env['HTTP_REMOTE_USER']

@martini könnte dies ein Problem mit einer neueren Version von PUMA sein?

EDIT: Sie müssen eine entsprechende Regel zum Setzen des Header-Felds in httpd.conf hinzufügen, damit es funktioniert:

RequestHeader merge REMOTE_USER %{REMOTE_USER}s

Bearbeiten 2018-01-08:
Mit dem Workaround von pikachuprof funktioniert jetzt alles. Es war ein Tippfehler in der /etc/krb5.conf-Konfiguration.

Infos:
Gebrauchte Zammad-Version: neueste
Verwendete Zammad-Installationsquelle: rpm
Betriebssystem: CentOS 7
Browser + Version: Firefox aktuell

Apache Server Config:
<VirtualHost *:443>
    ServerName ***
    ServerAdmin ***

    DocumentRoot "/opt/zammad/public"

    <IfModule !mod_auth_kerb.c>
        LoadModule auth_kerb_module /usr/lib64/httpd/modules/mod_auth_kerb.so
    </IfModule>

    ProxyRequests Off
    ProxyPreserveHost On

    <Proxy localhost:3000>
        Require local
    </Proxy>

    ProxyPass /assets !
    ProxyPass /favicon.ico !
    ProxyPass /robots.txt !
    ProxyPass /ws ws://localhost:6042/
    ProxyPass / http://localhost:3000/

    <Directory />
        Options FollowSymLinks
        AllowOverride None
    </Directory>

    <Directory "/opt/zammad/public">
        Options FollowSymLinks
        Require all granted
    </Directory>

    <Location "/auth/sso">
        Order allow,deny
        Allow from all

        AuthType Kerberos
        AuthName "Ticketsystem Kerberos Login"
        KrbServiceName HTTP
        KrbMethodNegotiate on
        KrbMethodK5Passwd on
        KrbLocalUserMapping off
        KrbSaveCredentials on

        Require valid-user

        # Environment specific: Path to the keytab and the realm
        Krb5Keytab /etc/kerberos.keytab
        KrbAuthRealm ***
    </Location>

    SSLEngine on
    SSLCertificateFile /etc/pki/tls/certs/***
    SSLCertificateKeyFile /etc/pki/tls/private/***

    ErrorLog "logs/***-error_log"
    CustomLog "logs/***-access_log" common
</VirtualHost>

Wenn ich https:// /auth/sso und "KrbLocalUserMapping on" öffne, zeigt mein Browser die folgende Fehlermeldung:interner ServerfehlerDer Server hat einen internen Fehler oder eine Fehlkonfiguration festgestellt und konnte Ihre Anfrage nicht abschließen.Bitte kontaktieren Sie den Serveradministrator unter admin@ , um ihn über den Zeitpunkt des Auftretens dieses Fehlers und die Aktionen, die Sie unmittelbar vor diesem Fehler durchgeführt haben, zu informieren.
Weitere Informationen zu diesem Fehler sind möglicherweise im Serverfehlerprotokoll verfügbar.

Wenn ich "KrbLocalUserMapping aus" setze, wird mein Browser auf https:// * /#login . umgeleitet

Ich versuche, "RequestHeader merge REMOTE_USER %{REMOTE_USER}s" einzustellen, aber es ändert sich nichts.

Hoffe jemand kann helfen!

Wir haben einen weiteren kleinen Workaround hinzugefügt:

RewriteEngine   On
RewriteCond     %{HTTP_COOKIE} !^.*zammad_session.*$
RewriteRule     ^/$ https://%{SERVER_NAME}/auth/sso [R,L]

Diese Zeilen in der Apache-config leiten '/' nur auf '/auth/sso' um, solange kein Zammad-Cookie gesetzt ist. Dies ermöglicht die Umleitung zur SSO-Anmeldeseite, ohne eine Endlosschleife zu erstellen, die zu einem 'internen Serverfehler' führt.

Ich kann es anscheinend nicht zum Laufen bringen. . . Apache-Protokolle zeigen meinen Benutzernamen für /auth/sso an, dann wird meine Anfrage an / umgeleitet und mein Benutzername ist weg. . . Vielleicht habe ich einen Fehler beim Bearbeiten der Funktion create_sso gemacht!? Kann mir jemand einen Hinweis geben?

@pikachuprof Ich hatte an einer Implementierung mit omniauth-kerberos gearbeitet .

Meine Implementierung erfordert jedoch, dass Sie sich jedes Mal anmelden, wenn Sie auf Zammad zugreifen möchten (natürlich mit Ihren Kerberos-Anmeldeinformationen), anstatt das "Kerberos-Ticket" zu verwenden, das bereits vom Computer des Benutzers generiert wird. (zB von kinit oder einem anderen "Kerberos-Ticketing-Client")

Ich hoffe, dass dies für die grundlegende Anmeldung mit Kerberos in Ordnung ist, um Hacker-Situationen zu vermeiden. 😊

Obwohl ich das Gefühl , dass für erweiterte Konfigurationen mit ‚einmalige Anmeldung / Authentifizierung‘ (z. B. unter Verwendung von kinit einmal und beglaubigen) und dann Sie ssh / login zu zammad / interne Websites / ftp alle Server ohne mehr Authentifizierung ( SPNEGO/GSSAPI) kann nur durchgeführt werden, indem der Frontend-Webserver (wie Apache) vollständig konfiguriert wird, was Sie gerade tun.

screen shot 2018-02-27 at 8 37 57 pm
screen shot 2018-02-27 at 8 48 00 pm

@muhammadn wir verwenden einen Kerberos-basierten Single-Sign-On-Dienst namens Stanford Webauth (mod_auth_webauth). Es erlaubt die Anmeldung per Passwort (im Browser) (und setzt ein Cookie mit einem Kerberos-Token für SSO), überträgt aber keine Benutzerpasswörter an den Dienst - nur an unser 'WebKDC'.

Die Authentifizierung muss in diesem Setup natürlich von Apache durchgeführt werden - aber Zammad sollte die REMOTE_USER-Variable verwenden, damit jeder dieser "Webserver-Auth"-Mechanismen funktioniert (oder etw. ähnlich?) und eine Methode zum Brechen bereitstellt aus der "Login-Schleife" heraus, ohne sich auf die Überprüfung auf ein Cookie zu verlassen, was ein wenig unzuverlässig erscheint.

@pikachuprof Ich habe meine Implementierung unter https://github.com/muhammadn/zammad/commit/7e8e01bff8226f2d74e80cbc307416db9bf2ac1d gepusht

Diese Implementierung ist offiziell kein Zammad-Feature, sondern nur zum Ausprobieren mit der omniauth-kerberos-Bibliothek. Sie müssen Apache nicht mit Kerberos-Unterstützung konfigurieren, da alles von Zammad verarbeitet wird (es ist eine Implementierung auf Rails-Ebene) und REMOTE_USER im Header oder sogar mod_auth_webauth nicht benötigt.

Alles, was Sie brauchen, ist, Ihre krb5.conf richtig einzurichten.

Beispiel:

[logging]
    default = FILE:/var/log/krb5.log

[libdefaults]
    default_realm = ZAMMAD.COM
    kdc_timesync = 1
    ccache_type = 4
    forwardable = true
    proxiable = true

[realms]
    ZAMMAD.COM = {
        kdc = kdc.zammad.com
        admin_server = kdc.zammad.com
        default_domain = zammad.com
    }

[domain_realm]
    .zammad.com = ZAMMAD.COM
    zammad.com = ZAMMAD.COM

Sie können alle diesbezüglichen Probleme stattdessen unter https://github.com/muhammadn/zammad/issues posten, da es sich nicht um eine offizielle Implementierung handelt.

Beachten Sie jedoch, dass Sie den Realm in Großbuchstaben eingeben müssen, um sich bei zammad anzumelden: zB: [email protected]

Gibt es eine Chance, dass wir vorhandene Kerberos-Tickets zur Authentifizierung verwenden können? Unsere Benutzer sind an eine so komfortable Lösung gewöhnt und ich habe keine Chance, zu zammad zu wechseln, bis ich echtes SSO zum Laufen bringe.

Gleiches Problem bei mir. Ich habe es geschafft, eine SSO-Verbindung von der Apache-Seite (die REMOTE_USER bevölkert) mit 2 Methoden (Kerberos & X509 SSL-Client-Zertifikat) herzustellen. Und meine Benutzerkonten sind mit dem Zammad-LDAP-Plugin gut gefüllt.

  • Als @EDVLeer, wenn ich /auth/sso sehe ich die Benutzeranmeldung im Apache-Log (so funktioniert es), aber ich komme wieder auf den Anmeldebildschirm zurück.
  • Ich habe den Hack versucht, in zammad/app/controllers/sessions_controller.rb schreiben ( @EDVLeer habe ich es entweder an einer falschen Stelle abgelegt, oder der Code hat sich nachträglich geändert und wir müssen das jetzt woanders hinstellen.
  • Ich habe den @pikachuprof- Hack
  • Ich habe jetzt keine Ideen mehr :D

So...

  • muss ich ein Plugin oder etwas in Zammad aktivieren, damit es funktioniert?
  • Ist es ein Fehler im Code? (Voraussichtlich ja, wenn wir den Quellcode ändern müssen)
  • Ist die URL /auth/sso in den neuesten Versionen noch gültig?
  • Oder gibt es ein offizielles Dokument zur Implementierung von SSO mit Zammad?

Anmerkungen:

Konfiguration für Kerberos

<Location "/auth/sso">
    Options FollowSymLinks
    AuthType        Kerberos
    AuthName        "My Name"
    KrbMethodNegotiate  On
    # 'Off' to force users having a valid kerberos ticket, and not prompting for a login/pass
    KrbMethodK5Passwd   Off
    KrbAuthRealms       MY-DOMAIN.FR
    Krb5KeyTab      /etc/krb5.keytab
    KrbLocalUserMapping On
    KrbServiceName      HTTP
    Require valid-user
</Location>

Konfiguration für X509 SSL-Zertifikat

Hinweis: Sie müssen Ihr öffentliches CA-Zertifikat (.crt) in Ihre Apache-CA-Bundle-Datei ( SSLCACertificateFile ) anhängen, damit Apache überprüfen kann, ob die Client-Zertifikate in Ordnung sind

# Let this before <Location> to get the certificate at the first connect, and avoid SSL renegotiation
# when we now the real url
SSLVerifyClient     require
<Location "/auth/sso">
    Options FollowSymLinks
    SSLRequireSSL
    SSLVerifyDepth      1    # Depend of your config. Can be higher
    Require expr %{SSL_CLIENT_I_DN_CN} in {'MY CA NAME'}
    SSLOptions      +StdEnvVars
    # Get the 'firstname.lastname' part of the corporate email, and populate REMOTE_USER
    RewriteEngine       On
    RewriteCond     %{SSL:SSL_CLIENT_S_DN_Email} ^(.+)@.+$
    RewriteRule     .* - [E=REMOTE_USER:%1]
    RequestHeader set REMOTE_USER %{REMOTE_USER}e
</Location>

Ich könnte das SSO-Problem "lösen", ich denke, es ist definitiv nicht der perfekte Weg, aber es funktioniert.

Meine Umgebung ist die neueste Zammad-Version (2.5) mit Apache2 2.4 mit Postgres. Nach der Konfiguration von SSO mit mod_auth_kerb muss ich folgende Dinge tun.

Ich habe LDAP konfiguriert, um unsere Mitarbeiter zu synchronisieren. Ich habe SAMACOUNTNAME dem Anmeldenamen zugeordnet. Mein Windows-Benutzername ist zum Beispiel schman. So konnte ich mich mit diesem Benutzernamen einloggen (nicht mit der E-Mail).

Danach habe ich die session_controller.rb bearbeitet und die folgende Zeile hinzugefügt (in Zeile 173)

ENV['HTTP_REMOTE_USER']=request.env['HTTP_REMOTE_USER']

Zammad kennt also den HTTP_REMOTE_USER. Danach funktioniert die Anmeldung nicht. Denn der Wert von HTTP_REMOTE_USER ist jetzt [email protected]. Um das zu beheben, füge ich meiner vHost-Konfiguration die folgende Zeile hinzu.

RequestHeader edit REMOTE_USER "@DOMAIN.AT" ""

Nach dem Neustart (Apache2 und Zammad) konnte ich mich vis SSO mit http://zammad.domain.at/auth/sso einloggen

Wenn jemand Deutsch spricht, habe ich einen kleinen Beitrag auf meinem Blog geschrieben .

@schmanat wie hast du die "login-loop" gelöst oder lässt du den Benutzer die "/auth/sso" URL verwenden?

Im Moment erhalten die Benutzer die /auth/sso-URL.

Aber das ist das nächste, worauf ich eingehen möchte. Hat die Problemumgehung Ihrer Antwort ein paar Kommentare oben (RewriteRule) nicht funktioniert?

Ja, hat es, aber es ist ziemlich unzuverlässig.

Vielen Dank an alle für Ihre Arbeit daran und für die Dokumentation, was Sie getan haben. Leider bin ich ratlos. Wie andere erfahren haben, werde ich auch auf die Anmeldeseite umgeleitet, nachdem ich den Endpunkt "auth/sso" erreicht habe. Hier ist alles, was ich getan habe:

  • installiertes Zammad auf Debian 9 (Stretch)
  • konfigurierte LDAP-Integration (zugeordnet samaccountname -> login )
  • bestätigt, dass Sie sich mit AD-Benutzername/Passwort anmelden können
  • erstelltes Dienstkonto in AD (einfach zammad )
  • erstellte Schlüsseltabelle, die dem zammad Dienstkonto zugeordnet ist
  • konfigurierter Kerberos-Client/-Realm (in /etc/krb5.conf )
  • verifizierte Kerberos-Umgebung mit kinit
  • verifiziert, dass Keytab funktioniert (kann TGT von KDC abrufen)
  • konfigurierter Apache2 vhost (wie von cohausz erklärt)
  • geändert sessions_controller.rb (wie von pikachuprof erklärt)
  • Header-Regel zur vhost-Konfiguration hinzugefügt (wie von pikachuprof erklärt)

Ich habe auch die von schmant angebotenen Lösungen ausprobiert, aber nichts scheint zu helfen.

Unten sind meine Apache2-Protokolle. Wie Sie sehen, wird der Benutzer durchgereicht... Wie kann ich überprüfen, ob die Umgebungsvariablen REMOTE_USER / HTTP_REMOTE_USER richtig gesetzt sind? Gibt es noch andere Schritte zur Fehlerbehebung, die ich ausprobieren kann?

zammad.example.com:443 10.1.4.197 - - [09/Aug/2018:09:39:23 -0500] "GET /auth/sso HTTP/1.1" 401 855 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36"
zammad.example.com:443 10.1.4.197 - [email protected] [09/Aug/2018:09:39:23 -0500] "GET /auth/sso HTTP/1.1" 302 969 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36"
zammad.example.com:443 10.1.4.197 - - [09/Aug/2018:09:39:23 -0500] "GET / HTTP/1.1" 200 1757 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36"
zammad.example.com:443 10.1.4.197 - - [09/Aug/2018:09:39:23 -0500] "POST /api/v1/signshow HTTP/1.1" 200 15874 "https://zammad.example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36"
zammad.example.com:443 10.1.4.197 - - [09/Aug/2018:09:39:24 -0500] "GET /api/v1/translations/lang/en-us?_=1533825563736 HTTP/1.1" 200 720 "https://zammad.example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36"
zammad.example.com:443 10.1.4.197 - - [09/Aug/2018:09:39:24 -0500] "GET /assets/images/fed16b83d2e87ea36cea961d6d8a2101.png HTTP/1.1" 304 210 "https://zammad.example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36" 

Hallo,

Ich habe den gleichen Fehler wie @jeremyj563.

Gibt es eine Lösung, um sich mit SSO anzumelden?

Danke für die Antwort

Ich interessiere mich auch für SSO.

Es wäre eine Option, Azure AD für SSO zu implementieren.

Wir sind auch sehr interessiert. Ich teste die App gerade im Univention Test App Center und bin sehr gespannt.

Entschuldigung, dass ich Sie belästige: Funktioniert nicht auf univention, da Docker Compose nginx verwendet.

ACHTUNG : Wir müssen Sie warnen, die SSO-Implementierung auf jede Weise zu verwenden, die in dieser oder anderen Ausgaben beschrieben wird. Die hier bereitgestellten Änderungen enthalten eine schwerwiegende Sicherheitslücke. Diese Sicherheitsanfälligkeit wird über SSO erstellte Sitzungen für nicht authentifizierte Benutzer beibehalten. Dies bedeutet, dass nicht authentifizierte Benutzer die zuvor erstellte SSO-Sitzung für einen Benutzer (im Zammad-Kontext) übernehmen können.

Wir empfehlen dringend, SSO zu deaktivieren, bis dieses Problem behoben ist.

Die gute Nachricht ist jedoch, dass wir mit der Arbeit an der offiziellen SSO-Implementierung begonnen haben.

Single Sign-On ist dank @rlue endlich in develop gelandet ! Es wird in wenigen Wochen Teil der kommenden Version 3.2 sein. Bitte beachten Sie, dass die Aktualisierung von Zammad-Instanzen, die den develop Zweig verwenden, derzeit nicht funktioniert. Daran arbeiten wir. Sie können SSO jedoch in einem neuen Zammad-(Test-)System testen.

@MrGeneration können Sie bitte die Dokumentation erweitern, um die SSO-Konfiguration in Ihrem nächsten freien Zeitfenster abzudecken?

Es gab eine Nachverfolgung. Bitte beachten Sie das obige Commit.

Leider stoßen wir bei der Erstellung der Dokumentation auf einige Hindernisse 😞 Über einen Beitrag in Form eines Pull Requests an die https://github.com/zammad/zammad-admin-documentation würde ich mich sehr freuen.
Der API-Endpunkt ist /auth/sso . Wir erwarten, dass eines der folgenden Elemente vorhanden ist und das login Attribut eines Benutzers enthält:

  • ENV REMOTE_USER
  • ENV HTTP_REMOTE_USER
  • Kopfzeile X-Forwarded-User

Lassen Sie es mich wissen, wenn Sie Fragen haben. Ich beantworte sie gerne.

Schließt jetzt.

Der Vollständigkeit halber: Die SSO-Dokumentation wird derzeit einer QA unterzogen.
https://github.com/zammad/zammad-documentation/pull/147

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen