PI Services

Active Directory Federation Services ou ADFS est un service cœur de tout système d'informations. Les problèmes qui peuvent survenir entraînent la plupart des temps des interruptions de services directement visibles par les utilisateurs finaux. Il est alors essentiel d'identifier et de résoudre la panne au plus vite. ADFS diagnostic analyser est un outil produit par Microsoft qui permet d'analyser très simplement la conformité d'une ferme ADFS.

Installer le module PowerShell ADFSToolbox

ADFSToolbox est un module PowerShell qui permet d'exporter la configuration de serveurs ADFS. Il est conseillé de faire l'installation du module sur un serveur de la ferme ADFS pour s'affranchir des problématiques de communications réseaux. 

L'installation du module se fait via la commande PowerShell suivante :

Install-Module -Name ADFSToolbox -Force

Si la version ciblée d'ADFS est la version 2.1 ou inférieur, il faut utiliser la commande PowerShell suivante :

Install-Module -Name ADFSToolbox -RequiredVersion 1.0.13 -Force 

Les versions d'ADFS sont liées à la version de Windows Server de la machine virtuelle, ADFS 2.1 correspond à Windows Server 2012.

Si le module ne peut pas être installé en raison de problème de connectivité internet, l'article suivant explique comment procéder pour contourner cette restriction : Active Directory - Comment installer un module PowerShell sans connexion internet ?

Exporter la configuration de serveurs ADFS via le module PowerShell ADFSToolbox

Une fois le module installé, ouvrir une fenêtre PowerShell en tant qu'administrateur avec un compte administrateur du serveur ADFS et entrer la commande :

Import-Module -Name ADFSToolbox -Force #pour les versions ADFS 3.0 et suivantes

Import-Module -Name ADFSToolbox -RequiredVersion 1.0.13 -Force #pour les versions d'ADFS 2.1 et précédentes

Pour exporter la configuration d'un serveur ADFS, enter la commande PowerShell suivante :

Export-AdfsDiagnosticsFile -ServerNames @("adfs1.contoso.com", "adfs2.contoso.com") #remplacer adfs1.contoso.com et adfs2.contoso.com par les FQDN des serveurs ADFS, d'autres serveurs ADFS peuvent être ajoutés en les ajoutant à la suite des parenthèses

Export-AdfsDiagnosticsFile -ServerNames adfs1.contoso.com" #la commande peut être raccourci si on ne souhaite requêter qu'un seul serveur

Dans le cas d'un serveur Web Application Proxy ou WAP qui n'est pas joint au domaine Active Directory, entrer la commande PowerShell suivante depuis une fenêtre PowerShell locale au serveur (installation du module comme expliqué précédemment nécessaire) :

Export-AdfsDiagnosticsFile

Le fichier généré se trouve dans le dossier C:\Windows\System32 et se nomme AdfsDiagnosticsFile-[DateDuJour] ou [DateDuJour] correspond à l'heure et à la date à laquelle l'export a été réalisé.

Analyser l'export de la configuration ADFS avec ADFS diagnostic analyser

L'URL d'ADFS diagnostic analyser est la suivante : adfshelp.microsoft.com/DiagnosticsAnalyzer/UploadFile

Cliquer sur le point 3 - Diagnostic Analyzer > Select (choisissez le fichier AdfsDiagnosticsFile précédemment généré) > Upload a diagnostic file

Plusieurs tests sont effectués, focalisez vous sur les erreurs et notamment celles qui sont simples à résoudre, par exemple une expiration de certificat :

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.

Introduction

La gestion des identités en entreprise est une problématique de plus en plus importante. En effet, des thématiques telles que la mise en place d'un référentiel d'identité unique, le SSO (authentification unique), la gestion du cycle de vie d'un utilisateur (provisioning et deprovisioning, gestion du mot de passe, …) et bien d'autres deviennent essentielles dans des environnements toujours plus complexes et offrant plus de services. Il devient donc primordial d'intégrer des solutions permettant de gérer les identités au sein d'une entreprise. Cela permet notamment :

• d'automatiser des processus de gestions de comptes (exemple la saisie/modification/suppression d'un compte dans une base RH déclenche les actions nécessaires sur les infrastructures du système d'information)
• d'éviter les erreurs humaines de manipulations
• de réduire les tâches d'exploitation
• de n'avoir qu'un seul point d'entrée pour la saisie d'informations (référentiel RH par exemple, …)

Dans cette série d'articles, nous allons nous intéresser au composant Synchronisation Service de Forefront Identity Manager qui répond à un grand nombre de ces problématiques. L'objectif est de découvrir les possibilités offertes par cet outil. Pour cela, nous allons utiliser le contexte d'une société "MyCompany" souhaitant synchroniser les changements de son référentiel d'identité (une base de données SQL Server) vers l'annuaire Active Directory (synchronisation d'attributs). Aussi, nous verrons comme gérer le cycle de vie des objets tels que les utilisateurs ou les groupes via un mécanisme de Provisioning/Deprovisioning.

Ces articles vont s'articuler de la façon suivante :

• Partie 1 : Introduction, licensing, concepts
• Partie 2 : Installation de FIM Synchronisation Service
• Partie 3 : Configuration du Management Agent SQL
• Partie 4 : Configuration du Management Agent AD / Profil d'exécution
• Partie 5 : Administration de FIM / Gestion de la metaverse
• Partie 6 : Création d'une règle d'extension (transformation d'attributs)
• Partie 7 : Création d'une règle d'extension de la metaverse (provisioning)

Lors de cette troisième partie, nous allons nous attarder sur la configuration d'un Management Agent. Ceux-ci vont nous permettre d'interagir avec les nos différents systèmes. Dans notre cas, il s'agira d'une base de données SQL et d'un annuaire Active Directory. Au cours de cet article, nous verrons la configuration du Management Agent SQL. Nous aborderons les options offertes lors de la configuration d'un Management Agent. Une partie d'entre elles est commune à tous les Management Agent. Seule la synchronisation d'attributs sera traitée. Le provisioning ne sera abordé que lors de la dernière partie de cette série d'articles.

NB : En Août 2015, Microsoft a sorti une nouvelle version de la suite FIM, renommé pour l'occasion MIM (Microsoft Identity Manager) suite à l'abandon de la gamme de produits Forefront. Cette nouvelle mouture apporte quelques fonctionnalités supplémentaires. Cependant le contenu de ces articles restent valables.

Problématiques

Pour établir une synchronisation, il faudra tout d'abord définir les attributs traité par outil. Il n'est en effet pas obligatoire de synchroniser tout les attributs d'un objets. De même, nous verrons que nous ne sommes pas obligés de traiter tous les objets. Enfin, l'une des problématiques principales sera d'établir le lien entre les objets contenus dans l'annuaire Active Directory et ceux dans le référentiel RH (la base de données SQL).

Configuration du management Agent SQL

Pour cette étude de cas, nous allons commencer par la configuration du management agent SQL qui contient les données du référentiel RH à importer dans l'annuaire Active Directory. Pour rappel, les données vont transiter par la métaverse. Chaque objet de cette dernière aura des liens vers l'objet correspondant du connector space Active Directory et du connector space SQL (s'ils existent dans ces connector space). Je vous invite à relire la partie 1 si vous souhaitez revoir les concepts du service de synchronisation FIM.

Lancez la console Synchronisation Service Manager puis rendez-vous dans l'onglet Management Agents. Cliquez sur Create afin d'exécuter l'assistant de création de Management Agent.

Sur le premier onglet, vous pouvez définir le nom, une description ainsi que le type de Management Agent parmi une liste. Dans notre cas, nous choisissons le type SQL Server.

L'onglet suivant permet de définir la localisation des données ainsi que les informations d'authentification pour y accéder.

Ainsi, on peut définir le nom du serveur SQL et de la base de données. Il faut également indiquer le nom de la table ou de la vue SQL qui contient les informations. Attention, il n'est possible de spécifier qu'une seule table ou vue par Management Agent. Si vous souhaitez accéder à plusieurs tables / vues, il faudra créer plusieurs Management Agent ou alors créer une vue contenant l'union des données que vous souhaitez. Il est par ailleurs plus simple d'adapter son modèle de données en ajoutant des vues supplémentaires plutôt qu'en créant des managements agent qui vont alourdir l'exploitation et la maintenabilité du système.

Enfin, on spécifie un compte utilisateur permettant d'accéder aux données (ce dernier peut s'authentifier en SQL ou au travers d'une authentification intégrée Windows). Ce dernier doit pouvoir lire les données de la table spécifiée.

NB : Les informations optionnelles ne seront pas utilisées dans cet exemple. L'option Delta View permet de spécifier une vue contenant les changements depuis la dernière synchronisation complète. Cela permet d'effectuer des opérations de synchronisation différentielles. Dans le cas contraire et contrairement au Management Agent Active Directory, le Management Agent SQL ne réalisera que des synchronisation complètes. L'option Multivalue Table offre quant à elle la possibilité de gérer des champs pouvant contenir plusieurs valeurs. L'un des exemples les plus courants est l'attribution d'un manager à un collaborateur. En effet, un manager peut posséder plusieurs personnes sous sa responsabilité. Pour approfondir le sujet, je vous invite à lire l'article Technet suivant : https://technet.microsoft.com/en-us/library/cc708679(v=ws.10).aspx

L'assistant va ensuite tenter d'accéder aux données de la base SQL avec les informations fournies. Si l'opération réussie, nous obtenons un listing des différentes colonnes. On peut ensuite définir l'ancre via le bouton Set Anchor. En général, il s'agira de la colonne représentant l'ID car celle-ci sera unique au sein de la table. Enfin, il est possible d'indiquer un type. Ce dernier n'a pas de lien avec le type utilisé dans la metaverse. Il s'agit d'une chaîne de caractère.

L'onglet Configure Connector Filter permet de filtrer des objets en fonctions d'un critère comme la valeur d'un attribut. On peut imaginer le cas où on ne souhaite pas synchroniser les collaborateurs ayant le statut de travailleur détaché. Attention, les objets satisfaisants ces filtres sont exclues de la synchronisation.

Il est ensuite possible de configurer les règles de jointures (Join Rules) et de projection (voir partie 1). Pour rappel, les premières permettent de créer le lien entre un objet de la metaverse existant et celui du connector space. Pour ce faire on définit le type d'objets correspondant (il est possible d'indiquer la valeur Any si l'on souhaite chercher sur toute la metaverse), ainsi que l'attribut de la metaverse et du connector space qui doivent être identiques pour réaliser la jointure. Dans notre cas, j'ai réalisé la jointure sur le login utilisateur (samAccountName dans la base de données et accountName dans la metaverse).

Si plusieurs objets de la metaverse correspondent, vous rencontrerez alors des erreurs à moins d'avoir défini une règle de résolution qui nécessite un développement spécifique en C# ou en VB.Net. Il est important de définir la jointure sur des attributs uniques. Si vous souhaitez établir des jointures en vous basant sur plusieurs attributs, il faudra aussi écrire la règle en C# (ou VB.Net) au travers des règles avancées. Celles-ci seront détaillées plus précisément lors de la partie 6. Chaque Management Agent doit posséder au moins une règle de jointure.

NB : Plusieurs règles de jointures peuvent exister à la fois. Cependant, dès qu'une règle est satisfaite, une jointure est réalisée et les suivantes ne sont pas évaluées. Il est donc important de faire attention à l'ordre des règles (l'ordre de traitement se faisant par ordre croissant).

Concernant les règles de projection, il ne peut y en avoir qu'une par Management Agent. Il convient simplement de définir le type d'objet qui sera créé dans la metaverse si aucune règle de jointure n'a été satisfaite. Contrairement aux règles de jointure, il n'est pas obligatoire d'avoir une règle de projection par Management Agent. Cette dernière est en effet optionnelle.

La section Configure Attribute Flow configure le flux d'attributs entre l'objet dans le connector space (qui est une représentation de l'objet provenant du système connecté) et son équivalent dans la metaverse. Pour chaque information à synchroniser, on définit le nom de l'attribut source et de l'attribut cible ainsi que le sens du flux (Flow Direction) :

• Import : si la valeur de l'attribut est copiée de la base de données vers la metaverse
• Export : si la valeur de l'attribut est copiée de la metaverse vers la base de données (dans notre cas, il pourrait s'agir d'une valeur de l'annuaire Active Directory à copier vers la base de données)

Le champ mapping type permet de définir des règles directes s'il convient simplement de transposer l'attribut ou avancés. Le type Advanced permet de spécifier des règles personnalisées (via du développement C# ou VB.Net), une constante (une valeur toujours identique pour tous les objets) ou une référence de type distinguishedName (elle permet AAA).

Conformément à notre exemple, j'ai choisi de synchroniser sans transformation le nom, le prénom, le samaccountname, le status et le service d'appartenance de chaque collaborateur.

NB : Nous verrons dans un prochain article qu'il est possible de transformer des attributs ou d'en utiliser plusieurs pour définir une valeur cible au travers du mapping de type avancé.

L'avant dernière section (Configure Deprovisioning) définit les règles de suppression des objets d'un connector space lorsque le lien avec l'objet dans la métaverse n'existe plus (par exemple : lorsque l'objet est supprimé de la metaverse). Il existe quatre options :

• Make them disconnector : L'objet est marqué comme déconnecté. Il peut cependant être reconnecté ou recréé dans la metaverse lors de la prochaine synchronisation. Il s'agit du choix par défaut
• Make them explicit disconnectors : L'objet dans le connector space est déconnecté. Contrairement à la première option, il ne peut être reconnecté ou recréé qu'explicitement (par exemple via une action manuelle au travers de l'onglet Joiner que nous verrons dans la partie 5).
• Stage a delete on the objet for the next export run : Cette option indique que l'objet sera supprimé du système connecté lors de la prochaine opération d'export. Cette opération est donc destructrice.
• Determine with a rules extension : Il s'agit d'une règle développée en C# ou VB.Net qui déterminera lequel des trois états précédemment expliqués sera appliqué.

De plus, lorsque l'objet est supprimé du système (la base de données), il est aussi supprimé du connector space et déconnecté de la metaverse. Le comportement par défaut dans cette situation est de supprimer tous les attributs peuplés par le Managament Agent. L'option Do not recall attributes contributed by objects from this management agent when disconnected permet d'indiquer que les attributs fournis par un système ne seront pas supprimés de la metaverse lorsqu'il sera déconnecté. Dans notre exemple, cela pourrait être utile dans le cas où nous souhaiterions conserver le compte Active Directory et tous ses attributs (y compris ceux fournis par le référentiel RH) alors même que le compte a été supprimé du référentiel RH.

Enfin, la dernière étape de l'assistant ne serait pas utilisée dans cet article. Celle-ci permet d'indiquer le nom d'une DLL. Cette dernière contient toutes les règles personnalisées (de jointure, de flux attributs, etc) que nous aurions pu ajouter au cours de l'assistant (Ici, la case est grisée car nous n'en avons pas configuré).

Lors du prochain article, j’aborderai la configuration du management agent Active Directory ainsi que les profils d’exécution permettant d’exécuter les tâches de synchronisation.

Introduction

Avec le développement de l'authentification unique en entreprise, ADFS (Active Directory Federation Services) est devenu un rôle de plus en plus déployé. Même si son déploiement reste simple et très documenté (grâce notamment, au déploiement d'Office 365), il est courant de rencontrer des difficultés lorsque l'on souhaite ajouter une fédération ou réaliser une configuration spécifique.

Au cours de cette article, il sera question de résoudre une erreur pouvant se produire lors de l'ajout d'une fédération, c’est-à-dire lorsque l'on veut utiliser son système d'authentification d'entreprise avec un partenaire (une application SAAS par exemple). Généralement, les informations permettant d'établir une fédération sont contenues dans un fichier de métadata qui est accessible depuis une url ou qu'il faut importer via un fichier. Cependant, des erreurs dans le fichier de métadata fourni par le partenaire peuvent empêcher d'avoir une configuration correcte.

Problème rencontré

L'ajout d'une fédération s'effectue dans la console de gestion ADFS via l'action "Add relying party trust" dans le menu "Trust Relationships / Relying Party Trusts".

Lorsque l'assistant s'ouvre, il est possible de choisir la méthode de configuration de la fédération. Il existe trois méthodes :

• Une url d'accès au metadata : il s'agit de la méthode nécessitant le moins de maintenance. Les mises à jour des métadata sont prises en compte automatiquement. Si vous souhaitez fournir les vôtres via cette méthode (afin de faciliter la configuration pour le partenaire), il suffit d'ouvrir l'accès à l'url suivante https://NOM_DNS/federationmetadata/2007-06/federationmetadata.xml (n'oublier pas de remplacer NOM_DNS par le nom DNS d'accès au service ADFS).

• Un fichier de metadata : il s'agit d'un fichier fourni par le partenaire dont le contenu est identique à celui présent via la première méthode.

• Une configuration manuelle : il faut insérer chaque paramètre manuellement

La méthode qui nous intéresse ici et qui peut poser problème est la seconde. En effet, si le fichier contient des erreurs de syntaxe, le message suivant peut apparaitre :

Some of the content in the federation metadata was skipped because it is not supported by AD FS. Review the properties of the trust carefully before you save te trust to the ADFS configuration database.

Même si celle-ci n'est pas bloquante, elle peut entrainer une mauvaise configuration de la fédération.

Résolution

Les conseils ci-dessous sont issues de retour d'expérience. Lorsque l'erreur ci-dessus est rencontrée, il convient de modifier le fichier est de faire des tests de façon dichotomique afin d'obtenir une configuration valide. Par exemple, on peut supprimer les assertions une à une afin de trouver celle(s) qui posent problème. Il faudra ensuite vérifier si elle est nécessaire pour le bon fonctionnement de la fédération (auquel cas, un correctif devra être trouvé) ou si elle peut être supprimée.

La principale erreur rencontrée dans un fichier de métadata est la présence d'assertion pour plusieurs versions  de SAML. En effet ADFS supporte les standards SAML en version 1.0, 1.1 et 2.0 permettant d'échanger des informations avec un partenaire de manière sécurisée. Même si cela permet à un partenaire de ne maintenir qu'un seul fichier de métadata, ADFS ne tolère la présence que d'une version de SAML par fichier. Par exemple, la présence concomitante de ces deux assertions doit être proscrite :

Dans ce cas là, il suffira de supprimer les assertions en SAML v1.0.

D'autre part, une erreur courante est d'intégrer des URLs non sécurisées (HTTP au lieu de HTTPS). Cela n'est pas autorisé.

Dernière erreur courante, ADFS est permissif sur la syntaxe et plus précisément sur la casse des assertions. Ainsi, l'assertion suivante est invalide si HTTP-Redirect est remplacé par HTTP-REDIRECT.

Aussi, si vous souhaitez accéder à la syntaxe complète du langage SAML afin de valider un fichier de métadata, vous trouverez ci-dessous des liens détaillant la syntaxe selon la version :

• SAML v2 : https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf

• SAML v1.1 : https://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf

Introduction

Active Directory Federation Services (ADFS) permet de transmettre n'importe quel attribut d'un objet Active Directory à un partenaire par le biais d'une fédération. Cela reste facilement paramétrable via l'interface de gestion ADFS Management (ce paramétrage sera d'ailleurs détaillé dans la suite de cet article).

Cependant, il peut arriver que l'on souhaite transformer un attribut Active Directory en réalisant notamment des manipulations de chaines de caractères. Dans cet article nous étudierons le cas de l'attribut ObjectGuid qui est envoyé de manière encodée (en base 64) et dont le but sera de le transmettre sous la forme standard (exemple : {3F2704E0-4289-11D3-9B0C-0305E92C1301}). Il est aussi possible d'imaginer d'autres cas d'usage comme : mettre en majuscule un attribut, tronquer une chaîne de caractère...

Cette opération se réalise en deux étapes :

• Le développement d'une DLL contenant l'opération de transformation de l'attribut.

• Le déploiement de cette DLL sur un environnement ADFS. Cette dernière sera utilisé au travers d'un "custom attribute store" ADFS en conjonction avec une règle personnalisée de transformation de revendications lors de la configuration de la fédération.

Pour réaliser toutes ces manipulations, il est nécessaire d'avoir un environnement ADFS déjà opérationnel ainsi que Visual Studio (en version 2013 ou supérieure).

Les notions de développements abordées pendant cet article sont très accessibles y compris pour quelqu'un ne développant pas. Le langage utilisé est le C#.

En bonus, vous trouverez une petite application console permettant de tester les attributs retournés par vos fédérations.

NB : Cette article a été rédigé à partir d'une infrastructure ADFS 3.0 (Windows 2012 R2) et de Visual Studio 2015. Il est inspiré d'un article de Tino Donderwinkel : ici.

Fonctionnement

Tout d'abord, voici le principe de fonctionnement lorsqu'une nouvelle revendication doit être transmise à une fédération :

• Une règle basée sur le template LDAP récupère l'attribut AD que l'on souhaite transmettre.

• Une règle personnalisée traite la première revendication et la retourne dans une deuxième revendication après qu'elle ait subit sa transformation via une méthode appelée dans un custom attribute store

Le custom attribute store est composé d'une DLL qui contiendra toutes nos méthodes permettant de transformer des revendications. En effet, dans cet article nous modifions une revendication provenant d'un annuaire Active Directory mais celle-ci peut très bien être issue d'un autre référentiel puisque notre custom attribute store traite une revendication et non un attribut LDAP.

Le développement du custom attribute store nécessite d'implémenter des références à une DLL ADFS. Cela passe par l'ajout d'une DLL contenu dans le répertoire d'ADFS. Cette dernière contient 3 méthodes qu'il faut implémenter :

• Initialize : Elle permet de fournir des paramètres de configuration à l'attribute store. Elle ne sera pas utiliser dans notre cas.

• BeginExecuteQuery : Cette méthode contient une reqête sur l'attribute store. Cela sera modélisé par une méthode de transformation de notre attribut.

• EndExecuteQuery : Elle est appelé lorsque la méthode EndExecuteQuery a terminé son exécution. Elle prend en paramètre le résultat retourné par la méthode précédente.

Prérequis

Pour développer un nouvel attribute store, il faut copier la DLL nommée “Microsoft.IdentityServer.ClaimsPolicy.dll” depuis un serveur ADFS sur l'ordinateur où Visual Studio est installé (celle-ci est située dans “C:\Windows\ADFS”).

Développement

Lorsque le prérequis est rempli, nous pouvons lancer Visual Studio est créer un nouveau projet via le bouton “File” puis “New” et enfin “Project”.

Dans la section “template”, on choisit la catégorie Visual C# et le modèle bibliothèque de classes (“Class Library”). La version 4.5 du Framework .Net ainsi qu'un chemin pour stocker les fichiers doivent être définies.

Le fichier qui nous intéresse le plus et le fichier “Class1.cs” qu'il est possible de renommer via un clic droit puis “Rename” en oubliant pas de valider la popup suivante permettant de modifier toutes les références à ce fichier dans notre projet.

Nous devons ensuite ajouter des références à notre projet. Pour rappel, ces dernières vont nous permettre de communiquer avec l'infrastructure ADFS en joignant entre autre la DLL précédemment copiée (“Microsoft.IdentityServer.ClaimsPolicy.dll”).

Cette première dépendance s'ajoute en effectuant un clic droit sur le champ “References” dans le menu de droite (Solution Explorer) puis en cliquant sur “Add Reference”.

Il faut choisir l'onglet “Browse” et enfin se rendre à l'emplacement de la DLL et la sélectionner

La seconde dépendance s'ajoute de la même manière Il s'agit de “System.IdentityModel”. Il est seulement nécessaire de se rendre dans le menu “Assemblies” au lieu de “Browse”.

Enfin, on ajoute les lignes de codes ci-dessous dans le fichier de classe.

Cela permet d'indiquer les références utilisées dans la classe.

Une fois les références ajoutées, il faut implémenter les méthodes explicitées dans le paragraphe précédent. Pour se faire, on doit ajouter ce qu'on appelle une interface à notre classe. Cela nous donnera accès aux méthodes permettant d'interagir avec ADFS. Notre classe représente l'attribute store que l'on souhaite créé.

Pour ajouter l'interface, il suffit d'ajouter “ : IAttributeStore” après “public class CustomStringAttributeStore”. Un avertissement est levé car Visual Studio ne trouve pas le code permettant de dire que notre classe est un attribute store (il cherche les 3 méthodes évoquées précédemment). Pour corriger cela, il suffit de faire un clic droit sur “IattributeStore” puis de cliquer sur “Implement Interface”. Le code de base pour les 3 méthodes est automatiquement généré.

Ci-dessous, vous trouverez le code pour chacune d'entre elles.

Initialize :

BeginExecuteQuery :

Il s'agit de la méthode où se déroule toute la logique de transformation. La section la plus importante est contenue à l'intérieure de la structure logique Switch. En fonction de la requête demandée, une transformation sera appliquée. Dans notre exemple, je n'ai qu'un seul cas possible, mais on peut améliorer cet attribute store afin qu'il contienne toutes les règles de transformations dont nous avons besoin.

NB : Une méthode Base64ToGuid est appelée dans le case Base64ToGuid. Cette méthode permet de convertir en chaîne lisible, le Guid d'un objet AD qui est normalement encodé en base 64.

EndExecuteQuery :

Le lien suivant mène vers le code complet de la classe : ici

Il suffit ensuite de générer la DLL en passant par le menu “Build” puis en cliquant sur “Build Solution”. La DLL est générée dans le sous répertoire “bin\Debug” du projet défini lors de la création. Par défaut il s'agit du chemin “C:\Users\nom_d'utilisateur\Documents\Visual Studio 2015\Projects”.

Déploiement

Une fois la DLL copiée, il faut la copier sur tous les serveurs ADFS dans le répertoire “C:\Windows\ADFS” (Attention : La DLL ne doit pas être déployée sur les serveurs Web Application Proxy). On peut ensuite passer à la configuration qui se fait via la console ADFS Management.

Configuration du Custom Attribute Store

Dans la section "Trust Relationship", effectuer un clic droit sur “AttributeStore” et cliquer sur “Add Custom Attribute Store”.

Une popup s'ouvre. Il faut renseigner le champ “Custom attribute store class name”. Ce champ doit être rempli avec attention et nécessite une syntaxe particulière :

Namespace.Classe,Nom_du_fichier_dll

Namespace : il s'agit du nom indiquer à côté de ce mot clé dans notre fichier de classe (Ici : CustomStringTransformAttributeStore).

Classe : Le nom de la classe (Ici : StringTransform)

Nom_du_fichier_dll : le nom de la DLL sans son extension (ici : CustomStringTransformAttributeStore)

Lorsque la configuration est validée, un évènement 251 apparait dans le journal Admin d'ADFS (dans la catégorie Applications and Services de l'observateur d'évènements). Lorsqu'il y a une erreur de configuration, un évènement avec l'ID 159 est présent.

Configuration de la fédération de test

Nous allons maintenant créer une fédération de test. Celle-ci ne doit pas forcément pointer vers un service réel. L'outil fourni dans le chapitre suivant permettra de générer des tokens. Dans la section Trust Relationship, il faut se rendre dans la section “Relying Party Trusts” puis choisir l'option “Add Relying Party Trust”.

Cliquez sur le bouton “Start” après l'ouverture de l'assistant. Choisir l'option “Enter data about the relying party manually”.

Insérez un nom pour la fédération puis cliquez sur “Next”.

Cliquez sur “Next” sur les onglets suivants jusqu'à “Configure Identifiers”. Entrez une url dans le champ “Relying party trust identifier” puis cliquez sur “Add”. Cette url n'a pas besoin de répondre.

Il faut ensuite cliquez sur suivant jusqu'à la fin de l'assistant en laissant cocher la case “Open the Edit Claim Rules dialog for this relying party trust when the wizard closes”. Cela nous permettra d'ajouter nos règles sur les revendications dès la création de la fédération (sinon, il vous faudra faire un clic droit sur la fédération et choisir “Edit Claim Rules”).

Dans l'assistant d'édition des règles de revendications, nous allons ajouter deux règles dans l'onglet “Issuance Transform Rules”. Pour se faire cliquez sur “Add Rule”.

Dans l'assistant, nous ajoutons une première règle qui va récupérer un attribut LDAP. On sélectionne donc le modèle “Send LDAP Attributes as Claims”.

On peut ensuite définir un nom puis choisir “Active Directory” en tant qu'attribute store. Enfin, on entre l'attribut LDAP qui nous intéresse pour la colonne “LDAP Attribute” (il peut être inséré à la main s'il n'est pas présent dans la liste comme c'est le cas pour “objectGUID”) puis on choisit une valeur pour “Outgoing Claim Type” (ici, j'ai choisi “Common Name”).

On ajoute ensuite une seconde règle qui va utiliser notre custom attribute store. Cette fois-ci le template à utiliser est “Send Claims Using a Custom Rule”. On défini ensuite un nom et on peut insérer le code suivant dans le champs “Custom Rule”.

Cette règle récupère la revendication “CommonName” que nous avons défini précédemment en tant que revendication de sortie de notre annuaire Active Directory et la transmet à notre custom attribute store (elle est retournée en tant que revendication de type “nameidentifier” en lui appliquant la méthode Base64ToGuid qui correspond au cas que l'on a défini dans notre classe “Transform.cs”. Il est bien entendu possible de changer les revendications, la requête ou le nom du custom attribute store en fonction de vos valeurs.

Test

Afin de tester vos fédérations, je met un outil console à disposition que j'ai développé et que vous pouvez récupérer via le lien suivant : ici. Il sera utile pour valider le bon fonctionnement de notre custom attribute store mais il vous permettra aussi de voir les revendications envoyées à vos partenaires pour n'importe laquelle de vos fédérations. En plus de ce dernier vous devez avoir dans le magasin racine de confiance, le certificat permettant de signé les tokens d'authentification (Token-Signing). Dans un déploiement par défaut, il est auto-signé.

L'outil est composé d'un .exe et d'un fichier .config. Ce dernier doit être rempli. Les paramètres à changer sont :

• relyingPartyId : il s'agit de l'url d'accès à la fédération (le champ "identifier") : https://adfstest.myenterprise.com/adfs/services/trust.

• adfsEndpoint : il s'agit du point d'accès pour effectuer l'authentification (exemple : https://fs.myenterprise.com/adfs/services/trust/13/windowsmixed). Le programme se base sur l'authentification windows. L'url “/trust/13/windowsmixed” doit être active sur l'infrastructure ADFS. Pour se faire, il faut se rendre dans la catégorie “Endpoints” de la console de gestion ADFS, puis effectuer un clic droit et choisir “Enable” sur cette url.

• certSubject : La valeur doit être celle du champ objet du certificat de type Token-Signing. Exemple : CN = ADFS Signing - fs.myenterprise.com.

Une fois l'outil paramétré, il suffit de le lancer l'exécutable. Ce dernier affiche toutes les revendications par un couple "Nom de la revendication : valeur". Voici un exemple de résultat obtenu :

On remarque qu'on obtient bien les deux revendications représentant le GUID, l'une le représentant sous forme d'une chaîne de caractère et l'autre encodé en base 64 (la revendication originale). Notre custom attribute store est donc bien opérationnel.

Si l'on souhaite ajouter de nouvelles transformations de revendications, il suffit maintenant d'ajouter des cas supplémentaires dans la classe et de la redéployer.

Introduction

Le répertoire SYSVOL est répliqué entre tous les contrôleurs d'un domaine Active Directory. Celui-ci peut être répliqué par FRS (File Replication Service) ou DFS-R (Distributed File System Replication). FRS devient petit à petit obsolète et il convient de migrer vers DFS-R dès que tous les contrôleurs de domaine (DC) utilisent Windows 2008 ou supérieur. Il existe d'ailleurs une procédure fortement documenté par Microsoft pour effectuer cette bascule (https://technet.microsoft.com/en-us/library/dd640019(v=WS.10).aspx). En effet, DFS-R est beaucoup plus robuste et performant.

Cependant, celui-ci peut aussi rencontré des problèmes et la réplication peut se retrouver en erreur avec certains contrôleur de domaine. Lorsque cet incident survient, les stratégies de groupes (GPO) ou les scripts d'ouverture de session (ou de démarrage d'ordinateur) ne sont plus forcément en accord avec la dernière version mise en place. Pire, une stratégie de groupe récemment créée peut ne pas exister sur un contrôleur de domaine. On rencontre alors des erreurs d'application des GPOs sur des postes clients, serveurs ou utilisateurs. Pour pallier à ce problème, il existe une procédure permettant de resynchroniser la totalité (restaurer) du répertoire SYSVOL depuis un contrôleur de domaine valide.

Nous allons voir comment repérer les contrôleur de domaine dont la réplication DFS-R du SYSVOL est en erreur, puis nous aborderons le sujet de la restauration non autoritaire (principe expliqué ci-dessous) du répertoire SYSVOL.

Diagnostic

Pour repérer si un contrôleur de domaine ne réplique plus correctement le répertoire SYSVOL, il existe une multitude de méthodes. Tout d'abord, il suffit de comparer le contenu des dossiers SYSVOL de plusieurs contrôleurs de domaine. Si l'un d'entre eux est vide ou qu'il n'y a pas les mêmes objets alors il y a des problèmes de réplication DFS-R du répertoire SYSVOL.

Il existe aussi des techniques plus fiables. Tout d'abord, dans une invite de commande depuis un contrôleur de domaine, on peut exécuter le script ci-dessous :

Ce dernier affiche un statut de la réplication DFS-R pour chaque contrôleur de domaine. Le chiffre affiché pour chaque DC nous donne l'information. Lorsqu'il y a une erreur celui-ci possède la valeur 5 (une réplication sans erreur équivaut à un statut 4). Aussi, il peut arriver que la valeur soit “No instance avalaible”. Cette information indique qu'il n'y a donc pas de réplication du SYSVOL.

On peut confirmer une erreur de réplication DFS-R (ou même une absence de réplication du SYSVOL) via la recherche d'événements spécifiques dans l'observateur d'événements. Ceux-ci sont situés dans le journal “DFS Replication” et non dans les journaux Active Directory. Il faut rechercher les événements avec les IDs suivants :

• 2012

• 2013

• 4012

Event 2012

L'événement 2012 nous informe d'une erreur de réplication DFS lors d'un arrêt non prévu du serveur (coupure de courant). Si cet événement n'est pas accompagné d'un événement avec l'ID 2013 alors la réplication a repris son cours normal et ne nécessite pas d'action (vous devriez néanmoins obtenir un statut 4 avec la commande précédente pour confirmer cela).

Event 2013

Cet événement indique que la réplication n'a pas repris et qu'il convient de le faire manuellement via la commande suivante :

NB : Pensez à remplacer GUID_VOLUME par le votre. Pour cela, il suffit de copier coller la commande indiqué dans l'événement pour relancer la réplication du répertoire SYSVOL. Cependant, si celle-ci n'a pas été relancé depuis longtemps alors elle ne redémarre pas et on obtient l'événement 4012.

Pour information, les management packs SCOM AD ou DFS ne remontent pas ce type d'erreur.

Event 4012

En effet, lorsqu'une réplication DFS-R a été stoppé pendant plus de 60 jours (valeur par défaut du paramètre MaxOfflineTimeInDays) alors il est nécessaire de lancer une synchronisation complète du dossier répliqué. L'événement donne une procédure qui peut s'appliquer dans le cas où il s'agit d'une réplication DFS-R créé par un administrateur. Néanmoins celle-ci n'est pas applicable dans le cas du répertoire SYSVOL car nous n'avons tout simplement pas accès à cette réplication via la console DFS Management. Il faut alors réaliser une restauration du répertoire SYSVOL.

Procédure de restauration

Cette procédure n'est pas compliquée mais nécessite de la rigueur afin de rétablir la réplication Active Directory du répertoire SYSVOL. Toutefois, celle-ci ne s'applique que lorsque le nombre de contrôleurs de domaine en erreur est faible et que l'on est sûr que celui-ci répliquera le répertoire SYSVOL depuis un contrôleur de domaine sain. Par exemple, cela peut être le cas dans une topologie en étoile lorsque un ou plusieurs contrôleurs de domaine présent sur des sites distants ne répliquent plus le répertoire SYSVOL.

Dans le cas où l'on souhaiterait restaurer le dossier SYSVOL depuis un contrôleur de domaine précis et restaurer tous les autres DC alors il convient de réaliser une restauration autoritaire du SYSVOL (la restauration est forcé depuis un contrôleur de domaine précis et la réplication DFS-R est coupé temporairement sur les autres DC).

Lors de l'exécution du processus ci-dessous, on ne choisit pas un contrôleur de domaine comme source de la restauration, cette dernière est donc dite non autoritaire. Il n'existe pas véritablement de règle pour savoir s'il faut préférer une restauration autoritaire ou non. Cela dépendra donc des cas (pourcentage de DC en erreur, topologie Active Directory complexe). Microsoft recommande toutefois de réaliser une restauration autoritaire dès qu'il y a plus d'un DC qui rencontre ce type de problème (dans des gros environnements cela peut vite devenir compliqué à mettre en œuvre et une restauration non autoritaire peut rester une solution viable).

Pour réaliser une restauration non autoritaire, il faut lancer ADSIEdit avec un compte administrateur du domaine.

Il faut ensuite effectuer un clic droit sur ADSI Edit puis choisir l'option “Connect To”.

Dans les paramètres de connexion il faut choisir de se connecter au contexte d'attribution de noms par defaut (Default Naming Context) et valider.

Enfin, il faut naviguer jusqu'à l'objet du contrôleur de domaine posant problème (Exemple de chemin : CN=DC01,OU=Domain Controllers,DC=myenterprise,DC=com) puis se rendre dans le conteneur “DFSR-LocalSettings” puis “Domain System Volume”.

Sur ce dernier, il faut effectuer un clic droit puis choisir “Properties”. Il faut ensuite trouver l'attribut “msDFSR-Enabled” et passer la valeur à “False” (cette dernière doit être à “True” par défaut). Cela permet de rendre le contrôleur de domaine non authoritaire pour la réplication.

Par la suite, on force une réplication Active Directory depuis un DC sain via l'outil en ligne de commande repadmin :

Sur le DC en erreur, on exécute la commande ci-dessous qui aura pour effet de désactiver la réplication du répertoire SYSVOL :

Un événement avec l'ID 4114 doit être présent dans le journal “DFS Replication” de l'observateur d'événement du contrôleur de domaine en erreur dont voici le contenu :

Nous pouvons maintenant réinitialiser la réplication du répertoire SYSVOL. Dans ADSI Edit, il faut éditer de nouveau l'objet “Domain System Volume” du contrôleur de domaine en erreur et remettre la valeur de l'attribut “msDFSR-Enabled” à “True”.

Il suffit ensuite de forcer une réplication Active Directory depuis un DC sain via l'outil en ligne de commande repadmin :

Puis, on lance une réplication initiale du répertoire SYSVOL depuis le DC sur lequel on effecture une restauration via la commande :

Un premier événement de type avertissement doit être visible dans le journal “DFS Replication”. Celui-ci possède l'ID 4614. Il indique que la réplication Active Directory s'est lancée.

Lorsque la réplication est terminée, un second événement avec l'ID 4604 indique la bonne exécution de celle-ci.

Enfin, on peut vérifier le statut de la réplication du répertoire SYSVOL du contrôleur de domaine via la commande suivante :

NB : Pensez à changer NOM_DC par le nom du contrôleur de domaine à tester.

Introduction

Cet article a pour but d'expliquer la gestion des photos dans l'annuaire Active Directory via une intégration par un script Powershell. En effet, le référentiel photo d'une entreprise ne respecte pas forcément les préconisations Microsoft. Grâce à un script, nous allons voir comment les respecter et peupler un annuaire Active Directory. La solution proposée permettra d'automatiser le processus en s'affranchissant d'outils tiers qui peuvent réaliser cette opération.

Solution

L'attribut AD permettant de renseigner la photo est thumbnailPhoto. Il y a plusieurs restrictions sur une image de profil :

• la résolution est limitée à 96x96 pixels
• la taille ne doit pas éxéder 100Kb

La valeur stockée dans l'attribut thumbnailPhoto est un tableau de bytes.

La solution proposée utilise des classes .Net issue de System.Drawing. Ainsi, on va pouvoir redéfinir la taille d'une image, la centrer et éventuellement définir la qualité si la photo est trop lourde. Afin d'être le plus portable possible, le script interroge Active Directory via ADSI pour réaliser la modification de l'attribut thumbnailPhoto.

NB : Depuis la V15 des produits d'infrastructure Microsoft et grâce au couple Exchange 2013/Lync 2013, il est possible de stocker des photos d'une résolution de 648*648 pixels directement dans la boîte aux lettres de l'utilisateur. Cette dernière est accédée directement via les Exchange Web Services par Lync. Une copie d'une résolution de 48x48 est toujours stockée dans l'attribut thumbnailPhoto.

Script

Le script permet de rendre conforme la photo d'un utilisateur et de la placer sur l'objet Active Directory dans l'attribut thumbnailPhoto. Pour chaque utilisateur, il est nécessaire de renseigner les paramètres suivants :

• le samaccountname de l'utilisateur
• le dossier contenant la photo
• le nom du fichier photo
• l'extension du fichier photo

Pour vérifier que l'opération s'est correctement exécutée, il suffit de vérifier dans la console Active Directory Users and Computers que l'utilisateur possède bien une valeur pour l'attribut thumbnailPhoto (via l'éditeur d'attribut). La photo peut ensuite être consultée via Outlook (pour les messageries Exchange) ou le client Lync.

Ce script s'exécute utilisateur par utilisateur. Il est possible d'imaginer une logique de traitement "en masse".

Préambule

L'ensemble des manipulations ont été réalisées sur une infrastructure Windows 2012 R2 / ADFS 3.0.

Problématique

Avec quelques connaissances en développement web (CSS et Javascript), il est possible de customiser les pages de logon ADFS. On peut positionner un logo qui remplacera le nom de la federation ou encore changer l'illustration par défaut. De plus, Microsoft offre aussi la possibilité de changer une partie du code Javascript et CSS. Nous verrons donc comment gérer ses templates ADFS puis je détaillerai un script Javascript permettant d'ajouter automatiquement le suffixe UPN de l'utilisateur. Ainsi toute personne souhaitant se connecter n'aura qu'à entrer son samAccountName. Attention, cette méthode n'est fonctionnelle que dans le cas où tous les utilisateurs possèdent le même suffixe UPN.

Gestion des templates ADFS

Microsoft fourni quelques indications pour customiser les pages ADFS sur le lien suivant :
http://technet.microsoft.com/en-us/library/dn280950.aspx . On retrouve notamment les modifications les plus basiques comme les changements d'images ou de messages (erreur, aide,...).

Aussi, dans ADFS 3.0, il est possible de gérer plusieurs templates via les Cmdlets Powershell adéquates. Le template de base se nomme "default". On peut d'ailleurs récupérer la liste des thèmes avec la Cmdlet Get-ADFSWebTheme. On remarque qu'il s'agit bien du template de base grâce à l'attribut IsBuiltinTheme.

Les étapes de customisation d'un thème sont les suivantes :

• création d'un nouveau thème 
• export des fichiers du thème 
• modification des fichiers 
• import des fichiers modifiés dans le thème créé

Pour ajouter un nouveau thème il suffit d'utiliser la commande New-AdfsWebTheme en spécifiant le nom du thème ainsi que les sources du nouveau thème. En général, on se basera sur le thème par défaut que l'on customisera ultérieurement.

Il nous faut ensuite exporter les fichiers de ce thème (vers le dossier C:\ADFSTheme par exemple) :

Attention le dossier d'export doit exister (il ne sera pas généré automatiquement).

On remarque que l'on a accès à un certain nombre de fichiers mais pas à tous. En général, ceux que l'on voudra customiser sont le fichier onload.js et le fichier style.css.

Une fois modifiée, il ne reste plus qu'à importer le fichier dans le thème nommé custom. Un exemple avec le fichier onload.js :

Enfin pour définir le thème custom comme actif il faut utiliser la Cmdlet ci-dessous :

Ajout automatique du suffixe UPN

Afin de faciliter l'expérience utilisateur lors d'un usage en situation de mobilité ou via un navigateur ne supportant pas ADFS, il peut être utile d"ajouter automatiquement le suffixe UPN lorsque ce dernier a été omis dans le formulaire d'authentification. Pour les utilisateurs ne connaissant pas les notions de nom de domain Netbios ou d'UPN, cette customisation peut être interessante. Celle-ci nécessite du code Javascript.

ADFS se base sur la valeur entrée dans le champ “UserName” avec l’ID “userNameInput” du fomulaire. Il faut donc modifier cette valeur. Une autre solution (utilisée ici), consiste à changer l’ID et le nom du champ original. Puis, on ajoute un nouveau champ, invisible à l’utilisateur et contenant la bonne valeur ainsi que l’ID et le nom mentionné précédemment. Cette seconde solution est esthétiquement plus réussi (l’utilisateur ne voit pas le changement)

Ci-dessous, se trouve le script a ajouté à la fin du fichier onload.js est à intégrer dans le thème ADFS via la méthode vu précédemment :

Voici les opérations réalisées par le script lorsque le formulaire est valider (via la touche “Entrée” ou un clic sur le bouton de connexion) :

• Récupération du champ contenant l’identifiant utilisateur
• Vérification de la présence d’un suffixe UPN

Si le suffixe est manquant :

• On renomme le champ contenant l’identifiant utilisateur (UserName) et on change son ID (userNameInput).
• On ajoute un nouveau champ non visible portant les valeurs initiales (Id et nom). Il contiendra la valeur entrée par l’utilisateur avec le suffixe UPN. Celles-ci seront transmises à ADFS.

Une amélioration pourrait être d'ajouter une balise “select” contenant une liste de tous les suffixes UPN possibles. Cela permettrait de gérer les infrastructures utilisant de multiples suffixes UPN.

L’une des principales utilité des GPOs est d’automatiser des tâches sur un large panel d’utilisateurs (ou d’ordinateur) évitant ainsi à l’administrateur de perdre un temps précieux…

Le déploiement des imprimantes fait partie de ces tâches qui peuvent être un tracas logistique sans l’utilisation des GPOs.

La première étape est la création d’une nouvelle GPO à l’aide de la console “Group Policy Management” dans l’OU où celle-ci s’appliqueras :

Une fois la nouvelle GPO créée, ouvrez la console “Print Management”, sélectionnez l’imprimante à déployer via GPO et cliquez sur “Deploy with Group Policy” :

La fenêtre “Deploy with group policy” apparait, cliquez sur “Browse” puis sélectionnez la GPO créée puis cliquez sur OK :

Les habitués des GPOs savent sans doute qu’une GPO peut être appliquée au niveau utilisateur, ordinateur ou les deux.

Ce choix dépend de votre organisation interne, j’ai pour ma part choisi le déploiement par utilisateurs :

Il faut ensuite cliquer sur “Add” puis sur OK.

A ce niveau l’imprimante est déployée sur les clients à partir de Windows Vista.

Pour la gestion des clients XP, il est nécessaire de passer par une étape supplémentaire car contrairement aux client 7, Vista et 8 qui utilisent “gpprnext.dll” les clients XP et les serveurs antérieurs à Windows Server 2003 utilisent PushPrinterConnections.exe.

Retournons dans la console Group Policy Management.

Sélectionnez la GPO et éditez là :

Sous “User Configuration” (ou Computer Configuration en fonction du choix d’application de la GPO fait plus haut), allez dans “Windows Settings” puis “Scripts” :

Dans les propriétés du “Logon”, cliquez sur “Add” puis dans “Script Name” choisir PushPrinterConnections.exe (que l’on trouve dans le dossier SYSWOW64 sur Windows Server 2008R2) et dans les paramètres du script tapez “-log” :

Au prochain Logon, vos utilisateurs auront l’imprimantes d’installée sur leur poste, ce sans même que l’administrateur n’ait eu à se déplacer !

Dans les nouveautés de Windows Server 2012 l’interface graphique de gestion granulaire de mot de passe vient simplifier le travail de l’Administrateur en lui évitant de passer par les GPO et ADSIEdit.

La gestion granulaire des mots de passe est déjà disponible depuis Windows Server 2008, un niveau fonctionnel de 2008 suffit donc pour bénéficier de l’interface graphique sur un serveur 2012.

Avant de commencer : il est très probable que dès la mise en place de la stratégie vos utilisateurs aient à changer de mot de passe, or certaines applications ne peuvent le gérer, je vous conseille donc d’appliquer la stratégie une fois vos utilisateurs délogué.

Dans le Server Manager, lancer le tool “Active Directory Administrative Center” :

Une fois lancé, basculer en vue arborescente (Tree View), puis dans le dossier System, double-cliquer sur le dossier “Password Settings Container”

Pour créer une nouvelle politique de mot de passe, sélectionner dans l’onglet de droite : New –> Password Setting

Nous arrivons alors sur cette fenêtre et l’on remarque que Windows Server 2012 se veut intuitif :

Les textbox précédés d’un astérisque rouge sont des éléments requis pour la création de la stratégie.

Parmi ces éléments, il y a le champ “Precedence”, qui permet – dans le cas déconseillé ou plusieurs stratégies s’appliquerait aux mêmes utilisateurs ou groupes – de gérer quelle stratégie s’applique en priorité.

Une fois le paramétrage terminé, cliquer sur “Add” et la stratégie est immédiatement exécutée pour les utilisateurs concernés.