System Authentication

When servedat is run with sufficient privileges, it can access the host operating system's authentication databases.  This may include PAM, Active Directory, passwd, LDAP, NIS, or any other sources tied to operating system logon mechanisms.  If the server host is a network client, servedat will inherit access to the remote authentication databases as well.  Operations performed using system logons will inherit whatever privileges and limitations are assigned by the operating system.

This allows system users to access the server using the same credentials and privileges as they would for FTP, SCP, SSH, or a console login.  It also allows administrators to control access using existing authentication databases.

The preferred method to enable SysAuth is to set "SysAuth 1" in a configuration file, or specify "-S" on the command line.  Alternatively, SysAuth will be turned on by default if servedat is run as root or as a Windows service, and no AuthFile is specified.

It is strongly recommended that you explicitly set SysAuth instead of relying on the default behavior.  Otherwise it could be unexpectedly disabled if you later add an on AuthFile.  The default behavior may change in a future release.

Note that AuthFile usernames take priority over SysAuth usernames.  So if a username exists in both databases, only the AuthFile record will be used.  This may change in a future version.

Database Details

On Windows systems, the LogonUser() facility is used to authenticate users and retrieve access privileges.  If the system is configured to use Active Directory, LDAP, NIS, or other authentication services, those databases will be inherited through LogonUser().

Windows does not create a user's profile (home) directory until the first time the user logs onto the desktop.  If a user has never logged onto the desktop of the machine running servedat, their profile directory will not be available and they will instead be directed to the default home.

On Mac OS X (darwin), Linux, NetBSD, FreeBSD, AIX, and Solaris x86, the PAM system is used to access available system authentication services.  By default, servedat registers with the service module "sshd" ("login" on AIX) since most systems default to having this module enabled.  If you wish to create a custom PAM service module, you can change the name by using the ServiceName (-V) option.

For HP-UX, IRIX, and Solaris Sparc, the system password file will be checked via getpwnam().  If the system is configured to use Active Directory, LDAP, NIS, or other authentication services, those databases may be inherited through getpwnam().  As a fallback, if no record is found in getpwnam() or if its password field starts with '+', and an NIS domain has been detected, then NIS will be used to lookup the username.  Note that a local passwd entry will override an NIS network entry.  When inheriting authentication from an external source such as Active Directory, LDAP, or NIS, the service must provide a unix crypt style password hash.

Privilege Details

When servedat is running with sufficient privileges, System Users are granted the user id, group id, and secondary group ids of their login.  If servedat is not running as a privileged process, System Authentication will not be available on most systems.

System authenticated users will normally be allowed full access to all available filesystems by using absolute pathnames (paths starting with a '/' or in Windows with a volume label such as "C:").  You can override this access server-wide with the configuration variable RestrictHome.

Windows: Access to network mounted filesystems is restricted by the Windows operating system.  If a network mounted filesystem requires user authentication, then a client will only be able to access it if the username is authenticated with System Authentication (not AuthFile) and the given username and password are the same on both the servedat system and the network file server.