Détails: Écrit par : Gabriel Guillory; Catégorie : Projets divers; Publication : 3 juillet 2023; Affichages : 459

Le module Mellon permet d'authentifier des utilisateurs lors de l'accès à un serveur Apache HTTPd. Cela permet notamment d'offrir des fonctionnalités de Single Sign On et de contrôler l'accès à des applications qui ne proposent pas nativement une authentification des utilisateurs.

Dans cet article, nous allons voir comment il est possible à des utilisateurs Active Directory d'ouvrir une session Windows sur leur machine et d'accéder, grace à cette authentification initiale, à une application Web telle que Grafana en passant par un reverse proxy Apache configuré avec le module Mellon sans avoir à se réauthentifier.

Contenu

Pré-requis
Quelques rappels
Installation de Mellon
Configuration dans ADFS
Configuration de Grafana
Authentification Windows Intégrée (WIA)
Liens

Pré-requis

Un serveur Apache HTTPd est requis. Dans notre cas, nous nous appuierons sur un service Apache HTTPd configuré en proxy-inverse pour autoriser ou non l'accès à une application
Il sera également nécessaire de pouvoir accéder aux services ADDS et ADFS pour configurer le Single Sign On.
Une application ne gérant pas l'authentification est requise et dont l'accès a été configuré en HTTPS. Dans notre cas, nous utiliserons Grafana 10 configuré sans authentification.

Quelques rappels

IdP : Identity Provider ou fournisseur d'identité. C'est le serveur qui offre le service d'authentification. Il peut également retourner des informations complémentaires (attributs) relatives au compte authentifié. Dans notre cas, il s'agira du serveur ADFS.
SP : Service Provider ou fournisseur de service. C'est l'application qui a délégué à l'IdP la tâche de l'authentification de ses utilisateurs. Comme le SP et L'IdP ont préalablement établi un lien de confiance par l'échange mutuel de métadonnées sécurisées (fichiers XML), le SP peut accepter de "laisser passer" un utilisateur qui a été authentifié par l'IdP distant. Dans notre cas, le SP correspond au module Mellon.
Les points de terminaison sont des URL mises a disposition par le SP et l’IdP afin d’assurer leur communications. Comme il s’agit de communications confidentielles, ADFS refusera d’enregistrer les points de terminaison inclus dans le fichier de metadata d’un SP si ceux-ci ne sont pas sécurisés en HTTPS. Il convient donc, même dans un labo, de configurer le HTTPS au niveau du SP
WIA : Windows Integrated Authentication, est un mécanisme proposé par Microsoft pour permettre de transmettre automatiquement à un serveur cible (ex: serveur ADFS) les informations d'authentification de l'utilisateur ayant ouvert la session Windows.

Installation de Mellon

Sur le serveur Apache, installer les packages Mellon, SSL et OpenSSL avec la commande suivante :
```
# dnf install mod_auth_mellon mod_ssl openssl
```
Créer un répertoire pour rassembler les fichiers métadata de Mellon :
```
# mkdir -p /etc/httpd/mellon
```

Lancer le script de création des métadata et du certificat SSL Mellon :

# cd /etc/httpd/mellon
# /usr/libexec/mod_auth_mellon/mellon_create_metadata.sh https://grafana.interne.lan/mellon/metadata https://grafana.interne.lan/mellon

- le 1^er paramètre correspond à l’identifiant de l’entité. On utilise généralement l’URL du SP où les métadata peuvent être récupérées
- le 2^ème paramètre correspond à l’URL où les messages SAML à destination du SP seront interprétés et que Mellon appelle le « MellonEndPointPath »

Le script paraît bien s'exécuter et retourne alors les informations suivantes :

Output files:
Private key: https_grafana.interne.lan_mellon_metadata.key
Certificate: https_grafana.interne.lan_mellon_metadata.cert
Metadata: https_grafana.interne.lan_mellon_metadata.xml
Host: grafana.interne.lan

Endpoints:
SingleLogoutService (SOAP): https://grafana.interne.lan/mellon/logout
SingleLogoutService (HTTP-Redirect): https://grafana.interne.lan/mellon/logout
AssertionConsumerService (HTTP-POST): https://grafana.interne.lan/mellon/postResponse
AssertionConsumerService (HTTP-Artifact): https://grafana.interne.lan/mellon/artifactResponse
AssertionConsumerService (PAOS): https://grafana.interne.lan/mellon/paosResponse

En réalité, on s'aperçoit rapidement que le fichier XML des métadata n'a pas été généré :

Explication de l'erreur :
L’instruction « set -e » placée au début du script sh indique que l’exécution sera interrompue en cas d’erreur. Comme le script exécute la commande openssl avec une redirection des erreurs vers /dev/null, celui-ci s’arrête donc en cas d’erreur d’openssl sans qu’aucune erreur ne soit affichée. Comme openssl génère effectivement une erreur dans notre cas, cela explique pourquoi le fichier XML n’est pas créé dans la suite du script. L’erreur retournée par openssl est non bloquante et concerne la génération des nombres aléatoires via /dev/urandom qui a changé au moins depuis la version 3 d’openssl (Cf ce post).

Contournement adopté :
On commente la directive « set -e » en début de script et on relance le script.

Pour plus de clarté, renommer les fichiers générés :

# mv https_grafana.interne.lan_mellon_metadata.key grafana_mellon.key
# mv https_grafana.interne.lan_mellon_metadata.cert grafana_mellon.cert
# mv https_grafana.interne.lan_mellon_metadata.xml grafana_mellon_sp.xml

Récupérer le fichier de métadata XML de l’IdP ADFS situé à l’adresse suivante et placer le fichier dans /etc/httpd/mellon :
https://adfs01.pic.lan/FederationMetadata/2007-06/FederationMetadata.xml

Pour plus de clarté, renommer le fichier métadata de l'IDP :

# cd /etc/httpd/mellon
# mv FederationMetadata.xml adfs_idp.xml

Créer le fichier /etc/httpd/conf.d/grafana.interne.lan.conf en adaptant le contenu suivant :

#========
# GRAFANA
#========
<VirtualHost *:80>
   ServerName grafana.interne.lan
   Redirect / https://grafana.interne.lan/
</VirtualHost>

#============
# GRAFANA SSL
#============
<VirtualHost *:443>
   ServerName grafana.interne.lan

   <Location />

      #=====================
      # autorisation d'accès
      # selon l'IP (1)
      #=====================
      Order Deny,Allow
      Deny from all
      Allow from 192.168.0.0/16 10.0.1.0/24

      #================================
      # configuration de Mellon
      # pour toute l'arborescence / (2)
      #================================
      MellonEnable info
      MellonEndpointPath /mellon/
      MellonSPMetadataFile /etc/httpd/mellon/grafana_mellon_sp.xml
      MellonSPPrivateKeyFile /etc/httpd/mellon/grafana_mellon.key
      MellonSPCertFile /etc/httpd/mellon/grafana_mellon.cert
      MellonIdPMetadataFile /etc/httpd/mellon/adfs_idp.xml

      #===============================
      # protection effective de
      # l'accès à l'arborescence / (3)
      #===============================
      AuthType Mellon
      MellonEnable auth
      Require valid-user

      #==========================
      # header d'authentification
      # envoyé à Grafana (4)
      #==========================
      RewriteEngine On
      RewriteRule .* - [E=PROXY_USER:%{LA-U:REMOTE_USER},NS]
      RequestHeader set X-WEBAUTH-USER "%{PROXY_USER}e"
      RequestHeader unset Authorization

   </Location>

   #======================
   # configuration SSL (5)
   #======================
   SSLEngine on
   SSLCertificateFile /etc/pki/tls/certs/localhost.crt
   SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
   SSLProtocol all -TLSv1.1 -TLSv1 -SSLv2 -SSLv3

   #=============
   # relayage (6)
   #=============
   ProxyPreserveHost On
   ProxyPass / http://lin-sv02.interne.lan:3000/
   ProxyPassReverse / http://lin-sv02.interne.lan:3000/

</VirtualHost>

Notes :
- le 1er virtualhost ne fait que rediriger les requêtes HTTP vers le virtualhost SSL
- le bloc noté (1) n'autorise que les requêtes venant de notre réseau privé (192.168.0.0/16 et 10.0.1.0/24)
- le bloc noté (2) configure la protection des accès à partir du niveau de l’arborescence de l’URL défini par la clause Location (ici la racine /).
- le bloc noté (3) protège de manière effective le niveau d'arborescence de l'URL défini par la clause Location (ici la racine /). Noter que ce bloc pourrait se situer à un niveau inferieur (ex : /grafana) dans la mesure où Mellon a été configuré dans un niveau supérieur.
- le bloc noté (4) ajoute aux en-têtes HTTP relayées vers Grafana le champ "X-WEBAUTH-USER" contenant le nom de l'utilisateur. Ce nom d'utilisateur est récupéré dans la variable d'environnement REMOTE_USER à partir du popup d'authentification puis mis en forme dans la variable d'environnement PROXY_USER et enfin affecté au champ X-WEBAUTH-USER. Cette opération est nécessaire car même si Grafana sera configuré sans authentification native puisque l'on souhaite déléguer cette tâche à l'IdP, l'application a besoin quand même de connaitre le nom de l'utilisateur authentifié pour pouvoir lui ouvrir son profil.

Vérifier la syntaxe et relancer le serveur Apache avec les commandes suivantes :
```
 # httpd configtest
 # systemctl restart httpd
```

Configuration dans ADFS

Configuration de la partie de confiance

Dans la terminologie Microsoft, une partie de confiance (Relying Party) est une application tierce qui s’appuie sur ADFS pour authentifier des utilisateurs. Dans la terminologie SAML, il s’agit du Service Provider. Une relation de confiance (Relying Party Trust) doit être mise en place entre le SP (Relying Party) et l’IdP (ADFS).

Copier le fichier de métadata généré par Mellon grafana_mellon_sp.xml sur le serveur ADFS
Dans le gestionnaire ADFS, cliquer-droit sur « Approbation de la partie de confiance » puis cliquer sur « Ajouter une approbation de partie de confiance ». L’assistant de création se lance.
A l’étape « Bienvenue », sélectionner « prise en charge des revendications » et cliquer sur "Démarrer".
A l’étape « Sélectionner une source de données », cliquer sur « Importer les données concernant la partie de confiance à partir d’un fichier » et sélectionner le fichier « grafana_mellon_sp.xml » précédemment copié. Cliquer ensuite sur « suivant ».
Le message suivant peut apparaitre et être ignoré sans risque :
A l’étape « Entrez le nom complet », choisir un nom pour identifier la partie de confiance et cliquer sur "suivant" :
A l’étape « Sélectionner une stratégie de contrôle d’accès », on peut notamment spécifier un mode d’authentification basé sur le MFA. Dans notre cas, on sélectionne « Autoriser tout le monde » et on clique sur "suivant" :
A l’étape « Prêt à ajouter l’approbation », on peut vérifier toutes les informations configurées avant de valider la création de la relation de confiance en cliquant sur "suivant".
A l’étape « Terminer », on peut cocher la case pour passer directement à la configuration de la stratégie d’émission des revendications après avoir cliqué sur "fermer".

Configuration des revendications

Dans « Approbation de la partie de confiance », cliquer-droit sur la partie de confiance à configurer puis cliquer sur « Editer la stratégie d’émission de revendication » :
La boîte de dialogue qui apparait affiche la liste des règles de transformation qui seront appliquées dans l’ordre pour répondre à la partie de confiance :
Cliquer sur « Ajouter une règle » puis dans la fenêtre qui s'affiche, sélectionner « Transformer une revendication entrante » et cliquer sur "suivant" :
Dans « Configurer la règle de revendication », configurer la règle de la manière suivante puis cliquer sur "terminer", sur "appliquer" et "OK" :
Aller ensuite dans les propriétés de la partie de confiance, dans l’onglet « Avancées » et vérifier que l’algorithme de hachage correspond à SHA-256 au moins.

Configuration de Grafana

Ouverture de session automatique

Pour que Grafana ouvre automatiquement la session de l'utilisateur authentifié par l'ADFS puis autorisé par Mellon, il faut ajouter les paramètres suivants dans le fichier /etc/grafana/grafana.ini :
```
 [auth.proxy]
 enabled = true
 header_name = X-WEBAUTH-USER
 header_property = username
 auto_sign_up = true
```
Note : le paramètre "auto_sign_up = true" signifie que Grafana va ouvrir automatiquement la session de l'utilisateur spécifié dans le champ "X-WEBAUTH-USER" que le reverse-proxy a ajouté dans la requête HTTP.

Relancer Grafana :

 # systemctl restart httpd
 # systemctl restart grafana-server

Premier test d'accès à Grafana

Accéder à l'URL de Grafana, dans notre cas http://grafana.interne.lan. Nous serons alors redirigés de façon transparente vers https://grafana.interne.lan puis vers la bannière de login de l'ADFS pour l'authentification. Saisir alors les informations d'authentification d'un compte présent dans ADDS et cliquer sur "connexion" :
Nous constatons que nous accédons à Grafana et que la session de l'utilisateur PIC\user01 est automatiquement ouverte :

Note importante :
Si l'accès échoue et que nous obtenons les erreurs suivantes dans les logs HTTPd, alors il est très probable que cela soit dû à une désynchronisation des horloges. En effet, comme de nombreux systèmes d'authentification, ADFS/ADDS ont besoin que les clients et les serveurs aient leur horloge bien synchronisée. Dans notre cas, il convient donc de vérifier et de rectifier le cas échéant la date et l'heure du reverse proxy, de l'ADFS et du contrôleur de domaine (même si normalement ADFS et ADDS se synchronisent automatiquement).
```
[auth_mellon:error] [pid xxx] [client xxx] NotBefore in Condition was in the future.
[auth_mellon:error] [pid xxx] [client xxx] NotOnOrAfter in Condition was in the past.
```

Déconnexion

Si nous tentons de nous déconnecter de Grafana en cliquant sur "Sign out", nous constatons qu'aucune déconnexion n'est effectuée et que nous revenons à la page d'accueil de notre profil. C'est normal puisque c'est l'ADFS qui nous a authentifié et non pas Grafana. Si nous souhaitons être effectivement déconnecté de l'ADFS, il faut donc demander cette déconnexion auprès du serveur ADFS. Cela aura toutefois pour conséquence de nous déconnecter des autres applications éventuelles pour lesquelles ADFS nous avait authentifié.

Dans le virtualhost SSL Grafana du reverse proxy, ajouter la ligne suivante (en adaptant le FQDN bien sûr) à la fin du bloc <Location /> :
```
 Redirect /logout https://adfs01.pic.lan/adfs/ls/?wa=wsignout1.0
```
Cela a pour effet de rediriger l'URL de déconnexion Grafana vers l'URL de déconnexion de l'ADFS.
Relancer le service HTTPd :
```
# systemctl restart httpd
```
Accéder à nouveau à Grafana et cliquer cette fois sur "Sign out" en haut à droite. Nous constatons cette fois-ci que cette action a provoqué la déconnexion auprès de l'ADFS :

Authentification Windows Intégrée (WIA)

WIA (noté aussi parfois IWA) permet au navigateur de fournir à ADFS les informations d'authentification de la session Windows, soit de façon automatique et transparente, soit après avoir demandé à l’utilisateur de les saisir dans un popup. C'est un moyen d'associer l'authentification Kerberos à une authentification de type SSO (SAML, OAuth...). L'opération ne peut se faire de façon automatique qu'à partir d'une machine et d'un compte utilisateur issus du même environnement Active Directory que le serveur ADFS, ce qui ne la destine habituellement qu'à une utilisation sur un intranet. Notons que la configuration de cette fonctionnalité n'est pas si évidente car Microsoft ne la documente pas vraiment dans le détail.

Activer WIA sur le serveur ADFS

Dans le composant d'administration ADFS, aller dans < Service / Méthodes d'authentification / Editer les méthodes d'authentification principale >
Dans la boîte de dialogue qui apparaît, s'assurer dans l'onglet "Principal" que l'authentification Windows est activée.

Vérifier le SPN du compte de service ADFS

Un SPN (Service Principal Name) est une chaine de caractère de la forme < classe > / FQDN_du_serveur servant à identifier un service s'exécutant sur une machine donnée (ex : cfis, dns, www ...). Un client peut avoir besoin de connaitre le compte de service exécutant un service en particulier notamment dans le cadre d'une authentification Windows intégrée. Pour répondre à cette nécessité, Active Directory renseigne généralement l'attribut "ServicePrincipalName" des comptes de service. Mais dans le cas du service ADFS, il est très possible qu'un compte spécifique ait été créé sans SPN donnant lieu à un message d'avertissement lors de la procédure d'installation (Cf étape 8 de "Installer ADFS sous Windows Server 2022"). C'est pourquoi il est impératif de vérifier le SPN du compte de service utilisé pour ADFS et de le renseigner le cas échéant.

Sur le serveur ADFS, la commande suivante nous indique qu'aucun SPN n'a été configuré pour notre service HTTP ADFS :
```
> setspn -Q HTTP/adfs01.pic.lan
Vérification du domaine DC=pic,DC=lan

Aucun SPN identifique détecté.
```
Cela est également confirmé par l'attribut "servicePrincipalName" de notre compte de service "service-adfs" qui est vide :

Si le SPN du compte de service utilisé par ADFS est vide, alors le renseigner en adaptant la commande suivante :

> setspn -s HTTP/adfs01.pic.lan service-adfs
Vérification du domaine DC=pic,DC=lan

Inscription des ServicePrincipalNames pour CN=service-adfs,CN=Users,DC=pic,DC=lan
          HTTP/adfs01.pic.lan
Objet mis à jour

On constate que l'attribut "servicePrincipalName" du compte de service a été mis à jour :
cap20

Etendre la liste des navigateurs acceptés par ADFS

Les types de navigateur (user-agent) supportés doivent apparaitre dans la propriété wiasupportedagents de ADFS :
```
 > Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
```
Pour ajouter à cette liste les navigateurs Chrome, Firefox et autres navigateurs compatibles avec Mozilla, lancer la commande suivante. "Mozilla/5.0" doivent alors apparaitre dans la propriété :
```
 > Set-AdfsProperties -WIASupportedUserAgents ((Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents) + "Mozilla/5.0")
```

Pour rétablir si nécessaire la liste à son état initial :

> Set-AdfsProperties -WIASupportedUserAgents "MSAuthHost/1.0/In-Domain", "MSIE 6.0", "MSIE 7.0", "MSIE 8.0","MSIE 9.0", "MSIE 10.0", "Trident/7.0", "MSIPC", "Windows Rights Management Client","MS_WorkFoldersClient","=~Windows\s*NT.*Edge"

Vérifier les modifications en relançant la commande de l'étape 1. Nous devrions alors obtenir l'affichage suivant :
Redémarrer ensuite le service ADFS :
```
 > Restart-Service adfssrv
```

Configurer les navigateurs pour le WIA

Edge et Chrome

Edge et Chrome s'appuient sur les options internet de Windows pour activer ou non l’authentification automatique Windows. Nous allons donc débuter la configuration à ce niveau-là.

Ouvrir les "options internet" de Windows. Dans la rubrique "sécurité" de l'onglet "avancé", vérifier que la case "Activer l'authentification Windows intégrée" est cochée (ce doit être le cas par défaut) :
Dans l'onglet "sécurité", cliquer sur "Sites de confiance" puis sur le bouton "Sites" afin d'ajouter l'URL du serveur ADFS.
Cliquer ensuite sur "personnaliser le niveau" puis dans < Authentification utilisateur / Connexion >, sélectionner "Connexion automatique avec le nom d'utilisateur et le mot de passe actuel" et valider.
Tester tout le processus SSO en ouvrant une session Windows avec un utilisateur Active Directory, puis en ouvrant Chrome ou Edge et en saisissant l'URL de l'application cible, en l'occurence http://grafana.interne.lan. Nous constatons alors que nous accédons directement au profil de l'utilisateur authentifié par les intermédiaires successifs WIA/Kerberos, Mellon/SAML, ADFS/ADDS :

Spécificité Firefox

Les choses se compliquent un peu avec Firefox. Alors qu'avec Edge et Chrome, l'authentification unique et automatique par WIA ne semble pas poser de problème, Firefox v115 affiche systématiquement un prompt afin de resaisir un login + mot de passe.

cap25

Tout d'abord, il faut savoir que WIA affiche ce prompt s'il ne parvient pas à authentifier automatiquement l'utilisateur Windows. On voit donc ici que l'authentification WIA initiée par Firefox est refusée par notre serveur ADFS. Cela est dû à une couche de sécurisation ADFS nommée Extended Protection for Authentication (EPA) qui permet d'empêcher certaines attaques de type "Man in the Middle" contre le serveur ADFS. Edge et Chrome (version > 51.0.2784) sont compatibles avec EPA ce qui explique pourquoi nous ne rencontrons pas ce problème avec ces deux navigateurs. En ce qui concerne Firefox, celui-ci ne semble toujours pas compatible EPA malgré un ticket ouvert depuis longtemps sur bugzilla. A l'heure actuelle, si l'on souhaite absolument faire fonctionner le WIA de Firefox (version <= 115), c'est techniquement possible mais au prix d'une sérieuse concession sur la sécurité du serveur ADFS, c'est-à-dire en désactivant l'EPA.

La procédure suivante décrit comment faire fonctionner le WIA de Firefox en désactivant l'Extended Protection for Authentication de l'ADFS. Cette procédure n'est toutefois pas recommandée en production :

Sur le serveur ADFS, désactiver l'EPA avec les commandes powershell suivantes :
```
> Get-ADFSProperties
> Set-ADFSProperties -ExtendedProtectionTokenCheck None
```
Note : la valeur par défaut du paramètre ExtendedProtectionTokenCheck est "Allow"
Redémarrer ensuite le service ADFS :
```
> Restart-Service adfssrv
```
Sur le navigateur Firefox du client, taper "about:config" dans la barre d'adresse afin d'accéder aux paramètres avancés, puis en bas du message d'avertissement, cliquer sur le bouton "Accepter le risque et poursuivre" :
Dans le champ de recherche, taper "network.negotiate" afin de configurer les paramètres network.negotiate-auth.allow-non-fqdn, network.negotiate-auth.allow-proxies, network.negotiate-auth.trusted-uris respectivement à true, false et <URL du serveur ADFS>.
Tester tout le processus SSO en ouvrant une session Windows avec un utilisateur Active Directory, puis en ouvrant Firefox et en saisissant l'URL de l'application cible, en l'occurence http://grafana.interne.lan. Nous constatons alors que nous accédons directement au profil de l'utilisateur authentifié par les intermédiaires successifs WIA/Kerberos, Mellon/SAML, ADFS/ADDS :

Liens

https://www.techsupportpk.com/2021/03/configure-sso-in-apache-using-mellon-adfs-ubuntu.html
https://github.com/keycloak/keycloak-documentation/blob/main/securing_apps/topics/saml/mod-auth-mellon.adoc
https://jdennis.fedorapeople.org/doc/mellon-install/mellon-install-guide.html
https://osc.github.io/ood-documentation/latest/authentication/adfs-with-auth-mellon.html
!!https://www.techsupportpk.com/2018/05/single-sign-on-apache-windows-adfs-rhel-centos.html
https://learn.microsoft.com/en-us/azure/active-directory/develop/scenario-desktop-acquire-token-integrated-windows-authentication?tabs=dotnet
!!https://pitstop.manageengine.com/portal/en/kb/articles/saml-auto-login-with-adfs
https://itiscloudy.com/2020/05/why-does-adfs-wia-and-kerbeos-work-togethere/
https://medium.com/identity-beyond-borders/integrated-windows-authentication-with-kerberos-and-wso2-identity-server-ffcd8263a0f1
!!https://jpassing.com/2021/10/18/obtaining-adfs-access-tokens-using-the-client-credentials-grant-and-integrated-windows-authentication/
!!https://www2.microstrategy.com/producthelp/Current/SystemAdmin/WebHelp/Lang_1033/Content/integrated_auth_web_browser.htm
https://learn.microsoft.com/fr-fr/windows-server/identity/ad-fs/operations/configure-ad-fs-browser-wia
https://docs.centrify.com/Content/CoreServices/Authenticate/SilentAuthFirefox.htm
https://rakhesh.com/windows/firefox-and-adfs-wia/
https://verbalabs.atlassian.net/wiki/spaces/docs/pages/6816783/Integrated+Windows+Authentication+browser+requirements
https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox
https://cherwellsupport.com/webhelp/en/5.0/5853.htm
https://dirteam.com/sander/2019/11/26/howto-enable-extended-protection-for-authentication-on-the-ad-fs-farm/
https://securityboulevard.com/2022/06/relaying-to-adfs-attacks/
https://support.mozilla.org/fr/questions/926378

Ajouter un commentaire

SYNTAXERROR

C'est pas grave ...

Menu principal

Tags populaires

Connexion

Authentification unique avec WIA, Mellon et ADFS