The goals of the Distributed Authentication System (DAS) need to be formally stated. It is very easy for project requirements to expand and change so that the objectives are never met. It is important to define a limited set of achievable objectives.

Goals

Here is a concise list of the basic goals of DAS:

• Distributed authentication and naming for organizational LAN/Intranet use. In our case, this is a software lab.
• Comprised of 100% FOSS software. No proprietary protocols or components will be used.
• Provide basic authentication and naming capabilities similar in scope to NIS and Windows NT Domains
• DAS authentication security should be better than NIS and Windows NT
• Cross platform. The server components should run on any Unix-like system, and the client components should support any Unix-like system. Minimum client support should include GNU/Linux, FreeBSD, and Solaris. The system should not be designed to support only one Unix flavor or GNU/Linux distribution.
• Central storage and management of user, group, directory, and authentication informantion
• Globally unique usernames, groupnames, UIDs, and GIDs.
• Should act as an enabler for network file systems and single-sign-on (SSO) applications
• Use existing, proven code and projects to the maximum extent possible
• Installation, configuration, and management must be straightforward and well-documented

More Goals

A user defined in DAS should be able to login to his or her computer from the console, GUI console, or via SSH using an encryped, centrally stored/managed username and password. Any PAM-enabled application or application/protocol that runs over SSH can use the same username and password for authentication.

The DAS should enable Single Sign On (SSO); specifically, being able to use Kerberos 5 client-server applications. The DAS should support SSO applications via traditional Kerberos client-server programs and ticket management, as well as GSS-API enabled applications such as Kerberos-aware web browsers and web servers.

Specific Functions/Details

Network-wide:

• Globally unique UID, GID, user names, and group names
• Central storage and management of user information, including the GECOS field ("chfn" info), shell, home directory, etc.
• Central storage and management of group membership information
• The capability for central storage and management of the the following standard NIS map information:
  • passwd
  • group
  • hosts
  • services
  • networks
  • protocols
  • rpc
  • ethers
  • netmasks
  • bootparams
  • netgroup
  • publickey
  • automount
  • aliases
• Centralized, secure, encrypted authentication for users and applications
• Provide infrastructure for Single Sign On (SSO) applications
• Enable network file system use: NFSv4, NFSv3, OpenAFS, etc.
• Logging of all authentication and Kerberos events
• It should be possible for users to be "logged into" the network from multiple hosts simultaneously
• user and password control functions:
  • account expiration
  • account lockout/account unlock
  • password complexity requirements
  • password dictionary checking
  • password length limits
  • password history checking

Client Functions:

• naming - username, groupname, hostname, and other lookups. This is usually configured in /etc/nsswitch.conf
• network authentication of users via Kerberos
• allow console logins
• allow local GUI console logins via XDM, GDM, and KDM
• allow users to unlock a locked desktop/screensaver
• allow SSH logins
• support other remote console protocols, such as Kerberized RLOGIN and Kerberized TELNET
• maintain time synchronization
• All standard Unix functions should work for an DAS user: cron jobs, at jobs, e-mail, etc.
• Supports network file systems (*NFSv4, NFSv3, OpenAFS)
• Support network file transfers via SCP, SFTP, Rsync over SSH, Kerberized FTP, and Kerberized RCP
• Should be possible to automatically create a home directory on first login
• Disk quotas work correctly for DAS users and groups
• commands such as ls, ps, top, who, whoami, id, finger, and w need to work for DAS users (any command that uses nsswitch lookups)
• The DAS client and the DAS server should have no shared secrets between them. The assumption is that you cannot trust users or root users on DAS client machines. This also allows local "root" users to administer their systems as they see fit without compromising the central naming and authentication system. For example, a host administrator can configure his or her system to allow local users as well as DAS users.
• Procedures for handling situations where DAS clients cannot connect to DAS servers must be developed. A local root user or local user should still be able to login and use host services, even when the network or specific DAS server daemons are not available.

Server Functions:

DAS servers would provide the following services and features:

• Redundancy (multiple units, failover, etc.)
• Scalability
• Log all transactions
• Automatic replication and backup
• Provide time synchronization services
• Add, delete, modify, and view users, groups
• Add, delete, modify, and view other directory/naming info.
• NIS server
• Kerberos 5 daemons
• A complete set of well-documented command line tools for performing administrative tasks. These tools would facilitate the creation of administrator-friendly unified GUI or menu-driven tools.

Application Support:

DAS systems should be capable of supporting authentication for the following client-server protocols:

• SSH (and everything that rides over SSH)
• POP3 over TLS
• IMAP over TLS
• SMTP AUTH over TLS
• NNTP over TLS
• IRC over TLS
• XMPP (standardized Jabber) over TLS
• HTTPS
• WebDAV over TLS
• IPP over TLS
• CVS over SSH
• SQL over TLS

DAS systems should also be capable of supporting the following Kerberized SSO applications and protocols:

• telnet
• rlogin
• ftp
• rsh
• rcp
• ksu
• Kerberized SSH
• NFSv4

Note:  Kerberized telnet, rlogin, ftp, rsh, and rcp all support optional data encryption. Authentication is secure in any case.