MOVEit Transfer permet d'authentifier des utilisateurs sur des serveurs externes LDAP et/ou RADIUS. Microsoft Active Directory (AD) fonctionne comme un serveur LDAP, de sorte que MOVEit Transfer peut y effectuer des authentifications natives. Les deux peuvent être sécurisés au niveau du transport (Il est recommandé d'utiliser le protocole LDAP sur SSL/TLS.). Les authentifiants associés sont stockés sous forme cryptée sur MOVEit Transfer.

Outre le fait d'authentifier des utilisateurs existants auprès de sources externes, MOVEit Transfer peut créer de nouveaux utilisateurs, souvent en tant que clone d'un utilisateur modèle existant. MOVEit Transfer peut aussi scinder la base d'utilisateurs d'une organisation en deux groupes, les utilisateurs externes et les utilisateurs internes, l'un utilisant une source d'authentification externe et l'autre utilisant la base de données d'utilisateurs intégrée MOVEit Transfer. Lorsqu'il accède à un serveur LDAP, MOVEit Transfer peut répliquer les informations d'appartenance aux groupes ainsi que d'autres informations telles que l'adresse e-mail à partir de ce serveur LDAP.

Authentification unique

Pour les environnements d'entreprise, vous pouvez mettre en œuvre l'authentification externe pour MOVEit Transfer qui fournit un comportement d'authentification unique (SSO). Il existe plusieurs approches pour cela. Il s'agit, mais sans s'y limiter, de ce qui suit :

  • CA SiteMinder. MOVEit Transfer peut accepter des authentifiants préauthentifiés de CA SiteMinder. Pour plus d’informations sur cette fonction, reportez-vous à la section Sujets avancés - Intégration de services - Intégration SiteMinder).
  • Common Access Card (CAC). MOVEit Transfer peut authentifier des utilisateurs en utilisant des certificats client stockés sur des matériels dans des environnements de type CAC Smart Card. Pour plus d’informations sur cette fonction, reportez-vous à la section Sujets avancés - Intégration de services - Intégration CAC.
  • Fournisseur d'identité utilisant SAML. MOVEit prend en charge une authentification unique via l'échange de messages SAML structurés entre le service et le fournisseur d'identité. Vous aurez besoin d'un fournisseur d'identité compatible SAML (tel que AD FS) comme source d'authentification. Cette fonction peut être utilisée avec les sources d'authentification d'utilisateur existantes. Pour plus d'informations, reportez-vous à la section Présentation de la fonction Authentification unique.

Sources d'authentification

Une source d'authentification est un serveur RADIUS, LDAP ou WS-Trust que MOVEit Transfer interroge. Plusieurs sources d'authentification peuvent être configurées au sein d'une organisation donnée. Chacune peut être de type différent (par exemple, deux sources RADIUS et trois sources LDAP) et faire référence à un utilisateur modèle différent. Les utilisateurs appartiennent donc déjà aux groupes appropriés lorsqu'ils sont automatiquement ajoutés.

Les types de sources d'authentification actuellement pris en charge sont les suivants :

  • RADIUS (Authentication Only) (RADIUS (Authentification uniquement)) : Les noms d'utilisateur et les mots de passe entrants sont vérifiés auprès d'un serveur RADIUS distant. Si l'authentification est réussie, un nouvel utilisateur peut être créé à la volée en tant que clone d'un utilisateur modèle existant.
  • RADIUS (Authentication Only) (RADIUS (Authentification uniquement)) : Les noms d’utilisateur et les mots de passe entrants sont vérifiés auprès d'un serveur LDAP distant. Si l'authentification est réussie, un nouvel utilisateur peut être créé en tant que clone d'un utilisateur modèle existant.
  • LDAP (Lookup and Authentication) (LDAP (Recherche et authentification)) : Les noms d’utilisateur et les mots de passe entrants sont vérifiés auprès d'un serveur LDAP distant. Si l'authentification est réussie, un nouvel utilisateur peut être créé à la volée en tant que clone d'un utilisateur modèle existant. Toutefois, les attributs utilisateur tels que l'adresse e-mail et les appartenances aux groupes seront reportés à partir du serveur LDAP. (Il s'agit actuellement de l'option la plus répandue.)
  • WS-Trust (Authentication Only) (WS-Trust (Authentification uniquement)) : Les noms d’utilisateur et les mots de passe entrants sont vérifiés auprès d'un serveur WS-Trust distant. Si l'authentification est réussie, un nouvel utilisateur peut être créé à la volée en tant que clone d'un modèle d'utilisateur existant.

La documentation complète et les exemples pour les serveurs LDAP Active Directory, Novell eDirectory, IBM Domino et iPlanet sont fournis. D'autres serveurs LDAP (comme IBM Tivoli Access Manager - SecureWay) sont également pris en charge grâce à l'utilisation de modèles de connexion et d'attribut flexibles. (La configuration d'un serveur RADIUS est relativement générique comparée à celle d'un serveur LDAP.)

Plus d'informations

La connexion à des sources d'authentification externes nécessite souvent des règles de pare-feu supplémentaires. Pour plus d'informations sur les différentes règles associées aux services LDAP et RADIUS, reportez-vous à la section MOVEit Transfer Configuration du pare-feu.

Pour connaître les paramètres qui contrôlent la façon dont MOVEit Transfer accède aux sources d'authentification externes et la façon dont les nouveaux enregistrements d'utilisateurs sont configurés pour les utilisateurs d'authentification externes, reportez-vous à la section Méthode d'authentification de la page Paramètres - Stratégies de sécurité - Authentification d'utilisateur.

Pour connaître les paramètres qui contrôlent la façon dont les utilisateurs accèdent aux sources d'authentification externes, reportez-vous à la section Méthode d'authentification de la page Utilisateurs - Profil

Pour plus d'informations sur la configuration des sources d'authentification, reportez-vous à la section Interface Web - Paramètres - Stratégies de sécurité - Authentification externe.

Accès en toute sécurité à des serveurs LDAP sur site (tels qu'Active Directory)

MOVEit Transfer Dispose de deux moyens pour se connecter en toute sécurité à des sources LDAP sur site à partir d'un segment DMZ. Chacun garantit un cryptage renforcé des authentifiants utilisateur et des informations pendant leur transfert, et aucun ne demande un accès anonyme.

Connexion SSL/TLS directe et authentifiée à un serveur LDAP interne

Ce scénario est très courant. Un utilisateur final présente d'abord des authentifiants à MOVEit Transfer via une liaison SSH (FTP/SSH) ou SSL (FTP/SSL ou HTTP/S) cryptée. MOVEit Transfer transfère ensuite ces authentifiants au serveur LDAP via une liaison SSL (LDAP/SSL) cryptée afin de déterminer si cet utilisateur peut se connecter à MOVEit Transfer. MOVEit Transfer ne conserve pas les authentifiants dans son magasin.

Selon la configuration de votre système, il est possible que MOVEit Transfer se connecte en tant qu'utilisateur LDAP avec le droit de parcourir l'annuaire LDAP pour répliquer les paramètres tels que l'adresse e-mail et les appartenances aux groupes. Dans ce cas, les authentifiants que MOVEit Transfer utilise pour parcourir l'annuaire sont cryptés sur MOVEit Transfer à l'aide de l'algorithme AES 256 bits.

Pour accéder à un serveur LDAP interne directement à partir d'un serveur MOVEit Transfer basé sur une DMZ, procédez comme suit :

  • Configurez votre serveur LDAP de façon à exiger une authentification et des connexions SSL lors de la réception de connexions provenant de l'adresse IP du pare-feu interne, du serveur MOVEit Transfer ou d'un segment DMZ.
  • Configurez une règle de pare-feu interne pour permettre à MOVEit Transfer de se connecter au serveur LDAP sur le port TCP 636 (le port standard pour LDAP sur SSL).
  • Configurez une source d'authentification externe sur MOVEit Transfer. Fournissez les authentifiants pour accéder au serveur LDAP et spécifiez LDAPS (LDAP sur SSL) en tant que protocole d'authentification.

Connexion SSL authentifiée à un serveur LDAP interne via RADIUS

Ce scénario est moins courant mais il est encore fréquemment utilisé dans les cas où LDAP (même crypté avec SSL) est un protocole banni. Un utilisateur final présente d'abord des authentifiants à MOVEit Transfer via une liaison SSH (FTP/SSH) ou SSL (FTP/SSL ou HTTP/S) cryptée. MOVEit Transfer transfère ensuite ces authentifiants à un serveur RADIUS avec des paquets RADIUS cryptés afin de savoir si cet utilisateur peut se connecter à MOVEit Transfer à ce moment-là. MOVEit Transfer ne conserve pas les authentifiants dans son magasin. Le serveur RADIUS (souvent Microsoft Internet Authentication Service, c'est-à-dire IAS) ne possède pas son propre référentiel d'utilisateurs, mais il est généralement connecté à un domaine Windows, Active Directory ou un autre serveur LDAP.

Le protocole RADIUS est basé sur UDP et tous les paquets sont cryptés avec une clé. Cette clé est stockée sur MOVEit Transfer à l'aide de l'algorithme AES 256 bits. MOVEit Transfer n'a pas besoin de savoir quoi que ce soit sur le ou les serveurs LDAP qui détiennent vraiment les informations utilisateur, car le serveur RADIUS joue le rôle d'un serveur frontal complet. Les requêtes RADIUS, par nature, renvoient moins d'informations sur leurs utilisateurs qu'une requête LDAP similaire.

Pour accéder à un serveur LDAP interne en toute sécurité via RADIUS à partir d'un serveur MOVEit Transfer basé sur une DMZ, procédez comme suit :

Configurez votre serveur RADIUS pour obtenir les informations d'authentification de votre serveur LDAP. (Souvent, lorsque vous utilisez des modules complémentaires gratuits comme le serveur IAS de Microsoft avec Active Directory, vous n'avez que cette possibilité.)

Configurez une règle de pare-feu interne pour permettre à MOVEit Transfer de se connecter au serveur LDAP sur le port UDP 1645 (le port standard pour RADIUS).

Configurez une source d'authentification externe sur MOVEit Transfer. Complétez la clé appropriée pour crypter le trafic RADIUS de votre serveur RADIUS.

Notes concernant les services SSL sur Active Directory

Des utilisateurs ont indiqué que l'activation des services SSL sur les services LDAP Active Directory est plus difficile à réaliser qu'il n'y paraît. Plus précisément, la mise en œuvre de la recommandation de Microsoft impliquant le déploiement d'une autorité de certification d'entreprise peut prendre un certain temps.

Toutefois, il existe, un moyen plus facile d'activer SSL sur Active Directory et qui n'implique aucune autorité de certification d'entreprise.

  1. Procurez-vous un certificat serveur signé par une autorité de certification avec le nom de domaine complet (FQDN) du serveur Active Directory (AD) répertorié en tant que nom courant (NC) du certificat. Pour un serveur nommé ad.internal.mycorp.com, un certificat serveur nommé ad.internal.mycorp.com signé par une autorité de certification quelconque conviendra.
  2. Sur le serveur AD, utilisez le composant logiciel enfichable MMC Certificats (pour l'ordinateur local) afin d'ajouter le certificat serveur signé par une autorité de certification dans le magasin de certificats Personal (Personnel) de l'ordinateur local. Veillez à ce que le certificat importé dispose d'une clé privée répertoriée dans sa propre boîte de dialogue.
  3. Sur le serveur AD, utilisez le composant logiciel enfichable MMC Certificats (pour l'ordinateur local) afin d'ajouter le certificat de l'autorité de certification dans le magasin de certificats Trusted Root (Racine de confiance) de l'ordinateur local. Le certificat importé ne doit avoir aucune clé privée répertoriée dans sa propre boîte de dialogue.
  4. Sur le serveur MOVEit Transfer (ou un autre client LDAP), utilisez le composant logiciel enfichable MMC Certificats (pour l'ordinateur local) afin d'ajouter le certificat de l'autorité de certification dans le magasin de certificats Trusted Root (Racine de confiance) de l'ordinateur local. Le certificat importé ne doit avoir aucune clé privée répertoriée dans sa propre boîte de dialogue.
  5. Redémarrez le contrôleur de domaine. Active Directory trouve automatiquement le certificat de serveur SSL actuel à utiliser selon son nom et rend disponible son interface LDAPS en fonction.
  6. À ce stade, MOVEit Transfer (ou un autre client LDAP) doit être capable de se connecter de manière sécurisée à Active Directory à l'aide de LDAPS sur le port TCP 636.

Vous trouverez davantage d'informations concernant cette procédure sur le site de Microsoft. La différence principale qui existe entre la procédure de Microsoft et celle indiquée ici concerne le recours à l'utilitaire de module complémentaire certreq Microsoft à la place d'OpenSSL.

Enfin, il existe au moins deux autres solutions à ces procédures ; les deux impliquent un tunnel SSL qui ajoute un chiffrement SSL au protocole LDAP existant d'Active Directory.

  • Configurez votre pare-feu afin qu'il accepte les connexions LDAP/SSL sur le port TCP 636 et qu'il les transfère à Active Directory sur le port 389. Dans ce cas, un certificat SSL est installé sur votre pare-feu. (Tous les pare-feu ne prennent pas en charge cette configuration.)
  • Installez un utilitaire appelé STunnel (https://www.stunnel.org) sur votre Active Directory ou tout autre ordinateur interne qui a accès à Active Directory. Configurez STunnel afin qu'il accepte les connexions LDAP/SSL sur le port TCP 636 et qu'il les transfère à Active Directory sur le port 389. Dans ce cas, un certificat SSL est installé sur l'ordinateur qui exécute STunnel.

Contactez le personnel de notre support technique pour obtenir plus d'informations sur ces procédures.