Il y a plusieurs choses que vous pouvez faire avec Google Apps.
Vous pouvez configurer un serveur SAML connecté à votre réseau AD puis configurer Google pour authentifier votre accès à Google Apps contre le serveur SAML. Nous avons utilisé une application PHP appelée simpleSAMLphp car nous avions déjà des serveurs configurés pour exécuter PHP et nous avons des développeurs avec des compétences PHP. L’inconvénient d’utiliser une solution SAML seule est que vous ne pouvez vous connecter aux comptes que via le web. Cela signifie que vous ne pouvez pas accéder à votre boîte mail via imap/pop, et vous ne pouvez pas vous connecter à Google Talk avec n’importe quel vieux client XMPP.
Utiliser SAML ne crée pas automatiquement de comptes dans le domaine Google Apps. Vous aurez probablement aussi besoin d’un outil qui synchronisera les comptes, pour cela vous pouvez utiliser l’outil Google Apps Directory sync. Cela vous permettra de créer des comptes, mais ne synchronisera toujours pas les mots de passe par défaut car les hachages de mots de passe Windows ne sont pas réversibles et Google ne peut rien en faire.
Il est possible d’utiliser quelque chose comme PasswdHk pour intercepter les changements de mot de passe dans votre AD puis stocker le mot de passe dans un format (sha1 non salé) que l’utilitaire de synchronisation de répertoire Google peut utiliser pour définir les mots de passe Google Apps. Mais cela ajoute un peu de risque de sécurité car Google n’accepte que les hachages de mots de passe md5 ou sha1 non salés via son API de provisionnement, et pour synchroniser avec Google, vous devez essentiellement stocker ces hachages. Si vous devez utiliser cela, il est très important de garder ces hachages en sécurité.
Hmm. Vous m’aviez tout excité à propos de SAML jusqu’au passage sur imap/pop. Cela bloquerait tous les gens qui utilisent des clients Windows Mobile et BlackBerry, n’est-ce pas ? Des alternatives astucieuses ?
Si vous êtes prêt à accepter le risque de stocker les hachages de mots de passe, alors vous pouvez combiner le SSO et la synchronisation de répertoire pour obtenir un système fonctionnel.
Comme alternative, quelqu’un pourrait développer un portail Intranet où les utilisateurs de votre domaine iraient pour initialiser leur compte Google et définir le mot de passe pour le compte Google. J’avais envisagé de développer quelque chose comme cela, mais je n’ai pas pu convaincre mes collègues que c’était la bonne voie.
L’idée de base est la suivante, construire une application web qui
-
Réside sur votre intranet et s’authentifie contre votre Active Directory
-
Dispose d’une fonction qui prendra le nom d’utilisateur et le mot de passe que l’utilisateur a utilisés pour se connecter au site intranet et obtiendra toute autre information nécessaire depuis l’AD, puis utilisera l’API de provisionnement Google pour ajouter/mettre à jour le compte de l’utilisateur.
Construire l’outil ne devrait vraiment pas être trop difficile, j’avais estimé que pour produire quelque chose de basique, il ne faudrait que 12 à 16 heures de développement. L’avantage de cette solution est qu’elle vous donne 100% des fonctionnalités de Google Apps, l’inconvénient est qu’elle est quelque peu gênante pour l’utilisateur final.