ZeroShell    Forum
   Feed Feed
EnglishEnglish     ItalianoItaliano     French     Spanish                Zeroshell on LinkedIn LinkedIn       Facebook      Twitter ZeroTruth una interfaccia per il Captive Portal

      Cosa è?
      Screenshots
      Licenza
      Annunci
      Mailing List
      Forum
      English Forum
      Documentazione
      FAQ
      Hardware
      Download
      Update On-line
      Kerberos Tutorial  
      Note Legali
      Contattami


  Più in dettaglio:
      Hotspot Router
      Accounting
      Shibboleth SP
      Grafici e Prestazioni
      Net Balancer
      Router UMTS
      Proxy con Antivirus
      Filtri Web
      WiFi Access Point
      OpenVPN Client
      OpenVPN Server
      QoS
      OpenDNS
      Kerberos 5
      NIS e LDAP
      Certificati X.509
      RADIUS
      VPN
      Firewall


Valid HTML 4.01 Transitional




Autorizzazione NIS e LDAP

L'autenticazione non è l'unico meccanismo che entra in gioco nell'accesso alle risorse di una LAN: dopo aver riconosciuto un utente come autentico, egli non potrà accedere indiscriminatamente a tutti i servizi. Serve cioè un meccanisco di autorizzazione all'uso delle risorse. D'altra parte, se si guarda al contenuto del file /etc/passwd di un sistema Unix, questo non contiene solo le password criptate (anzi spesso non le contiene), ma anche lo user ID, il group ID del gruppo principale di appartenenza, la descrizione, la home directory e la shell di login dell'utente. Queste informazioni caratterizzano l'utente nel sistema e in particolare lo UID e il GID se presenti nelle ACL (Access Control List) di una risorsa ne autorizzano l'accesso.
La tecnica dei file locali come /etc/passwd e /etc/group non è applicabile su grosse LAN in quanto per ogni workstation e server per cui un utente o gruppo può accedere è necessario replicare la relativa entry. Se poi si rende necessaria la modifica di un'informazione di un utente, come per esempio l'appartenenza ad un gruppo o la sua shell di login, l'amministratore sarà costretto a ripetere la modifica per ogni host su cui l'utente può accedere.

A soluzione di questi problemi fu sviluppato il protocollo NIS (Network Information Service) anche noto come Sun Yellow Pages (YP). Esso permette di centralizzare su di un server le informazioni contenute nei file /etc/passwd, /etc/group, /etc/shadow distribuendole ai client via network. A questo punto l'amministratore inserisce, modifica e cancella le informazioni solo sul server NIS ottenendo che queste siano automaticamente disponibili su tutti i nodi Unix.

In passato, si usava far distribuire al NIS anche le password criptate contenute in /etc/passwd o in /etc/shadow facendolo fungere quindi da server di autenticazione oltre che di autorizzazione. Oggi, questa tecnica è inapplicabile perché comporta il passaggio delle password sulla rete aperta e insicura dove uno sniffer potrebbe catturarle e, con le attuali potenze di calcolo disponibili decriptarle in poche ore macchina. Si preferisce pertanto delegare il lavoro di autenticazione a un server Kerberos, che grazie a ticket e autenticatori non fa mai viaggiare i segreti dell'utente.

Il NIS opera su domini "piatti" ed è pertanto inadeguato per grandi organizzazioni che per loro natura possano essere inquadrate in una struttura gerarchica. In questi casi, si va sempre più diffondendo l'uso del protocollo LDAP (Lightweight Directory Access Protocol) che permette l'accesso a dati organizzati in directory X.500. In genere, si usa far corrispondere un dominio LDAP al dominio DNS della struttura che si deve rappresentare e questo suddividerlo in Organization Unit (OU) in base alla naturale suddivisione della realtà.

LDAP, contrariamente al NIS, è estensibile, intendendo con ciò che i tipi di dato che si possono rappresentare non è fissato a priori dal protocollo, ma possono essere modificati dall'amministratore mediante l'aggiunta degli schemi. Esistono schemi per l'autorizzazione, per la raccolta di informazioni sugli utenti (telefono, fax, email, indirizzo, ecc), per la localizzazione delle stampanti di rete, per la memorizzazione delle zone del DNS, per il routing SMTP della posta elettronica, per il database di RADIUS e tanti altri. Naturalmente gli schemi possono essere creati su misura anche dal sistemista.

L'esempio probabilmente più noto di directory consultabile con LDAP è Microsoft Active Directory presente nei controller di dominio Windows. Grazie alla gerarchicità di LDAP e alla transitività delle relazioni di trust dei realm Kerberos 5, Microsoft è riuscita ad ottenere un sistema di autenticazione, autorizzazione e auditing incredibilmente scalabile su grandi realtà poiché distribuisce, in maniera naturale, il carico di lavoro sui sottodomini componenti la grande struttura.

Zeroshell utilizza LDAP per memorizzare i dati riguardanti le zone del server DNS, gli attributi per il server RADIUS, l'autorizzazione degli utenti e degli host. Risponde ai client LDAPv2 e LDAPv3 e contiene gli schemi per la gestione degli Address Book centralizzati (compatibili con Netscape, Mozilla e Outlook). Zeroshell risponde anche a richieste dei client NIS garantendo così il supporto a richieste di autorizzazione per host datati che non hanno LDAP.




    Copyright (C) 2005-2013 by Fulvio Ricciardi