Authentification on Zwindler's Reflection

Déléguer l’authentification Gitlab à Azure AD avec OAuth2

Tue, 14 May 2019 11:45:56 +0000

Gérer les comptes internes à Gitlab, c’est bof, le SSO, c’est mieux !

Dans le cadre de l’hébergement d’un nouveau serveur Gitlab, j’ai voulu intégrer notre base de compte existante, synchronisée dans Azure à l’aide de l’outil Azure AD, qui est le pendant « cloud » de l’Active Directory, bien connus de mes amis Windowiens (oui, il y en a). La plupart des applications savent aujourd’hui déléguer l’authentification à des fournisseurs tiers, généralement de type LDAP, via des protocoles tels que SAML(2) ou OAuth(2).

Cependant, bien que ces protocoles soient standards, leur implémentation dépend fortement du logiciel en question et il n’est pas toujours facile de s’y retrouver.

Pour faciliter cette opération, Azure a mis à disposition, directement dans Azure AD, des objets préconfigurés pour des milliers d’applications tierces. C’est comme ça qu’on peut implémenter, de manière simple et rapide, le SSO Active Directory avec les produits Atlassian (JIRA + Confluence), par exemple.

Tout commence dans Azure

Dans le portail Azure, ouvrir « Entreprise applications », puis cliquer sur « New Application »

Malheureusement pour nous, il n’y a pas de template pour Gitlab ! Il va falloir le faire à la main.

A noter, le principe déroulé dans ce tutoriel est valable pour n’importe quelle autre application supportant des mécanismes similaire. Il est possible de réutiliser un template utilisé pour un soft et le réadapter pour d’autres logiciels qui fonctionnent de la même façon. C’est juste une histoire de paramètres.

Le menu nous conseille donc de choisir « Non-gallery application », puisque nous ne trouvons pas Gitlab. Sauf que, bizarrement, il faut un compte Premium pour utiliser cette feature.

On se rabat donc sur « Application you’re developing ». C’est d’ailleurs ce que conseille d’utiliser la documentation de Gitlab. Sauf que, pas de chance non plus, ça ne marche plus comme ça, maintenant ;)

Créer une App registration pour Gitlab

Pour toutes les applications qui ne sont pas dans le store, on ne peut donc plus passer par les « Entreprise Applications ». On va donc créer une « App registration », qui n’est ni plus ni moins qu’un compte de service avec un ID et un (ou plusieurs) secrets.

Cliquer sur « New registration », puis lui donner un nom.

Sélectionner le type de comptes qui pourront accéder à cette application. Dans mon cas, il s’agit uniquement d’autoriser les comptes provenant de mon AD, mais on peut imaginer le cas d’une application ouverte en BtoB ou carrément ouverte à tout Internet.

Enfin, renseigner l’URL de callback, qui permettra à Azure de rediriger l’utilisateur qui s’est authentifié avec succès vers notre Gitlab.

We’ll return the authentication response to this URI after successfully authenticating the user. Providing this now is optional and it can be changed later, but a value is required for most authentication scenarios.

Dans le cas précis de Gitlab, cette URL aura la forme : mongitlab.example.org/users/auth/azure_oauth2/callback

Récupérer des valeurs qui intéressent Gitlab

Retourner ensuite dans l’overview de notre nouvelle « App registration ». Dans les détails, elle dispose d’un Application ID, aussi appelé Client ID et d’un Tenant ID :

On va maintenant créer un Secret. Pour les secrets, on peut choisir soit d’uploader un certificat (conseillé car plus sécurisé), ou de lui générer un mot de passe. Pour la simplicité de ce tutoriel, je vais créer un mot de passe pour notre application, mais je le répète, mieux vaut uploader un certificat.

On dispose maintenant de notre CLIENT_ID, notre TENANT_ID et de notre CLIENT_SECRET. Notez les bien, car une fois que la fenêtre sera fermée, il ne sera plus possible de relire à nouveau le secret et il faudra en générer un nouveau…

Ajouter des restrictions ou des fonctionnalités complémentaires

En fonction de votre niveau de licence pour Azure AD, vous aurez accès à plus ou moins de choses. Moi, je n’ai accès à pratiquement aucune feature, mais si vous avez mieux, vous aller pouvoir ajouter des options très pratiques telles que le self service (les utilisateurs peuvent demander eux même à avoir accès à l’application, et si c’est validé, ils sont ajouté dans le bon groupe) et aux autorisations/restrictions par groupes Azure AD.

Pour se faire, il faut RETOURNER dans les Entreprises Applications (#RollingEyes), puis chercher notre « App registration » qui y apparaît maintenant dans la liste (avec le filtre All applications).

Configuration de Gitlab

Gitlab ayant été installé avec les packages, la configuration se situe dans le fichier /etc/gitlab/gitlab.rb.

Dans le fichier de configuration, ajouter le bloc suivant en remplaçant les valeurs en majuscules par celles qu’on vient de récupérer :

gitlab_rails['omniauth_providers'] = [
{
"name" => "azure_oauth2",
"args" => {
"client_id" => "CLIENT_ID",
"client_secret" => "CLIENT_SECRET",
"tenant_id" => "TENANT_ID",
}
}
]

Rechargez ensuite Gitlab pour prise en compte de ce nouveau paramètre

sudo gitlab-ctl reconfigure
[...]
Running handlers complete
Chef Client finished, 13/637 resources updated in 26 seconds
gitlab Reconfigured!

Une boite d’authentification Azure Oauth2 devrait apparaître sous le login classique !! Youpi :)

Et voilà c’est fini… ou presque…

Vous avez maintenant ajouté du SSO et l’authentification via Azure AD pour l’accès à votre Gitlab ! On essaye de se connecter ?

Et Paf !!

Signing in using your Azure Oaut2 account without a pre-existing gitLab account is not allowed

En fait, c’est normal.

Par défaut, il n’est pas possible de s’authentifier avec Azure Oauth2 si un compte n’existe pas préalablement dans Gitlab, ce qui est quand même bien dommage si vous avez beaucoup de comptes à créer.

Deux cas de figure.

Soit vous ne souhaitez pas que n’importe qui dans votre AD puisse se connecter sans votre accord préalable

Dans ce cas là, ce cas vous est finalement assez favorable, puisque vous allez pouvoir explicitement dire qui peut ou ne peut pas se connecter. Si vous ne disposez pas des bonnes licences et que vous avez pas pu restreindre l’accès à un groupe d’utilisateurs, c’est une « solution » de contournement acceptable.

Cependant, pour éviter de créer à la main tous les comptes, il sera probablement préférable de les créer de manière automatique à l’aide de l’API Gitlab et même du très bon module Ansible gitlab_user :

- name: "Create Gitlab User"
gitlab_user:
server_url: "{{gitlab_api}}"
login_token: "{{token}}"
validate_certs: True
name: "Zwindler"
username: "zwindler"
password: "{{ 99999999 | random | to_uuid }}"
confirm: no
email: "zwindler@zwindler.fr"
state: present

Soit, à l’inverse, vous souhaitez que tous les utilisateurs de votre AD puissent avoir accès, sans pour autant devoir les ajouter uns par uns

Il existe alors des lignes sont à ajouter dans la configuration gitlab pour autoriser cette option :

gitlab_rails['omniauth_allow_single_sign_on'] = ['azure_oauth2']
gitlab_rails['omniauth_block_auto_created_users'] = false
gitlab_rails['sync_profile_from_provider'] = ['azure_oauth2']
gitlab_rails['sync_profile_attributes'] = ['name', 'email']

D’un point de vue sécurité, c’est un peu moins bien puisque n’importe qui avec un compte pourra se connecter, sans que vous le sachiez.

Cependant, ce problème est un peu moins grave qu’il n’y parait puisque l’utilisateur sera logué mais n’aura accès à rien (ou juste ce qui est « public »).

Dans le cas d’un Gitlab d’entreprise, où tous les développeurs doivent pouvoir se connecter, cette seconde option me parait quasi obligatoire. C’est encore plus acceptable si vous avez pu restreindre l’accès au SSO par groupe dans Azure AD, comme indiqué plus haut.

Have fun :)

Sources

« la Connexion Bureau à Distance ne peut pas vérifier l’identité » depuis un Mac/OSX vers Windows 2008+

Fri, 05 Jun 2015 13:36:49 +0000

On ne peut pas dire que je sois un grand partisan d’Apple, mais il arrive parfois que des VIPs souhaitent se connecter sur les serveurs Windows en bureau à distance (RDP). Et quand on n’y connait rien car on n’en utilise pas, c’est parfois un peu déroutant.

Ici, le mac refusait de se connecter au serveur Windows 2008, qui autorisait pourtant les connexions RDP. En fait, le souci se situait au niveau de l’acceptation du certificat délivré par le serveur 2008r2 (qui venait d’être migré depuis un 2003, qui ne dispose pas de cette sécurité).

Symptôme

Le message d’erreur suivant apparait suite à l’authentification sur la mire d’un serveur Windows 2008 ou plus sur un Mac. Le serveur répond bien au ping (puisqu’on a la mire). On s’est assuré que le mot de passe entré est correct.

Résolution

Comme je l’ai dis en introduction, il s’agit ici d’un défaut du client RDP sur OSX qui gère mal les authentifications avancées de Windows 7 et 2008R2 et plus. Pour résoudre ce problème, il y a plusieurs manipulations à effectuer.

Suppression des entrées dans le trousseau

La première chose à faire est d’abord de supprimer toutes les entrées correspondantes aux connexions RDP dans le trousseau de compte Mac

Ouvrir le finder
Aller dans Applications
Aller dans le dossier Utilitaires
Ouvrir trousseaux d’accès
Supprimer les lignes avec « remote desktop connection »

ATTENTION : faire un clic droit sur la ligne pour supprimer et ne pas utiliser le menu dans le haut. Sinon il y a risque de supprimer tous les enregistrements.

Lors de la prochaine connexion, ne pas cocher d’ajouter les informations au trousseau.

Modification du .rdp

Si le problème persiste, il est probable que les informations de connexion soient contenues dans le RDP. Lorsque l’authentification échoue, ouvrir les préférences du fichier RDP en cliquant sur CBD en haut à gauche, puis sur Préférences

Dans l’onglet Session, vider la case Domaine et décocher les cases

Dans l’onglet Sécurité, cocher la case Toujours se connecter

Quitter les préférences et enregistrer quand le Mac le demande pour mettre à jour le .rdp

Mise en place de Guacamole 0.9.5 sur CentOS 7

Sun, 31 May 2015 09:49:36 +0000

Pour information : je me suis basé sur le très bon article de Deviant Engineer, qui est concis, s’affranchit de la conf par fichier plat au profit du module MySQL, et surtout qui fonctionne, ce qui n’est pas le cas de tous les tutoriels que j’ai pu croiser sur la toile.

Aujourd’hui, au même titre que l’informatique s’est généralisée, Internet est de plus en plus présent, où qu’on se trouve. Mais ce n’est pas toujours un Internet comme à la maison.

Pour des raisons de sécurité et/ou de bande passante, certains ports/protocoles/site web sont souvent bloqués sur les points d’accès public ou d’entreprise. Il n’est pas rare que seul l’HTTP et l’HTTPS soient disponible, me privant ainsi de mes accès SSH/VPN/FTP/…
C’est un vrai casse tête pour moi : je déploie des services chez moi et j’en deviens dépendant au point d’être agacé de ne pas y avoir accès en toutes circonstances. Et plutôt que de relativiser cet absence d’accès absolu à mes services/données, je préfère chercher des moyens de contournement ;).

Si l’autohébergement d’applications web et l’utilisation d’un reverse proxy (Vulture/Apache) répond à une partie de cette problématique, des fois, j’ai parfois besoin d’avoir accès aux machines qui hébergent ces services. C’est pourquoi j’utilisais jusqu’à présent Ajaxterm, puis Gateone pour disposer d’un accès SSH à mes serveurs en cas de filtrage.

Cependant, j’ai aussi besoin de me connecter en mode graphique sur mes serveurs. En présentant au travers d’une interface HTML5 des clients pour les protocoles SSH, VNC et RDP, Guacamole répond à ce besoin.

Quelques ressources pour bien commencer :

La documentation officielle décrit comment l’installer à partir des sources. Cependant, sur certains systèmes, les applications ont été packagées et sont disponibles (0.8.4 si je ne m’abuse sur RHEL et CentOS). Je voulais avoir la version la plus récente, je me suis donc penché sur la solution « compilation ».

Et pour avoir une compatibilité maximale en terme de fonctionnalités, il faut disposer de Tomcat 7, présent nativement dans RHEL7/CentOS7, que j’ai donc installé (mon premier CentOS7, youhou !)

Prérequis

Forcément, la première chose à faire lorsqu’on installe une application web un peu exotique sur un CentOS, c’est d’installer les dépôts additionnels pour les dépendances (ici EPEL).

rpm -Uvh http://mirror.metrocast.net/fedora/epel/7/x86_64/e/epel-release-7-5.noarch.rpm # EPEL Repo
yum -y install wget
wget http://download.opensuse.org/repositories/home:/felfert/Fedora_19/home:felfert.repo && mv home\:felfert.repo /etc/yum.repos.d/ # Felfert Repo
yum -y install tomcat libvncserver freerdp libvorbis libguac libguac-client-vnc libguac-client-rdp libguac-client-ssh
yum -y install cairo-devel pango-devel libvorbis-devel openssl-devel gcc pulseaudio-libs-devel libvncserver-devel \
freerdp-devel uuid-devel libssh2-devel libtelnet libtelnet-devel tomcat-webapps tomcat-admin-webapps java-1.7.0-openjdk.x86_64

Installation du composant « serveur »

Le logiciel est découpé en deux parties. Une partie « serveur » qui correspond au portail web, et une partie dite « cliente », qui se charge de la connexion aux différents serveurs SSH/~~telnet~~/VNC/RDP que vous aurez configurés. J’ai rayé telnet car je refuse d’utiliser ce protocole (à l’exception de certaines contraintes de travail très particulières).

cd /distrib
wget http://sourceforge.net/projects/guacamole/files/current/source/guacamole-server-0.9.5.tar.gz
tar -xzf guacamole-server-0.9.5.tar.gz && cd guac*0.9.5
./configure --with-init-dir=/etc/init.d
make
make install
ldconfig

Installation du du composant « client »

La partie client peut directement être récupérée tel quel sur le site du projet.

mkdir -p /var/lib/guacamole && cd /var/lib/guacamole/
wget http://sourceforge.net/projects/guacamole/files/current/binary/guacamole-0.9.5.war -O guac.war
ln -s /var/lib/guacamole/guac.war /var/lib/tomcat/webapps/
rm -rf /usr/lib64/freerdp/guacdr.so
ln -s /usr/local/lib/freerdp/guacdr.so /usr/lib64/freerdp/

MariaDB (MySQL)

Ne soyez pas surpris de découvrir MariaDB. MariaDB, c’est MySQL. Ou plutôt ce que MySQL aurait du devenir. Il s’agit d’un fork de MySQL initié par son créateur qui a réalisé qu’Oracle (qui a racheté Sun Microsystems en 2009) risquait d’envoyer le produit dans le mur (en concurrence avec Oracle Database).
MariaDB a donc progressivement remplacé MySQL dans les communautés Open Source et les entreprises (citons Google en 2013), et RedHat a suivi le mouvement avec la version 7 de RHEL.
Pas de mauvaise surprise si vous êtes habitués à MySQL : tout est identique en terme d’administration. Vos scripts fonctionneront toujours, les binaires n’ont pas changés.

Installation de la base de données

yum -y install mariadb mariadb-server
cd /distrib
wget http://sourceforge.net/projects/guacamole/files/current/extensions/guacamole-auth-mysql-0.9.5.tar.gz
tar -zxf guacamole-auth-mysql-0.9.5.tar.gz
wget http://dev.mysql.com/get/Downloads/Connector/j/mysql-connector-java-5.1.32.tar.gz
tar -zxf mysql-connector-java-5.1.32.tar.gz
mv mysql-connector-java-5.1.32/mysql-connector-java-5.1.32-bin.jar guacamole-auth-mysql-0.9.5/lib/
mkdir /var/lib/guacamole/classpath/
cp /distrib/guacamole-auth-mysql-0.9.5/lib/* /var/lib/guacamole/classpath/
systemctl restart mariadb.service

Configuration de la base de données

mysqladmin -u root password MySQLRootPass
mysql -u root -p # Enter above password
create database guacdb;
create user 'guacuser'@'localhost' identified by 'guacDBpass';
grant select,insert,update,delete on guacdb.* to 'guacuser'@'localhost';
flush privileges;
quit

Création du schéma pour Guacd

cd /distrib/sqlauth/guacamole-auth-mysql-0.9.5/schema/
cat ./*.sql | mysql -u root -p guacdb # Enter SQL root password set above

Configuration, création du fichier « .properties »

mkdir -p /etc/guacamole/ && vi /etc/guacamole/guacamole.properties
# Hostname and port of gucamole proxy
guacd-hostname: localhost
guacd-port: 4822
# Location to read extra .jar's from
lib-directory: /var/lib/guacamole/classpath/
# Authentication provider class
auth-provider: net.sourceforge.guacamole.net.auth.mysql.MySQLAuthenticationProvider
# MySQL properties
mysql-hostname: localhost
mysql-port: 3306
mysql-database: guacdb
mysql-username: guacuser
mysql-password: guacDBpass
# Additional settings
mysql-disallow-duplicate-connections: false

Post-installation

Ne pas oublier de nettoyer les répertoires contenant les sources (dans /distrib chez moi), ajouter un lien symbolique vers le fichier de configuration et ajouter le démarrage automatique des services

mkdir -p /usr/share/tomcat/.guacamole
ln -s /etc/guacamole/guacamole.properties /usr/share/tomcat/.guacamole/
systemctl enable tomcat.service && systemctl enable mariadb.service && chkconfig guacd on

Le serveur devrait être accessible à l’adresse http://@IP_serveur:8080/gucamole**/**. A partir de là, vous pouvez configurer vos serveurs SSH/RDP/VNC, créer des utilisateurs et vous connecter.

Deux derniers points :

les logs ne sont pas toujours très locaces. Chez moi, il se trouvent dans /var/log/messages et /var/log/tomcat/
il manque selon moi un menu pour gérer les connexions actives. Typiquement, dans le cas de VNC, le soft m’indique que j’ai 4 ou 5 sessions ouvertes. Elles n’ont pas l’air concurrentes (je n’en ai qu’une réellement active), mais me parait potentiellement même problématique