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
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
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.
- 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:
- 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
- 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
- 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.
DAS servers would provide the following services and features:
- Redundancy (multiple units, failover, etc.)
- 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.
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
- 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:
- Kerberized SSH
Note: Kerberized telnet, rlogin, ftp, rsh, and rcp all support optional data encryption.
Authentication is secure in any case.