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.
To avoid overloading the system authentication database during high traffic volume, system user records are cached for up to 60 seconds. If you make changes to a system user's authentication record, those changes may not take effect in servedat for up to 60 seconds after the last access. Restarting servedat will clear the cache immediately, and force all clients to retry.
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(). Alternate Domains may be specified by the client: see each client's Authentication documentation for details.
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, and SysHome has not been set, then they will instead be directed to the default home. See the Home Directories chapter for details.
On Mac OS X, Linux, FreeBSD, AIX, and Solaris x86, the PAM system is used to access available system authentication services. Mac OS X installs a custom "servedat" PAM module, while AIX uses the standard "login" module. Linux, NetBSD, FreeBSD, and Solaris x86 use the standard "sshd" module. If you have problems with the default module or if you wish to create a custom PAM service module, you can specify a different module name by using the ServiceName (-V) option.
For HP-UX 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.
When servedat is running with sufficient privileges, System Users are granted the user id, group id, and supplemental group ids of their login. If a user has more than 32 supplemental groups, some or all supplemental groups may be omitted. Some environments may support fewer supplemental groups. Check the server logs for warnings if System Users are not receiving the privileges you expect. 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.