PI Services

Le blog des collaborateurs de PI Services

Authentification SSO avec l'ADFS et Apache 2.5 (installé sur un windows)

Sur mon blog précédent : https://blog.piservices.fr/post/2017/04/28/authentification-sso-avec-l-adfs-et-apache-2-5-installe-sur-un-linux , j'ai expliqué comment configurer un serveur apache installé sur un linux pour faire du SSO avec l'adfs en utilisant auth_mellon et lasso. Aujourd'hui nous allons voir la même chose mais sur un apache installé sur un Windows. 

Contexte

Apache ne communique pas nativement avec l'ADFS. Pour permettre à des applications web qui tournent sur apache de faire de l'authentification SSO, il faudrait installer SimpleSAMLphp qui contient tous les modules nécessaire pour faire du SAML.

Installation du simpleSAMLphp

1. Depuis le site télécharger la dernière version stable de SimpleSAMLphp. Décompression le fichier et déplacer les contenus dans le répertoire www du serveur apache.

2. Accèder au dossier www\simplesamlphp-1.14.11\www\index.php depuis votre navigateur et une page d'installation et de configuration de SimpleSAMLphp apparaîtra. 

Sélectionner >Configuration et vous verrez que par défaut le protocole SAML 2.0 - Idp est désactivé:

Pour l'activer aller dans le fichier \simplesamlphp-1.14.11\config\config.php et modifier le paramètre 'enable.saml20-idp' en true: 

/*
     * Enable
     *
     * Which functionality in SimpleSAMLphp do you want to enable. Normally you would enable only
     * one of the functionalities below, but in some cases you could run multiple functionalities.
     * In example when you are setting up a federation bridge.
     */
    'enable.saml20-idp' => true,
    'enable.shib13-idp' => false,
    'enable.adfs-idp' => false,
    'enable.wsfed-sp' => false,
    'enable.authmemcookie' => false,

Faire un refresh de la page:

Note: Dans notre cas l'idp est un ADFS donc pas besoin d'activer l'idp sur le serveur apache.

S'assurer que tous les prérequis nécessaires sont installés depuis la page configuration:

3. Créer le certificat SSL (auto-signé) pour le service provider (SP) avec openssl (assurez vous que openssl est installé)

openssl req -new -x509 -days 3652 -nodes -out saml.crt -keyout saml.pem

et entrer les fichiers *.crt et *.pem dans le fichier de configuration \simplesamlphp-1.14.11\config\authsources.php comme indiqué ci-dessous:

    // An authentication source which can authenticate against both SAML 2.0
    // and Shibboleth 1.3 IdPs.
    'default-sp' => array(
        'saml:SP',

        // The entity ID of this SP.
        // Can be NULL/unset, in which case an entity ID is generated based on the metadata URL.
        'entityID' => 'http://testapplication/',

        // The entity ID of the IdP this should SP should contact.
        // Can be NULL/unset, in which case the user will be shown a list of available IdPs.
        'idp' => 'https://fs.xxx-xxx.com/federationmetadata/2007-06/federationmetadata.xml',

        // The URL to the discovery service.
        // Can be NULL/unset, in which case a builtin discovery service will be used.
        'discoURL' => null,
		'privatekey' => 'saml.pem',
        'certificate' => 'saml.crt',
  • entityID = l'url de l'application web
  • idp = l'url ou le fichier metadata de l'identity provider (l'idp)
  • privatekey = le fcihier pem créé précédemment
  • certificate = le ficher crt créé précédemment

Génération du fichier service provider (SP) metadata.

Il faudra par la suite générer le fichier metadata du service provider (sp) et l'utiliser pour configuration la fédération ADFS.

Pour générer le fichier sp metadat aller dans sur la page Féderation et cliquer sur [Afficher les métadonnées] de SP SAML 2.0

Une page avec les métadonnées apparaîtra, sauvegarder les tous dans un fichier au format xml. Exemple d'un fichier de metadonnées généré par SimpleSAMLphp:

<?xml version="1.0"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" entityID="http://testapplication/">
  <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol">
    <md:KeyDescriptor use="signing">
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>MIIEFTCCAv2gAwIBAgIJALEBPyeEV48BMA0GCSqGSIb3DQEBCwUAMIGgMQswCQYDVQQGEwJGUjEMMAoGA1UECAwDSURGMQ4wDAYDVQQHDAVQQVJJUzEUMBIGA1UECgwLQVBQTElDQVRJT04xGzAZBgNVBAsMEkFQUExJQ0FUSU9OIEdST1VQRTEVMBMGA1UEAwwMQVBQTElDQVRJT04xMSkwJwYJKoZIhvcNAQkBFhptZXZlbi5rYXJ1cHBhbm5hbkBsaXZlLmNvbTAeFw0xNzAyMDgxMTI3MjJaFw0yNzAyMDgxMTI3MjJaMIGgMQswCQYDVQQGEwJGUjEMMAoGA1UECAwDSURGMQ4wDAYDVQQHDAVQQVJJUzEUMBIGA1UECgwLQVBQTElDQVRJT04xGzAZBgNVBAsMEkFQUExJQ0FUSU9OIEdST1VQRTEVMBMGA1UEAwwMQVBQTElDQVRJT04xMSkwJwYJKoZIhvcNAQkBFhptZXZlbi5rYXJ1cHBhbm5hbkBsaXZlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALjKwVm4GtahFeBZXataYQzIWIAqcenA4RjmyGaGnI64uttEXDea8qpY+FYYCG9QIJWksz9CBrmM81bCi63DvQMa/ufGhTR6x99I5XHXdzya2F0DZCG6VuruPzLFuxi7u3p/ViHzmFkdEW9Gv23+s/SNyXnO7w4+YHiazobTadH9OmioPxd9m9Llwiml0I7FeVkfcnmscNOezD0P89eWVKkRnOjH8yccp2skke1nbHAv7Kh37dt3tq8uE/QPxC9gWimgyuJdo8F49RL6b2vE5laAxKYUSCjY6bcMg2MXrTiJMKmnqj0POauS8r9jy7V26+6sGtjNajOerem2X7ShskkCAwEAAaNQME4wHQYDVR0OBBYEFNB6YexsAR7Hy1YRDN54MxBdId5YMB8GA1UdIwQYMBaAFNB6YexsAR7Hy1YRDN54MxBdId5YMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBAAG1hkGrJcNCrhmacqKi6sOV05238ix0ynGhtZyHVmIZf2OmJIXj117Xk9SHcCk4pFx26yfHOH4vnqK579UL1ACg1bp21R1POO4GNnhXRQiPwOdhtCOprYt9vq1zP7+aIiU4v6gSDUAcWf7a6nin4dwcYfO0cHAly7TW75tJGQa88eT9/v4s7YIopm+8D/+8skB8HqbkJ7i5E6+iILdHXgKqj1amxojPYjrH5ZFZmxS+tT5Z33+PU+FMwYw5YzmSAV84QfotZamcIc95A7FUNP2VEQjkX3nx6zuY+RE8aZr6Ul2ORPJVrnajrcUooP8f6Rd70Fg2Eaq/gmK1bP6UOm4=</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </md:KeyDescriptor>
    <md:KeyDescriptor use="encryption">
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>MIIEFTCCAv2gAwIBAgIJALEBPyeEV48BMA0GCSqGSIb3DQEBCwUAMIGgMQswCQYDVQQGEwJGUjEMMAoGA1UECAwDSURGMQ4wDAYDVQQHDAVQQVJJUzEUMBIGA1UECgwLQVBQTElDQVRJT04xGzAZBgNVBAsMEkFQUExJQ0FUSU9OIEdST1VQRTEVMBMGA1UEAwwMQVBQTElDQVRJT04xMSkwJwYJKoZIhvcNAQkBFhptZXZlbi5rYXJ1cHBhbm5hbkBsaXZlLmNvbTAeFw0xNzAyMDgxMTI3MjJaFw0yNzAyMDgxMTI3MjJaMIGgMQswCQYDVQQGEwJGUjEMMAoGA1UECAwDSURGMQ4wDAYDVQQHDAVQQVJJUzEUMBIGA1UECgwLQVBQTElDQVRJT04xGzAZBgNVBAsMEkFQUExJQ0FUSU9OIEdST1VQRTEVMBMGA1UEAwwMQVBQTElDQVRJT04xMSkwJwYJKoZIhvcNAQkBFhptZXZlbi5rYXJ1cHBhbm5hbkBsaXZlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALjKwVm4GtahFeBZXataYQzIWIAqcenA4RjmyGaGnI64uttEXDea8qpY+FYYCG9QIJWksz9CBrmM81bCi63DvQMa/ufGhTR6x99I5XHXdzya2F0DZCG6VuruPzLFuxi7u3p/ViHzmFkdEW9Gv23+s/SNyXnO7w4+YHiazobTadH9OmioPxd9m9Llwiml0I7FeVkfcnmscNOezD0P89eWVKkRnOjH8yccp2skke1nbHAv7Kh37dt3tq8uE/QPxC9gWimgyuJdo8F49RL6b2vE5laAxKYUSCjY6bcMg2MXrTiJMKmnqj0POauS8r9jy7V26+6sGtjNajOerem2X7ShskkCAwEAAaNQME4wHQYDVR0OBBYEFNB6YexsAR7Hy1YRDN54MxBdId5YMB8GA1UdIwQYMBaAFNB6YexsAR7Hy1YRDN54MxBdId5YMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBAAG1hkGrJcNCrhmacqKi6sOV05238ix0ynGhtZyHVmIZf2OmJIXj117Xk9SHcCk4pFx26yfHOH4vnqK579UL1ACg1bp21R1POO4GNnhXRQiPwOdhtCOprYt9vq1zP7+aIiU4v6gSDUAcWf7a6nin4dwcYfO0cHAly7TW75tJGQa88eT9/v4s7YIopm+8D/+8skB8HqbkJ7i5E6+iILdHXgKqj1amxojPYjrH5ZFZmxS+tT5Z33+PU+FMwYw5YzmSAV84QfotZamcIc95A7FUNP2VEQjkX3nx6zuY+RE8aZr6Ul2ORPJVrnajrcUooP8f6Rd70Fg2Eaq/gmK1bP6UOm4=</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </md:KeyDescriptor>
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://localhost/simplesaml/module.php/saml/sp/saml2-logout.php/default-sp"/>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://localhost/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp" index="0"/>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="http://localhost/simplesaml/module.php/saml/sp/saml1-acs.php/default-sp" index="1"/>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="http://localhost/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp" index="2"/>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="http://localhost/simplesaml/module.php/saml/sp/saml1-acs.php/default-sp/artifact" index="3"/>
  </md:SPSSODescriptor>
</md:EntityDescriptor>

Maintenant il ne reste plus qu'à configuration l'ADFS avec le fichier métadonnées du SP et faire un test. Pour effectuer un test et voir si l'authentification fontionne bien , aller sur la page [Authentifcation] et sélectionner [Tester les sources d'authentification configurées]

Pour accéder à cette page , connecter vous en tant qu'administrateur. Le mot de passe du compte administration est configuration depuis le fichier www\simplesamlphp-1.14.11\config\config.php avec le paramètre 'auth.adminpassword'

/**
     * This password must be kept secret, and modified from the default value 123.
     * This password will give access to the installation page of SimpleSAMLphp with
     * metadata listing and diagnostics pages.
     * You can also put a hash here; run "bin/pwgen.php" to generate one.
     */
    'auth.adminpassword' => '1234',
    'admin.protectindexpage' => false,
    'admin.protectmetadata' => false,

 

Changement d'UPN en mode hybride directement dans O365

Dans un environnement hybride, avec des utilisateurs synchronisés depuis l'Active Directory vers O365, il n'est actuellement pas possible de changer l'UPN directement par le portail d'administration O365.

Cependant avec les commandes Powershell suivante, il est possible de modifier l'UPN directement dans O365:

Set-MsolUserPrincipalName -UserPrincipalName first.lastname@contoso.fr -NewUserPrincipalName first.lastname@contoso.onmicrosoft.com

 

Set-MsolUserPrincipalName -UserPrincipalName first.lastname@contoso.onmicrosoft.com -NewUserPrincipalName first.lastname@contoso.com

 

Il faut passer par l'adresse technique pour changer l'UPN de l'utilisateur d'un domaine à un autre, il faut cependant que l'UPN final soit égal à la valeur présente dans l'Active Directory Onpremise.

Sécurité : Windows KB pour Wanna Cry

 

Suite à l'attaque du virus Wanna Cry, tout le monde a souhaité corriger la faille de sécurité au plus vite.

Avec tout ce qu'on a pu lire ou trouver sur internet on ne sait plus vraiment qui fait quoi et si nous sommes réellement protégé.

Liste des KB de Sécurité

Voici la liste des KB de sécurité couvrants la faille (pour information les KB se remplacent d'un mois à l'autre : exemple la KB du mois d'avril remplace celle de Mars):

  1. Pour Windows XP, Vista, 8, Windows Server 2003 et 2008 : 
    1. Mars 2017
      1. KB4012598
  2. Pour Windows 7 SP1 et Windows Server 2008 R2 SP1:
    1. Mars 2017
      1. Security only update : KB4012212
      2. Monthly Rollup : KB4012215
      3. Preview of Monthly Rollup : KB4012218
    2. Avril 2017
      1. Security only update : KB4015546
      2. Monthly Rollup : KB4015549
      3. Preview of Monthly Rollup : KB4015552
    3. Mai 2017
      1. Security only update : KB4019263
      2. Monthly Rollup : KB4019264
      3. Preview of Monthly Rollup : KB4019265
  3. Pour Windows Server 2012 :
    1. Mars 2017
      1. Security only update : KB4012214
      2. Monthly Rollup : KB4012217
      3. Preview of Monthly Rollup : KB4012220
    2. Avril 2017
      1. Security only update : KB4015548
      2. Monthly Rollup : KB4015551
      3. Preview of Monthly Rollup : KB4015554
    3. Mai 2017
      1. Security only update : KB4019214
      2. Monthly Rollup : KB4019216
      3. Preview of Monthly Rollup : KB4019218
  4. Pour Windows 8.1 et Windows 2012 R2 :
    1. Mars 2017
      1. Security only update : KB4012213
      2. Monthly Rollup : KB4012216
      3. Preview of Monthly Rollup : KB4012219
    2. Avril 2017
      1. Security only update : KB4015547
      2. Monthly Rollup : KB4015550
      3. Preview of Monthly Rollup : KB4015553
    3. Mai 2017
      1. Security only update : KB4019213
      2. Monthly Rollup : KB4019215
      3. Preview of Monthly Rollup : KB4019217
  5. Pour Windows 10 (Release 1511) :
    1. Mars 2017
      1. KB4013198
      2. KB4016636
    2. Avril 2017
      1. KB4015219
    3. Mai 2017
      1. KB4019473
  6. Pour Windows 10 (Release 1607) :
    1. Mars 2017 
      1. KB4013429
      2. KB4015438
      3. KB4016635
    2. Avril 2017
      1. KB4015217
    3. Mai 2017
      1. KB4019472
      2. KB4023680
  7. Pour Windows 10 LTSB : 
    1. Mars 2017 
      1. KB4012606
      2. KB4016637
    2. Avril 2017
      1. KB4015221
    3. Mai 2017
      1. KB4019474

En espérant que cela pourra vous servir.

Pour télécharger les KB : http://www.catalog.update.microsoft.com/home.aspx

 

 

SCOM – Approuver un agent absent de pending management

Lors de l’installation manuelle d’un agent SCOM (sans passer par l’assistant de la console SCOM), celui-ci doit, par défaut, être approuvé manuellement en passant par les Pending Management de l’onglet Administration de la console.

Dans de rares cas, il peut arriver que malgré une configuration correcte l’agent à approuver (ici nommé « 002 ») n’apparaisse pas et remonte les tant redoutées erreurs 21106 et 20070 indiquant que l’agent n’est pas autorisé à communiquer avec son serveur :

clip_image001

clip_image002

clip_image003

Par contre, l’agent apparait bien lorsqu’on utilise powershell :

clip_image004

Get-SCOMPendingManagement |where {$_.agentname –like ‘xxx’}

Il est alors possible de l’approuver également via Powershell :

Get-SCOMPendingManagement |where {$_.agentname -like ‘xxx’} | Approve-SCOMPendingManagement

Et le tour est joué, l’agent parvient maintenant à communiquer :

clip_image005

Une astuce bien utile, même si elle ne devrait pas vous servir tous les jours!

Le fichier NetSetup.log

Bonjour à tous,

Qui n'a jamais rencontré d'échecs lors de la mise en domaine d'un poste ?

Les messages d'erreurs fournis à cette occasion ne sont pas forcément des plus explicites, ni des plus détaillés.

Heureusement il y a une solution et celle-ci s'appelle NetSetup.log

Vous trouverez ce fichier dans le dossier C:\Windows\debug.

Pour ce qui est de la structure du fichier, vous pouvez vous référer à la capture ci-dessous, mais voici un résumé des informations contenues dans celui-ci :

  • Nom du contrôleur de domaine contacté pour la jonction au domaine
  • Nom du site Active Directory détecté
  • Identifiants utilisés pour la jonction
  • OU de destination du poste
  • Résultats lors de la création de l'objet ordinateur (SPNs, Nom DNS, ... )
  • Etc ...

Bonne découverte !

 

Authentification SSO avec l'ADFS et Apache 2.5 (installé sur un linux)

Dans cet article nous allons apprendre comment permettre apache 2.4 (installée sur un linux) à communiquer avec l'ADFS pour faire de l'authentification SSO (Single Sign On)

Contexte 

Apache ne communique pas nativement avec l'ADFS. Pour permettre à des applications web qui tournent sur apache de faire de l'authentification SSO, il faudrait installer deux modules , auth_mellon et lasso , pour permettre la communication.  

Installation des modules nécessaires 

1. auth_mellon

« auth_mellon » est un module Apache qui permet l'authentification d'utilisateurs d'un site web avec un fournisseur d'identité (Identiy Provider — IdP) implémentant SAML 2.0. Il peut accorder des droits d'accès à des chemins et fournir des attributs à d'autres modules ou applications.

Téléchargement du module « auth_mellon » : https://packages.debian.org/fr/sid/libapache2-mod-auth-mellon (nom du paquet: libapache2-mod-auth-mellon) pour debian

Télécharger depuis https://packages.debian.org/fr/sid/libapache2-mod-auth-mellon le fichier *.deb pour l’installation du module « auth_mellon ».

Utiliser la commande suivante pour installer auth_mellon.

dpkg –i libapache2-mod-auth-mellon_0.9.1-1-bpo70+1_amd64.deb

Note: Installer toutes les dépendence liées à « auth_mellon » avant de continuer.

2. lasso

« lasso » est une bibliothèque de modules écrits en C avec des protocoles de communication pour des entités fédérées , SSO et autres produits identiques. Pour que lasso puisse fonctionner,il faudrait en plus de liblasso3, libxml2, XMLSec et OpenSSL. 

Lasso est disponible sur le site http://lasso.entrouvert.org/ en téléchargement en ajoutant la repository dans le fichier sources.list par exemple pour une debian.

deb http://deb.entrouvert.org wheezy main

Note: Installer toutes les dépendence liées à « lasso » avant de continuer.

Génération du fichier métadata *.xml, *.crt, *.key 

Pour la création d'une fédération (federation trust), l'ADFS nécessite le fichier de configuration du Service Provider (SP) qui est le serveur apache et ses applications. Ces fichiers sont créés par le script fournit ci-dessous: 

Le nom du script est mellon_create_metadata.sh et placer dans le dossier /etc/apache2/mellon

#!/usr/bin/env bash
set -e

PROG="$(basename "$0")"

printUsage() {
    echo "Usage: $PROG ENTITY-ID ENDPOINT-URL"
    echo ""
    echo "Example:"
    echo "  $PROG urn:someservice https://sp.mon-application.com/mellon"
    echo ""
}

if [ "$#" -lt 2 ]; then
    printUsage
    exit 1
fi

ENTITYID="$1"
if [ -z "$ENTITYID" ]; then
    echo "$PROG: An entity ID is required." >&2
    exit 1
fi

BASEURL="$2"
if [ -z "$BASEURL" ]; then
    echo "$PROG: The URL to the MellonEndpointPath is required." >&2
    exit 1
fi

if ! echo "$BASEURL" | grep -q '^https\?://'; then
    echo "$PROG: The URL must start with \"http://\" or \"https://\"." >&2
    exit 1
fi

HOST="$(echo "$BASEURL" | sed 's#^[a-z]*://\([^/]*\).*#\1#')"
BASEURL="$(echo "$BASEURL" | sed 's#/$##')"

OUTFILE="$(echo "$ENTITYID" | sed 's/[^0-9A-Za-z.]/_/g' | sed 's/__*/_/g')"
echo "Output files:"
echo "Private key:               $OUTFILE.key"
echo "Certificate:               $OUTFILE.cert"
echo "Metadata:                  $OUTFILE.xml"
echo "Host:                      $HOST"
echo
echo "Endpoints:"
echo "SingleLogoutService:       $BASEURL/logout"
echo "AssertionConsumerService:  $BASEURL/postResponse"
echo

# No files should not be readable by the rest of the world.
umask 0077

TEMPLATEFILE="$(mktemp -t mellon_create_sp.XXXXXXXXXX)"

cat >"$TEMPLATEFILE" <<EOF
RANDFILE           = /dev/urandom
[req]
default_bits       = 2048
default_keyfile    = privkey.pem
distinguished_name = req_distinguished_name
prompt             = no
policy             = policy_anything
[req_distinguished_name]
commonName         = "mon-application.com"
EOF

openssl req -utf8 -batch -config "$TEMPLATEFILE" -new -x509 -days 3652 -nodes -out "$OUTFILE.cert" -keyout "$OUTFILE.key" 2>/dev/null

rm -f "$TEMPLATEFILE"

CERT="$(grep -v '^-----' "$OUTFILE.cert")"

cat >"$OUTFILE.xml" <<EOF
<EntityDescriptor entityID="$ENTITYID" xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
  <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <KeyDescriptor use="signing">
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>$CERT</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </KeyDescriptor>
    <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="$BASEURL/logout"/>
    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="$BASEURL/postResponse" index="0"/>
  </SPSSODescriptor>
</EntityDescriptor>
EOF

umask 0777
chmod go+r "$OUTFILE.xml"
chmod go+r "$OUTFILE.cert"

Note : Changer le CommonName par le FQDN complet, exemple : mon-application.com.

le script se lance comme indique dans la commande ci-dessous: 

sh mellon_create.metadata.sh https://mon-application.com/url_application https://mon-application.com/mellon

L'exécution du script va générer 3 fichiers à envoyer à l'IDP pour la création d'une fédération:

  1. https_mon-application.com_url_application.cert
  2. https_mon-application.com_url_application.key
  3. https_mon-application.com_url_application.xml

Configuration du fichier auth_mellon.conf

Configurer le fichier auth_mellon.conf (etc/apache2/mod-available/auth_mellon.conf) comme dans l’exemple ci-dessous.

# MellonCacheSize sets the maximum number of sessions which can be active
# at once. When mod_auth_mellon reaches this limit, it will begin removing
# the least recently used sessions.
# Default: MellonCacheSize 100
#MellonCacheSize 100

# MellonPostDirectory is the full path of a directory where POST requests
# are saved during authentication. This directory must writeable by the
# Apache user. It should not be writeable (or readable) by other users.
MellonPostDirectory "/var/cache/apache2/mod_auth_mellon/"

<Location />
    # Add information from the mod_auth_mellon session to the request.
    MellonEnable "info"

    # Configure the SP metadata
    # This should be the files which were created when creating SP metadata.
    MellonSPPrivateKeyFile /etc/apache2/mellon/https_mon-application.com_url_application.key
    MellonSPCertFile /etc/apache2/mellon/https_mon-application.com_url_application.cert
    MellonSPMetadataFile /etc/apache2/mellon/https_mon-application.com_url_application.xml

    # IdP metadata. This should be the metadata file you got from the IdP.
    MellonIdPMetadataFile /etc/apache2/mellon/FederationMetadata.xml

    # The location all endpoints should be located under.
    # It is the URL to this location that is used as the second parameter to the metadata generation script.
    # This path is relative to the root of the web server.
    MellonEndpointPath /mellon
</Location>

# This is a location that will trigger authentication when requested.
<Location /sspi/sspi_test.php>
    # This location will trigger an authentication request to the IdP.
    MellonEnable "auth"
MellonSecureCookie On
</Location>
<Location /index.php>
    # This location will trigger an authentication request to the IdP.
    MellonEnable "auth"
MellonSecureCookie On
</Location>
<Location /index_prod.html>
    # This location will trigger an authentication request to the IdP.
    MellonEnable "auth"
MellonSecureCookie On
</Location>
<Location /autoconnect_mail.php>
    # This location will trigger an authentication request to the IdP.
    MellonEnable "auth"
MellonSecureCookie On
</Location>

MellonIdPMetadataFile = le fichier de fédération de l'IDP.

Il ne reste plus qu'à paramétrer l'application pour la connection et redirection automatique.

 

 

 

Active Directory : De l'importance de l'initialisation du SYSVOL lors d'un DCPROMO

Bonjour à tous,

Aujourd'hui, nous allons aborder l'initialisation du dossier SYSVOL lors de la promotion d'un contrôleur de domaine (ou "DCPROMO" pour les intimes).

Quelques précisions pour débuter

Tout d'abord, il convient de rappeler quelques informations à propos du dossier SYSVOL en lui même.

Ce dossier se divise en plusieurs sous-dossiers, dont les deux plus importants sont :

  • Policies : dossier qui contient tous les fichiers de définitions de toutes les GPO pour le domaine Active Directory concerné
  • Scripts : dossier qui contient tous les scripts/fichiers/installeurs que vous voulez utiliser dans des GPO ou autres. Ce dossier Scripts est partagé sous l'URI \\contoso.com\NETLOGON.

Le principe du dossier SYSVOL est d'être automatiquement répliqué entre tous les contrôleurs de domaine d'un domaine Active Directory via les mécanismes suivants :

  • FRS : mécanisme de réplication utilisé jusqu'à Windows Server 2003 R2. Il est à noter que lors d'une opération de mise à jour d'une Infrastructure AD, le mécanisme FRS reste en place même si le niveau fonctionnel du domaine est passé en 2008 R2. Il faut utiliser l'utilitaire Dfsrmig.exe pour mettre à jour manuellement le mécanisme de réplication vers DFS.
  • DFS : mécanisme de réplication utilisé à partir de Windows Server 2008. Utilise DFS-N pour la mise à disposition du dossier Sysvol sous la forme de l'URI \\contoso.com\SYSVOL et DFS-R pour la réplication des données du dossier.

En résumé, ce dossier SYSVOL est mis à disposition sur chaque contrôleur de domaine via les deux partages suivants :

  • SYSVOL : X:\SYSVOL\sysvol
  • NETLOGON : X:\SYSVOL\sysvol\contoso.com\SCRIPTS

Promotion d'un contrôleur de domaine

Le but de cette section n'est pas de revenir sur comment faire la promotion d'un contrôleur de domaine, mais plutôt de préciser ce qu'il se passe lors de cette promotion pour l'initialisation du dossier SYSVOL.

Le diagramme de flux ci-dessous nous présente les étapes d'une promotion d'un contrôleur de domaine. La partie qui nous intéresse se situe plus spécifiquement lors de l'étape Installation et après le redémarrage post-promotion du contrôleur de domaine.

Une fois les pré-requis validés dans l'assistant de promotion, la copie de toutes les partitions de l'annuaire AD est effectuée à partir de l'AD de référence (renseigné précédemment).

Lorsque la copie des informations des partitions de l'AD est complète, le nouveau contrôleur de domaine redémarre.

Pour ceux que cela intéresse, le détail de la promotion se situe dans le fichier de log suivant : %SystemRoot%\debug\DCPROMO.TXT

Pour ceux qui veulent encore plus de détails, vous pouvez allez voir le fichier de log : %SystemRoot%\debug\DCPROMOUI.TXT

Initialisation du dossier SYSVOL

On pourrait croire, suite au redémarrage du serveur, que celui-ci est devenu d'office contrôleur de domaine mais ce n'est pas le cas.

En effet, si les informations des partitions de l'AD ont été copiées, en revanche, le dossier SYSVOL lui n'a pas encore été initialisé.

Vous pouvez le constater en tapant la commande net share, les partages en question n'apparaissent pas.

Si vous faites un DCDIAG, vous verrez que les tests Advertising et Netlogons sont en échec, ce qui est normal à cette étape.

Si vous regardez la section Replication DFS de l'observateur d'événements, vous devriez apercevoir l'événement suivant (4614) :

Cet événement indique clairement que le dossier SYSVOL est en cours d'initialisation à partir du DC de référence indiqué lors de l'assistant de promotion et que ce serveur ne s'annoncera pas contrôleur de domaine tant qu'il n'aura pas fini l'initialisation de ce dossier.

Si tout se passe bien, au bout de quelques minutes/heures/jours (rayez la mention inutile), vous devriez voir l'événement suivant (4604) indiquant que le dossier SYSVOL s'est bien initialisé :

Si vous tapez la commande net share, les partages SYSVOL et NETLOGON apparaissent et un DCDIAG ne vous donne plus d'erreur sur les tests Advertising et Netlogons.

En conclusion, votre serveur est devenu un contrôleur de domaine pleinement fonctionnel.

Quand l'initialisation ne fonctionne pas

Malgré de nombreux cafés pris, il se peut que le dossier SYSVOL n'est toujours pas initialisé, ce qui se traduit par la présence de l'événement 4614 mais que vous attendez en vain l'événement 4604 dans l'observateur d'événements.

Une plus ample analyse des journaux de votre serveur ne vous donnera pas beaucoup d'aide sur les raisons de cette non complétion, mais en revanche, ceux du serveur partenaire de réplication le peuvent.

En regardant ces journaux sur le serveur partenaire, nous voyons que la cause de la non-réplication est un fichier du dossier SYSVOL resté en lecture seule. Cependant, ce n'est qu'un exemple parmi d'autres de points de blocage.

Pour débloquer la situation, à partir de ce constat, vous avez deux choix :

  • Résoudre le problème sur le serveur "source" pour la réplication
  • Dé-promoter le serveur et le re-promoter mais en choisissant comme contrôleur de domaine source un serveur fonctionnel au niveau de la réplication DFS

Suite à ces corrections, vous n'aurez plus qu'à "guetter" l'événement 4604.

Désormais, lorsque vos partages SYSVOL et NETLOGON sont manquants, vous n'aurez plus d'excuses !

Direct Access : configurer Manage-Out dans un environnement réel

 

Lors du déploiement de Direct Access, le gros de l’attention est communément porté sur la configuration des accès de l’extérieur vers l’intérieur ; ce qui est tout naturel dans la mesure où il s’agit de l’utilisation principale de la solution.

Cependant, Direct Access peut également permettre les accès depuis votre LAN vers les clients connectés depuis l’extérieur, ce qui peut s’avérer extrêmement utile par exemple dans les scénarios d’assistance à distance de vos utilisateurs : il s’agit de la fonction dite de “manage out”

Une problématique peut alors vite émerger : comme vous le savez forcément si vous vous êtes déjà intéressés au sujet, Direct Access ne fonctionne qu’en IPv6 et repose sur des technologies de transition (IPHTTPS, 6to4, teredo… selon les scénarios, le premier étant de loin le plus utilisé) pour que les clients qui passent par internet (donc quasi systématiquement en IPv4) puissent dialoguer votre LAN (lui aussi très souvent en IPv4).
Par contre, la seule possibilité concernant les flux du LAN vers l’extérieur est le déploiement du routage ISATAP, avec tous ses inconvénients.
Par ailleurs, dans le cadre d’un déploiement multisite ou utilisant du load-balancing (très fréquent en entreprise pour des raisons de haute disponibilité), Microsoft ne supporte plus ce type de routage (cf. https://technet.microsoft.com/en-us/library/dn464274(v=ws.11).aspx#bkmk_isa ).

La seule solution restante est donc l’IPv6 natif.

Comme il n’est généralement pas envisageable d’entreprendre une migration complète de votre infrastructure réseau vers IPv6 simplement pour répondre à cette problématique, la solution d’un ou plusieurs serveurs « de rebond » dédiés à l’accès vers les clients externes reste la plus pratique, à défaut d’être la plus élégante. Il peut également tout à fait s’agir directement de vos serveurs SCCM ou de toute autre solutions de prise en main à distance dont vous disposeriez.
Ces serveurs seront configurés avec des adresses IPv6 statiques, leur permettant de communiquer avec votre infrastructure DirectAccess.

I Attribution des IPv6

Sur un des serveur Direct Access, lancez un shell powershell en tant qu’administrateur et exécutez la commande

(Get-DAServer).InternalIPv6Prefix

clip_image001

Le préfixe IPv6 interne de votre déploiement Direct Access est donc ici xxxx:yyyy:967b:1::/64

Nous allons l’utiliser pour définir arbitrairement les IPv6 statiques de vos différents serveurs Direct Access et serveurs Manage Out :

xxxx:yyyy:967b:1::1 (premier serveur Direct Access)
xxxx:yyyy:967b:1::2 (second serveur Direct Access)
[…]
xxxx:yyyy:967b:1::10 (premier serveur de Manage Out)
xxxx:yyyy:967b:1::11 (second serveur de Manage Out)
etc.

Il reste ensuite à les attribuer à chaque serveur, de facon tout à fait classique :

Ouvrez les propriétés de la carte réseau concernée (carte « LAN » ou unique sur vos serveurs DA) puis sélectionnez le protocole IPv6 et cliquez sur Properties :

clip_image003

Indiquez l’IPv6 du serveur, le prefix length 64 et cliquez sur OK.

clip_image004

II Création des routes

Afin que les serveurs de Manage-Out puissent communiquer avec les clients DirectAccess, il est ensuite nécessaire de leur ajouter des routes statiques. En effet, selon le serveur DirectAccess auquel un client est connecté, il obtiendra une adresse IPv6 avec un préfixe distinct et le serveur de ManageOut a besoin de savoir par quel serveur DirectAccess il doit passer pour pouvoir atteindre le client.

Il est possible d’obtenir ce préfixe en exécutant la commande suivante sur n’importe lequel des serveurs DirectAccess :

(Get-DAServer).ClientIPv6Prefix

clip_image005

On obtient ici le préfixe xxxx:yyyy:967b:1000::/59. Le préfixe client a une longueur de 59 bits.

Néanmoins ce dernier est subdivisé en préfixes de 64 bits et chacun d’entre eux est affecté à un serveur DirectAccess. Ainsi, selon l’exemple ci-dessus, les clients connectés au premier serveur DirectAccess obtiendront le préfixe xxxx:yyyy:967b:1000::/64, ceux connectés au second serveur auront le préfixe xxxx:yyyy:967b:1001::/64 etc.

Il est donc nécessaire d’ajouter autant de route que de serveur DirectAccess sur chaque serveur de Management.

Pour ce faire, on exécute les commandes suivantes :

Netsh int ipv6 add route xxxx:yyyy:967b:1000::/64 “Nom de la carte réseau” xxxx:yyyy:967b:1::1

Netsh int ipv6 add route xxxx:yyyy:967b:1001::/64 “Nom de la carte réseau” xxxx:yyyy:967b:1:: 2

clip_image006

III Ajout du serveur de Management à Direct Access

Le serveur de Manage-Out doit ensuite être ajouté aux serveurs de Management dans Direct Access.

Cela présente par ailleurs un intérêt majeur : il devient ainsi accessible même lorsqu’uniquement le tunnel infrastructure est monté, c’est-à-dire même si l’utilisateur n’a pas ouvert de session sur son PC.
Il devient alors envisageable de gérer à distance le déploiement de paquets, la synchronisation de console antivirus avec une gestion dans le LAN etc.

Pour réaliser cette opération, se rendre dans la console « Remote Access Management » puis dans le menu « DirectAccess and VPN » en ayant pris soin de sélectionner la ferme DirectAccess (« Load Balanced Cluster »). Ensuite, il est nécessaire de cliquer sur le bouton « Edit » de l’étape 3.

clip_image008

Dans l’onglet « Management », faites un clic-droit sur la liste de serveurs et sélectionnez « Add ».

clip_image009

Entrez le FQDN du serveur de manage-out et cliquez sur OK

clip_image010

Cliquez sur Finish.

Enfin, cliquez sur Refresh Management Servers :

clip_image012

Vous devriez maintenant pouvoir accéder à vos clients depuis le LAN, en utilisant leur nom DNS ou leur IPv6 directement.

Attention toutefois, les clients connectés via DirectAccess ont le profil de firewall Windows « public » actif, il peut donc être nécessaire d’ouvrir les ports dont vous aurez besoin pour ce profil !

SOPHOS – Retour d’expérience sur la migration des agents antivirus depuis une gestion UTM SG vers Sophos Central

Introduction :

Cette article va vous montrer comment basculer d’un environnement de gestion SG vers un environnement de gestion Sophos Central.

Note : Les boitiers SG (ancienne gamme Sophos) permettent de jouer le rôle de “serveur antivirus”. 

Prérequis :

  • Accès à la console d’administration SOPHOS SG et SOPHOS Central.
  • Avoir créé ou importé vos utilisateurs dans SOPHOS Central.
    • Pour que les utilisateurs remontent dans Sophos Central il faut au préalable mettre en place l’outil de synchronisation Sophos.

Déploiement :

La première étape consiste à s’identifier sur SOPHOS XG et de désactiver la « Tamper protection » sur tous les utilisateurs.

Pour réaliser cette action la méthode la plus simple est de créer un groupe réunissant tous les utilisateurs à migrer et de désactiver la fonction :

clip_image002

La deuxième étape consiste cette fois ci à s’identifier sur SOPHOS Central et d’envoyer email d’installation aux utilisateurs concerné par la migration  :

clip_image004

La dernière étape quant à elle, est de lancer l’exécutable téléchargé à partir du mail reçu :

clip_image006

L’installation doit être lancé en tant qu’administrateur et prend environ 15 minutes. Pendant ce lapse de temps le logiciel va désinstaller l’ancien antivirus, télécharger le nouveau et l’installer.

Une fois l’opération fini vous allez voir un nouveau logo apparaitre :

clip_image007

Configuration

Sophos Central permet comme à l’instar de SOPHOS SG de créer des groupes pour gérer l’administration. Le plus avec SOPHOS central est qu’il distingue deux catégories. La première est « User and Computer Policies » et la seconde « Server Polices ».

Voici la liste des paramètres qui peuvent être modifié pour les deux catégories.

User and Computer Policies

Server Policies

clip_image009

clip_image011

Fonctionnalité Innovante

La nouveauté de Sophos Central est le module Intercept X qui contient plusieurs outils dont CryptoGuard qui empêche les ransomwares et la Root Cause Analysis.

La RCA permet en cas d’attaque subit d’analyser en profondeur et de donner les détails de l’attaque.

Pour accéder à cette l’interface il faut se rendre dans l’onglet « Root Cause Analysis » puis de sélectionner l’attaque souhaité.

clip_image013

Trois Onglet s’offre à vous.

Overview : Regroupant les informations essentielles de l’attaque QUOI, OU, QUAND et QUI.

clip_image015

Artifacts : Liste tous les fichiers, adresses IP, Processus, clé de registre et toutes les connexions que l’attaque ai touché. Que ce soit en lecture, écriture, connexion.

clip_image017

Visualize : Montre graphiquement comment l’attaque c’est propagé.

clip_image019

Il suffit ensuite de cliquer sur la bulle qui nous intéresse pour nous afficher le détail.

clip_image021