ZeroShell    Forum
   Feed RSS Feed
EnglishEnglish     ItalianoItaliano     French     Spanish                Zeroshell on LinkedIn LinkedIn       Facebook      Twitter ZeroTruth an interface for Captive Portal


      What is it?
      Screenshots
      License
      Announcements
      Mailing List
      Forum
      Documentation  
      FAQ
      Hardware
      Download
      On-line Updates
      Kerberos Tutorial  
      Terms of use
      Contact me


  In greater details:
      Hotspot Router
      RADIUS Accounting
      Shibboleth SP
      Performances
      Net Balancer
      UMTS Router
      Soekris Net5501
      Proxy with Antivirus
      WiFi Access Point
      OpenVPN Client
      OpenVPN Server
      QoS
      OpenDNS
      Kerberos 5
      NIS and LDAP
      X.509 Certificates
      RADIUS
      VPN
      Firewall


Valid HTML 4.01 Transitional

LDAP and NIS directories

Authentication is not the only mechanism involved in accessing the resources of a LAN: after having recognized a user as authentic, the user can not access all the services indiscriminately. An authorization mechanism for using the resources is required. On the other hand, if you look at the contents of file/etc/passwd of a Unix system, it does not just contain encrypted passwords (actually it often does not contain them), but also the user ID, group ID of the main group, description, home directory and user login shell. This information characterizes the user in the system, and in particular the UID and GID, if present in the ACLs (Access Control Lists) of a resource, authorize access to it.
The technique of local files such as /etc/passwd and /etc/group is not applicable on large LANs since it is necessary to replicate the related entry for each workstation and server for a user or group to access. Should it later become necessary to modify the information for a user, for example their group or login shell, then the administrator will be forced to repeat the change for each host that the user can access.

The solution to these problems was found with the development of the NIS (Network Information Service) protocol, also known as Sun Yellow Pages (YP). It allows the information contained in the file /etc/passwd, /etc/group, /etc/shadow to be centralized on a server, distributing them to clients via the network. At this point the administrator can enter, edit and delete the information just on the NIS server so that it is automatically available on all Unix nodes.

In the past encrypted passwords contained in /etc/passwd or /etc/shadow were distributed by NIS, thus making it act as an authentication as well as authorization server. Nowadays, this technique is inapplicable because it involves moving the password over an open and insecure network where a sniffer could capture it and, with the processing power currently available, unencrypt it in a few machine hours. Therefore it is preferable to delegate the authentication job to a Kerberos server, which thanks to tickets and authenticators never puts user secrets over the network.

The NIS operates on "flat" domains and is therefore unsuitable for large organizations which due to their nature may be organized hierarchically. In such cases, the use of the LDAP (Lightweight Directory Access Protocol) protocol is increasingly widespread, allowing access to data organized in X500 directories. Generally an LDAP domain is made to correspond to the DNS domain of the structure which it must represent and break it down into Organization Units (OU) based on the natural subdivision of the organization.

Unlike NIS, LDAP is expandable, which means that the type of data it can represent is not established beforehand by the protocol, but can be changed by the administrator by adding schemas. There are schemas for authorization, collecting user information (telephone, fax, e-mail, address etc.), localization of network printers, memorization of the DNS zones, SMTP routing for e-mail, RADIUS database and many others. Naturally, the schemas can be customized by the system administrator.

Probably the best known directory consultable with LDAP is the Microsoft Active Directory present in the Windows domain controller. Thanks to the hierarchical nature of LDAP and the transitiveness of the trust relationships of the Kerberos 5 realm, Microsoft has managed to obtain an authentication, authorization and auditing system which is incredibly scaleable on large organizations since it naturally distributes the workload onto the subdomains making up the larger structure.

Zeroshell uses LDAP to memorize the data relating to the DNS server zones, the attributes for the RADIUS server and authorizations for the users and hosts. It replies to LDAPv2 and LDAPv3 clients and contains the schemas for managing centralized Address Books (compatible with Netscape, Mozilla and Outlook). Zeroshell also responds to NIS client requests thus guaranteeing support for authorization requests for older hosts that do not have LDAP.




    Copyright (C) 2005-2013 by Fulvio Ricciardi