Bonjour
DESCRIPTION DU BESOIN :
La direction souhaite donner accès à des ressources internes à des utilisateurs externes à sa société (partenaire sur un projet, client).
Les utilisateurs externes ne doivent pas pouvoir accéder aux données confidentielles de l’entreprise (sur les serveurs de fichiers, données RH…).
Je pars du principe que l’entreprise dispose d’un annuaire Active Directory existant avec 1 domaine dans 1 forêt (pour les utilisateurs de la société) appelé MSREPORT.INTRA. Tous les serveurs d’entreprise sont sous Windows et sont membres du domaine MSREPORT.INTRA.
Les utilisateurs doivent pouvoir accéder à des serveurs de fichiers, des serveurs SharePoint (extranet) et du serveur Terminal Server / Citrix (serveurs applicatifs) ainsi qu’à des applications web.
Nous allons voir dans cet article comment restreindre les accès à des utilisateurs externes au niveau des mécanismes d’authentification. Nous ne traiterons pas des autres mécanismes : mise en place de restrictions au niveau du réseau d’entreprise, politique d’authentification forte avec archivages des connexions.
ARCHITECTURE CIBLE POSSIBLE :
Généralement, 5 solutions sont proposées :
– Scénario 1 : Créer les comptes des utilisateurs externes dans le domaine interne.
– Scénario 2 : Créer les comptes des utilisateurs externes dans autre domaine dans la même forêt.
– Scénario 3 : Créer les comptes des utilisateurs externes dans une seconde forêt et créer une relation d’approbation avec authentification sélective.
– Scénario 4 : Créer les comptes utilisateurs externes dans une base ADAM ou une base SQL et configurer l’application en questions pour s’authentifier avec cette base de compte.
Nous allons commencer par exclure le scénario 4 car il ne répond pas aux cahiers des charges. Je ne peux pas accéder à des serveurs de fichiers en m’authentifiant dans une base ADAM / SQL.
RAPPEL DES RISQUES :
Par défaut, le groupe « Utilisateurs authentifiés » a :
– Le droit de créer des fichiers et lire les fichiers sur un serveur de fichiers Windows.
– Le droit d’accéder à un site web SharePoint.
– D’ouvrir une session sur un serveur Terminal Server (mode serveur d’applications). Pour Citrix, il faut que l’administrateur est créé une publication donc c’est déjà moins risqué…
SCENARIO 1 : CREER LES COMPTES DES UTILISATEURS EXTERNES DANS LE DOMAINE INTERNE.
Tous les utilisateurs du domaine sont membres des groupes « Utilisateurs du domaine » et membre du groupe système « Utilisateurs authentifiés ».Nos utilisateurs externes ont donc accès ont donc par défaut de nombreux accès sur les serveurs de fichiers, SharePoint et serveur Terminal Server / Citrix.
Comment restreindre ces accès ?
– Créer le groupe « EXTRANET-USERS ».
– Ajouter les utilisateurs externes aux groupes « EXTRANET-USERS ».
– Configurer le compte utilisateur externe afin que ce dernier ne puisse ouvrir des sessions que sur certaines machines. Pour cela, aller dans les propriétés du compte utilisateur, dans l’onglet « Account » puis cliquer sur le bouton « Log on To » et cocher la case « The following computers ». Entrer la liste des machines sur lesquels l’utilisateur peut ouvrir sa session. L’attribut sous-jacent gère jusqu’à 1024 valeurs. Cette méthode empêche l’ouverture de session en locale mais l’utilisateur peut toujours accéder à des machines non autorisées via le réseau (accès aux partages).
Une alternative à cette méthode est de configurer le paramètre de GPO « Deny logon locally » au groupe « EXTRANET-USERS » et appliquer cette GPO sur les machines Windows réservées aux utilisateurs internes.
– Configurer le paramètre de GPO « Deny Access to this computer from the network » au groupe « EXTRANET-USERS » et appliquer cette GPO sur les machines Windows réservées aux utilisateurs internes. Ce paramètre va empêcher les utilisateurs externes d’accéder aux ressources internes.
SCENARIO 2 : CREER LES COMPTES DES UTILISATEURS EXTERNES DANS AUTRE DOMAINE DANS LA MEME FORET :
Je trouve ce scénario sans intérêt. Les forêts avec plusieurs domaines sont plus complexe à gérer.
Par défaut, Active Directory crée des relations d’approbations entre domaines d’une même forêt qui ne peuvent pas être supprimées et sur lesquels on ne peut pas activer l’authentification sélective (on en parle juste en dessous).
Un utilisateur du domaine A sera donc « Utilisateurs authentifiées » dans le domaine B et inversement. On se retrouve dans le même cas que le scénario 1 au niveau sécurité.
SCENARIO 3 : CREER LES COMPTES DES UTILISATEURS EXTERNES DANS UNE SECONDE FORET ET CREER UNE RELATION D’APPROBATION AVEC AUTHENTIFICATION SELECTIVE :
C’est clairement le scénario qui offre le meilleur niveau de sécurisation.
Le principe est de :
– Créer un domaine dans une forêt séparé.
– Créer une relation d’approbation bidirectionnel (voir monodirectionnel selon le besoin) entre ces deux forêts (relation d’approbation inter-forêts).
– Activer l’authentification sélective au niveau de la relation d’approbation.
– Configurer les accès dans les domaines. Pour donner accès à une ressource Y1 membre du domaine Y (de la forêt Y) à un utilisateur du domaine X (de forêt X), vous devez donner le droit « Allowed to authenticate » sur le compte ordinateur de la machine Y1 à l’utilisateur du domaine X (de la forêt X). Dans le cas contraire si l’utilisateur essaie d’accéder à la ressource, il a le message d’erreur suivant « Logon Failure. The machine you are logging onto is protected by an authentication firewall. The specified account is not allowed to authenticate to the machine ».
La solution est très sécurisée par défaut mais a les inconvénients suivants :
– Vous avez deux annuaires Active Directory à gérer.
– Il faut configurer les permissions au niveau des comptes ordinateurs des serveurs de ressources (la permission « Allowed to authenticate »).
– Si vous utilisez des reverse proxy comme Forefront TMG pour publier l’Extranet, la délégation Kerberos ne fonctionne pas si le serveur Forefront TMG est dans le domaine des utilisateurs internes.
– Il faut obligatoirement activer l’authentification sélective au niveau de la relation d’approbation sinon on a les mêmes contraintes que le scénario 1 et 2.
POUR CONCLURE :
Je vous invite à partir sur le scénario 1 (domaine unique dans une forêt unique) ou sur le scanério 3 (domaine dans une forêt séparé pour les utilisateurs externes avec authentification sélective).
Pour plus d’informations :
– http://technet.microsoft.com/en-us/library/gg502594.aspx
– http://blog.msfirewall.org.uk/2008/06/using-isa-server-2006-to-protect-active.html
– http://technet.microsoft.com/en-us/library/cc995228.aspx
– http://4sysops.com/archives/how-to-use-kerberos-constrained-delegation-with-forefront-tmg/
A+
Guillaume MATHIEU
Consultant Architecture & Intégration PROSERVIA
La connaissance s’accroît quand on la partage.
http://msreport.free.fr
