ZeroShell    Forum
   Feed RSS Feed
EnglishEnglish     ItalianoItaliano     French     Spanish                Facebook      Twitter

Valid HTML 4.01 Transitional


      Qu'est ce que c'est?
      Screenshots
      Licence
      Annonces
      Liste de diffusion
      Forum
      Documentation  
      FAQ
      Hardware
      Download
      On-line Updates
      Kerberos Tutorial  
      Conditions d'utilisation
      Contactez-moi


  Dans plus de détails:
      Performances
      Net Balancer
      UMTS Routeur
      Proxy avec Antivirus
      Point d'accès WiFi
      OpenVPN Client
      OpenVPN Server
      QoS
      OpenDNS
      Kerberos 5
      NIS et LDAP
      Certificats X.509
      RADIUS
      Captive Portal
      VPN
      Firewall


LDAP et NIS directory

L'authentification n'est pas le seul mécanisme impliqué dans l'accès aux ressources d'un réseau local: après avoir reconnu un utilisateur comme authentique, l'utilisateur ne peut accéder à tous les services sans discrimination. Un mécanisme d'autorisation pour l'utilisation des ressources est nécessaire. D'autre part, si vous regardez le contenu du fichier / etc / passwd d'un système Unix, il ne contient pas seulement des mots de passe cryptés (en fait, il n'a souvent pas les contenir), mais aussi l'ID utilisateur, ID du groupe des principaux groupe, la description la home directory, et le shell de connexion utilisateur. Cette information qui caractérise l'utilisateur dans le système, et en particulier de l'UID et GID, s'ils sont présents dans les ACL (Access Control Lists) d'une ressource, d'autoriser l'accès.
La technique de fichiers local tel que /etc/passwd et /etc/group n'est pas applicable sur les réseaux locaux large car il est nécessaire de répliquer l'entrée correspondante pour chaque poste de travail et serveur pour un utilisateur ou un groupe d'accès. Faut-il plus tard, devenu nécessaire de modifier les informations d'un utilisateur, par exemple leur shell de connexion, puis l'administrateur sera obligé de répéter le changement pour chaque hôte que l'utilisateur peut accéder.

La solution à ces problèmes a été trouvée avec le développement de la NIS (Network Information Service) du protocole, également connu sous le nom Sun Yellow Pages (YP). Il permet à l'information contenue dans le fichier /etc/ passwd, /etc/group, /etc/ shadow pour être centralisés sur un serveur, de les distribuer aux clients via le réseau. À ce stade, l'administrateur peut entrer, modifier et supprimer les informations qui viennent sur le serveur NIS pour qu'il soit automatiquement disponible sur tous les nœuds Unix.

Dans les mots de passe cryptés passé contenues dans /etc/passwd ou /etc/shadow ont été distribuées par NIS, rendant ainsi agir comme une authentification ainsi que le serveur d'autorisation. Aujourd'hui, cette technique est inapplicable parce qu'elle consiste à déplacer le mot de passe sur un réseau ouvert et d'insécurité où un renifleur pourrait s'en emparer et, avec la puissance de traitement actuellement disponibles, il unencrypt en quelques heures quelques machine. Par conséquent, il est préférable de déléguer la tâche d'authentification à un serveur Kerberos, qui, grâce à destickets et authentificateurs ne met jamais les secrets d'utilisateur sur le réseau.

Le NIS fonctionne «à plat» les domaines et est donc inadapté pour les grandes organisations qui, en raison de leur nature peuvent être organisés de façon hiérarchique. Dans de tels cas, l'utilisation du protocole LDAP (Lightweight Directory Access Protocol) est de plus en plus répandue, permettant l'accès à des données organisées dans des Directory X500. Généralement, un domaine LDAP on fait correspondre au domaine DNS de la structure dont il doit représenter et de le décomposer en unités Organisation (UO) basée sur la subdivision naturelle de l'organisation.

Contrairement NIS, LDAP est extensible, ce qui signifie que le type de données qu'il peut représenter n'est pas établi au préalable par le protocole, mais peut être changé par l'administrateur en ajoutant des schémas. Il existe des schémas d'autorisation, la collecte d'informations utilisateur (téléphone, fax, e-mail, adresse, etc), la localisation des imprimantes réseau, la mémorisation des zones DNS, routage SMTP pour les e-mail, base de données RADIUS et bien d'autres. Naturellement, les schémas peuvent être personnalisés par l'administrateur système.

Probablement la plus connue Directory consultable avec LDAP est le Microsoft Active Directory présents dans le contrôleur de domaine Windows. Merci à la nature hiérarchique de LDAP et la transitivité de la relation de confiance de l'Kerberos 5, Microsoft a réussi à obtenir une authentification, d'autorisation et d'audit qui est incroyablement adaptable sur de grandes organisations car elle distribue naturellement la charge de travail sur les sous-domaines qui composent la structure plus vaste.

Zeroshell utilise LDAP pour mémoriser les données relatives aux zones de serveur DNS, les attributs pour le serveur RADIUS et les autorisations pour les utilisateurs et les hôtes. Elle répond aux clients LDAPv2 et LDAPv3 et contient les schémas de gestion centralisée des carnets d'adresses (compatible avec les navigateurs Netscape, Mozilla et Outlook). Zeroshell répond également aux demandes des clients NIS garantissant ainsi un soutien pour les demandes d'autorisation pour les anciens hôtes qui n'ont pas de LDAP.




    Copyright (C) 2005-2012 by Fulvio Ricciardi