Meilleure pratique pour l'authentification de DMZ contre AD dans LAN

Nous avons peu de clients face à face dans DMZ qui ont également des comptes d'utilisateurs, tous les comptes sont dans le fichier de mot de passe ombre. J'essaie de consolider les ouvertures de session des utilisateurs et de laisser les utilisateurs LAN s'authentifier contre Active Directory. Les services nécessitant une authentification sont Apache, Proftpd et ssh. Après avoir consulté l'équipe de sécurité, j'ai configuré l'authentification DMZ qui a un proxy LDAPS qui, à son tour, contacte un autre proxy LDAPS (proxy2) dans le réseau local et celui-ci transfère les informations d'authentification via LDAP (en tant que liaisons LDAP) vers un contrôleur AD. Deuxième proxy LDAP uniquement nécessaire car le serveur AD Refuse de parler TLS avec notre implémentation LDAP sécurisée. Cela fonctionne pour Apache en utilisant le module approprié. Dans une étape ultérieure, je peux essayer de déplacer les comptes clients des serveurs vers le proxy LDAP afin qu'ils ne soient pas dispersés autour des serveurs.

Pour SSH, j'ai rejoint proxy2 dans le domaine Windows afin que les utilisateurs puissent se connecter à l'aide de leurs identifiants Windows. Ensuite, j'ai créé des clés ssh et les ai copiées dans des serveurs DMZ à l'aide de ssh-copy, pour activer la connexion sans mot de passe une fois que les utilisateurs sont authentifiés.

Est-ce que c'est un bon moyen de mettre en œuvre ce type de SSO? J'ai manqué des problèmes de sécurité ici ou peut-être existe-t-il une meilleure façon d'obtenir mon objectif?

Si vous utilisez PAM pour votre pile d'authentification, vous pouvez utiliser pam_krb5 pour fournir l' authentification kerberos pour vos services. Kerberos a été conçu hors-ligne pour traiter les environnements hostiles, gère l'authentification par proxy, et fait déjà partie des spécifications AD. Pourquoi lutter avec LDAP lorsque vous pouvez faire en sorte que Kerberos fasse le travail lourd pour vous, et continuez avec la vie? Ouais, vous devrez faire une lecture, et oui, cela prendra un peu de temps, mais j'ai utilisé l'authentification Curb-to-AD pendant des années et j'ai trouvé que c'était le moyen le plus simple et le plus rapide d'obtenir SSO Travailler hors de la boîte lorsque vous avez Active Directory comme backend d'authentification.

La principale chose que vous rencontrerez est que Microsoft a décidé d'être très précis sur les types de cryptage par défaut (ils ont fondamentalement fait leur propre), donc vous devrez configurer vos clients Kerberos pour avoir les types de cryptage correspondant Les serveurs AD continueront de le rejeter. Ceci est heureusement une procédure simple et ne nécessite pas plus que quelques modifications à krb5.conf.

Et maintenant, certains liens à considérer …

Vue de Microsoft sur Kerberos

  • Kerberos expliqué

Maillage de Kerberos et Active Directory

  • Guide étape par étape pour Kerberos 5 (krb5 1.0) Interopérabilité

Ssh et Kerberos via PAM

  • Un extrait du livre O'Reilly sur SSH
  • IBM a quelques mots sur OpenSSH et Kerberos

Apache et Kerberos

  • Mod_auth_kerb via SourceForge
  • Fournir l'authentification Active Directory via le protocole Kerberos dans Apache

ProFTP et Kerberos

  • Module mod de ProFTPD mod_gss également via SourceForge

RFC des activités de Microsoft avec Kerberos (dont vous ne voulez vraiment pas lire):

  • RFC3244 Microsoft Windows 2000 Kerberos Changer le mot de passe et définir les protocoles de mot de passe
  • RFC4757 Les types de cryptage RC4-HMAC Kerberos utilisés par Microsoft Windows