Zammad: Authentification unique

Créé le 20 juin 2017  ·  30Commentaires  ·  Source: zammad/zammad

Informations :

  • Version Zammad d'occasion : la dernière
  • Source d'installation Zammad utilisée : rpm
  • Système d'exploitation : CentOS 7
  • Navigateur + version : Firefox dernière version

Il s'agit d'une question concernant l'authentification unique. Nous utilisons un Microsoft Active Directory dans notre entreprise et la connexion fonctionne bien avec ldap-sync.
Je me demande si SSO serait possible. J'ai déjà essayé de le configurer à l'aide de nginx, mais cela ne fonctionnera tout simplement pas :-(

Y a-t-il un moyen facile de le faire? Peut-être que l'un d'entre vous a déjà configuré Zammad avec SSO ? Ce serait bien si quelqu'un avait une instruction ou des exemples sur la façon de l'implémenter.

Merci d'avance.

authentication documentation feature backlog prioritised by payment verified

Commentaire le plus utile

L'authentification unique est enfin arrivée dans develop grâce à @rlue ! Il fera partie de la prochaine version 3.2 dans quelques semaines. Veuillez noter que la mise à jour des instances Zammad utilisant la branche develop est actuellement interrompue. Nous travaillons là-dessus. Cependant, vous pouvez tester l'authentification unique dans un nouveau système (test) Zammad.

@MrGeneration pouvez-vous s'il vous plaît étendre la documentation pour couvrir la configuration SSO dans votre prochain créneau horaire libre ?

Tous les 30 commentaires

Salut @jaeger13 ,

C'est possible bien sûr. Mais vous devez utiliser Apache httpd avec mod_auth_kerb, avec une configuration comme celle-ci :

<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>

Selon l'attribut uid choisi (ist sAMAccountName dans l'exemple ci-dessus), cela fonctionnera immédiatement.

Et vous devez configurer Apache comme proxy inverse au lieu de nginx.

Tant que le module auth renvoie le nom d'utilisateur authentifié dans la variable d'environnement REMOTE_USER ou HTTP_REMOTE_USER, il est possible d'utiliser d'autres modules comme auth_mellon etc.

hth, Roy

Salut @rkaldung ,

merci pour votre réponse rapide. Je vais l'essayer avec Apache et vos instructions :-)
Bien que j'aurais souhaité qu'il y ait un moyen de le faire avec nginx :-(

Merci!

Salut @jaeger13 ,

Il existe un moyen avec nginx, mais sans test pour le moment. @martini Vos deux cents là-dessus?

Salut @rkaldung

Pouvez-vous décrire le chemin avec NGINX ? Cela m'intéresserait aussi beaucoup. Merci.

Salut @scimitar4444

@rkaldung signifie une implémentation au niveau des rails comme https://github.com/jgraichen/omniauth-kerberos - mais cela doit d'abord être implémenté dans Zammad. ??

-Martin

@martini Il

J'ai essayé de faire fonctionner SSO en utilisant vos instructions. Cependant, la navigation sur http://myserver.mydom.local/auth/sso me ramène à la page de connexion. . . est-ce que je rate quelque chose ?

Essayer d'utiliser (Stanford) Webauth (et l'utilisateur ldap) entraîne la même erreur, après une connexion réussie dans SSO, je reçois l'invite zammad pour me connecter.
Utilisation : Ubuntu 16.04 ; Zammad 2.2.0 ; Apache, MariaDB ; (REMOTE_USER est défini par webauth)

@rkaldung savez-vous

J'ai trouvé une solution de contournement :

Problème : le module nécessaire dans lib/sso/env.rb est appelé sans le request.env nécessaire de PUMA, donc 'REMOTE_USER' n'est pas disponible.

Solution de contournement:
Ajoutez 'REMOTE_USER' de request.env à ENV dans 'zammad/app/controllers/sessions_controller.rb' dans la fonction 'create_sso'

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

@martini cela pourrait-il être un problème avec une version plus récente de PUMA ?

EDIT : vous devez ajouter une règle correspondante pour définir le champ d'en-tête dans httpd.conf pour que cela fonctionne :

RequestHeader merge REMOTE_USER %{REMOTE_USER}s

Modifier 2018-01-08 :
Tout fonctionne maintenant avec la solution de contournement de pikachuprof. C'était une faute de frappe dans la configuration /etc/krb5.conf.

Informations :
Version Zammad d'occasion : la dernière
Source d'installation Zammad utilisée : rpm
Système d'exploitation : CentOS 7
Navigateur + version : Firefox dernière version

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>

Lorsque j'ouvre https:// /auth/sso et "KrbLocalUserMapping on", mon navigateur affiche l'erreur suivante :Erreur interne du serveurLe serveur a rencontré une erreur interne ou une mauvaise configuration et n'a pas pu répondre à votre demande.Veuillez contacter l'administrateur du serveur à l'adresse admin@ pour l'informer de l'heure à laquelle cette erreur s'est produite et des actions que vous avez effectuées juste avant cette erreur.
Plus d'informations sur cette erreur peuvent être disponibles dans le journal des erreurs du serveur.

Si je désactive "KrbLocalUserMapping", mon navigateur est redirigé vers https:// * /#login

J'essaie de définir "RequestHeader merge REMOTE_USER %{REMOTE_USER}s" mais rien ne change.

J'espère que quelqu'un pourra aider !

Nous avons ajouté une autre petite solution de contournement :

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

Ces lignes dans Apache-config redirigent '/' vers '/auth/sso' uniquement tant qu'aucun cookie zammad n'est défini. Cela permet la redirection vers la page de connexion SSO sans créer une boucle sans fin entraînant une « erreur de serveur interne ».

Je n'arrive pas à le faire fonctionner. . . les journaux apache affichent mon nom d'utilisateur pour /auth/sso, puis ma demande est redirigée vers / et mon nom d'utilisateur a disparu. . . peut-être ai-je fait une erreur en éditant la fonction create_sso !? Quelqu'un peut-il me donner un indice ?

@pikachuprof J'avais travaillé sur une implémentation utilisant omniauth-kerberos .

Cependant, mon implémentation nécessite que vous vous connectiez à chaque fois que vous souhaitez accéder à Zammad (en utilisant vos identifiants Kerberos bien sûr) au lieu d'utiliser le "ticket kerberos" qui est déjà généré par la machine de l'utilisateur. (par exemple à partir de kinit ou de tout autre "client de billetterie Kerberos")

J'espère que cela convient pour la connexion de base à l'aide de Kerberos afin d'éviter les situations de piratage. ??

Bien que je pense que pour les configurations avancées avec « connexion/authentification unique » (par exemple, utiliser kinit une fois et vous authentifier), puis vous ssh/connectez-vous à zammad/sites internes/ftp tous les serveurs sans plus vous authentifier ( SPNEGO/GSSAPI) ne peut être fait qu'en configurant entièrement le serveur Web frontal (comme Apache) que vous faites en ce moment.

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

@muhammadn, nous utilisons un service d'

L'authentification doit être effectuée par Apache dans cette configuration bien sûr - mais Zammad devrait utiliser la variable REMOTE_USER pour permettre à l'un de ces mécanismes "webserver-auth" de fonctionner (ou quelque chose de similaire ?), ainsi que fournir une méthode pour casser hors de la "boucle de connexion" sans compter sur la recherche d'un cookie, ce qui semble un peu peu fiable.

@pikachuprof J'ai poussé mon implémentation sur https://github.com/muhammadn/zammad/commit/7e8e01bff8226f2d74e80cbc307416db9bf2ac1d

Cette implémentation n'est pas officiellement une fonctionnalité de zammad mais juste pour vous d'essayer d'utiliser la bibliothèque omniauth-kerberos. Vous n'aurez pas besoin de configurer Apache avec le support de Kerberos car tout sera géré par Zammad (c'est une implémentation au niveau des rails) et n'aura pas besoin de REMOTE_USER dans l'en-tête ou même de mod_auth_webauth.

Tout ce dont vous avez besoin est d'avoir correctement configuré votre krb5.conf.

Exemple:

[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

Vous pouvez publier tous les problèmes à ce sujet sur https://github.com/muhammadn/zammad/issues à la place car ce n'est pas une mise en œuvre officielle.

Cependant, notez que pour vous connecter avec zammad, vous devez avoir le domaine en majuscule : par exemple : [email protected]

Une chance que nous puissions utiliser les tickets Kerberos existants pour l'authentification ? Nos utilisateurs sont habitués à une solution aussi confortable et je n'ai aucune chance de passer à zammad tant que je n'ai pas réussi à faire fonctionner le SSO.

Même problème pour moi. J'ai réussi à établir une connexion SSO du côté Apache (qui peuplent REMOTE_USER ) avec 2 méthodes (Kerberos & X509 SSL Client certificate). Et mes comptes utilisateurs sont bien renseignés, avec le plugin LDAP Zammad.

  • En tant que @EDVLeer, lorsque j'atteins /auth/sso je vois la connexion de l'utilisateur dans le journal Apache (donc cela fonctionne), mais je reviens à nouveau sur l'écran de connexion.
  • J'ai essayé le hack d'écrire en zammad/app/controllers/sessions_controller.rb ( @pikachuprof hack), mais en tant que @EDVLeer , soit je l'ai mis au mauvais endroit, soit le code a changé par la suite et il faut le mettre ailleurs maintenant.
  • J'ai essayé le hack @pikachuprof de ne pas rediriger vers / s'il y a un cookie, sans succès
  • Je suis maintenant à court d'idées :D

Alors...

  • dois-je activer un plugin ou quelque chose dans Zammad pour le faire fonctionner ?
  • Est-ce un bug dans le code ? (Peut-être oui, si nous devons changer le code source)
  • L'url /auth/sso toujours valide dans les dernières versions ?
  • Ou existe-t-il un document officiel expliquant comment implémenter l'authentification unique avec Zammad ?

Remarques:

Configuration pour 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>

Configuration pour le certificat SSL X509

Remarque : vous devez ajouter votre certificat public CA (.crt) dans votre fichier Apache 'CA Bundle' ( SSLCACertificateFile ) afin qu'Apache puisse vérifier si les certificats clients sont OK

# 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>

Je pourrais "résoudre" le problème SSO, je pense que ce n'est certainement pas le moyen parfait mais cela fonctionne.

Mon environnement est la dernière version de zammad (2.5) avec Apache2 2.4 avec Postgres. Après la configuration de SSO avec mod_auth_kerb, je dois faire les choses suivantes.

J'ai configuré LDAP pour synchroniser nos employés. J'ai mappé le SAMACOUNTNAME au nom de connexion. Par exemple, mon nom d'utilisateur Windows est schman. J'ai donc pu me connecter avec ce nom d'utilisateur (pas avec l'e-mail).

Après cela, j'ai modifié le fichier sessions_controller.rb et j'ai ajouté la ligne suivante (à la ligne 173)

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

donc Zammad connaît le HTTP_REMOTE_USER. Après cela, la connexion ne fonctionne pas. Parce que la valeur de HTTP_REMOTE_USER est maintenant [email protected]. Pour résoudre ce problème, j'ajoute la ligne suivante à ma configuration vHost.

RequestHeader edit REMOTE_USER "@DOMAIN.AT" ""

Après le redémarrage (Apache2 et Zammad), je pouvais me connecter via SSO avec http://zammad.domain.at/auth/sso

Si quelqu'un parle allemand, j'ai écrit un petit article sur mon blog .

@schmanat comment avez-vous résolu la "boucle de connexion" ou laissez-vous l'utilisateur utiliser l'URL "/auth/sso" ?

Pour l'instant, les utilisateurs obtiennent l'url /auth/sso.

Mais c'est la prochaine chose que j'aimerais creuser. La solution de contournement de votre réponse n'a pas fonctionné quelques commentaires ci-dessus (RewriteRule) ?

Oui, mais c'est assez peu fiable.

Merci à tous pour votre travail sur ce sujet et pour avoir documenté ce que vous avez fait. Malheureusement, je suis perdu. Comme d'autres l'ont expérimenté, je suis moi aussi redirigé vers la page de connexion après avoir atteint le point de terminaison "auth/sso". Voici tout ce que j'ai fait :

  • installé Zammad sur Debian 9 (stretch)
  • intégration LDAP configurée (mappé samaccountname -> login )
  • confirmé capable de se connecter avec le nom d'utilisateur/mot de passe AD
  • compte de service créé dans AD (simplement appelé zammad )
  • keytab créé mappé au compte de service zammad
  • client/domaine kerberos configuré (en /etc/krb5.conf )
  • environnement Kerberos vérifié avec kinit
  • vérifié que keytab fonctionne (capable d'obtenir le TGT de KDC)
  • vhost Apache2 configuré (comme expliqué par cohausz)
  • modifié sessions_controller.rb (comme expliqué par pikachuprof)
  • ajout d'une règle d'en-tête à la configuration de vhost (comme expliqué par pikachuprof)

J'ai également essayé les solutions proposées par schmant mais rien ne semble aider.

Vous trouverez ci-dessous mes journaux Apache2. Comme vous pouvez le voir, l'utilisateur est passé à travers... Comment puis-je vérifier que les variables d'environnement REMOTE_USER / HTTP_REMOTE_USER sont correctement définies ? Y a-t-il d'autres étapes de dépannage que je peux essayer ?

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" 

Bonjour,

j'ai la même erreur que @jeremyj563.

Existe-t-il une solution pour se connecter avec SSO ?

Merci pour votre réponse

Je suis également intéressé par le SSO.

Ce serait une option pour implémenter Azure AD pour SSO.

Nous sommes également très intéressés. Je teste actuellement l'application dans l'Univention Test App Center et je suis très excité.

Désolé de vous avoir blâmé : ne fonctionnera pas sur univention, car le docker compose utilise nginx.

ATTENTION : Nous devons vous avertir d'utiliser l'implémentation SSO de la manière décrite dans ce numéro ou dans d'autres. Les modifications fournies ici contiennent une grave faille de sécurité. Cette vulnérabilité persistera les sessions créées via SSO pour les utilisateurs non authentifiés. Cela signifie qu'il est possible pour des utilisateurs non authentifiés de reprendre la session SSO précédemment créée pour un utilisateur (dans le contexte Zammad).

Nous vous recommandons fortement de désactiver l'authentification unique jusqu'à ce que ce problème soit résolu.

Cependant, la bonne nouvelle est que nous avons commencé à travailler sur la mise en œuvre officielle du SSO.

L'authentification unique est enfin arrivée dans develop grâce à @rlue ! Il fera partie de la prochaine version 3.2 dans quelques semaines. Veuillez noter que la mise à jour des instances Zammad utilisant la branche develop est actuellement interrompue. Nous travaillons là-dessus. Cependant, vous pouvez tester l'authentification unique dans un nouveau système (test) Zammad.

@MrGeneration pouvez-vous s'il vous plaît étendre la documentation pour couvrir la configuration SSO dans votre prochain créneau horaire libre ?

Il y a eu un suivi. Veuillez noter le commit ci-dessus.

Malheureusement, nous rencontrons des obstacles lors de la création de la documentation 😞 Une contribution sous forme de Pull Request à la https://github.com/zammad/zammad-admin-documentation serait très appréciée.
Le point de terminaison de l'API est /auth/sso . Nous nous attendons à ce que l'un des éléments suivants soit présent et contienne l'attribut login d'un utilisateur :

  • ENV REMOTE_USER
  • ENV HTTP_REMOTE_USER
  • En-tête X-Forwarded-User

Faites-moi savoir si vous avez des questions. Je suis heureux d'y répondre.

Fermeture maintenant.

Par souci d'exhaustivité : la documentation SSO est actuellement en cours de contrôle qualité.
https://github.com/zammad/zammad-documentation/pull/147

Cette page vous a été utile?
0 / 5 - 0 notes