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.

Step-by-step instructions for enabling System Authentication can be found in the Adding Users section.

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 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, the AuthFile record will control access.

Shadow Users

Access rights for individual system users can be controlled by creating an Shadow Authentication record for each.  This allows restrictions such as RestrictHome and GetOnly to be applied on an individual basis rather than system-wide.  It also gives you the option of setting home directories individually, rather than using system home directories, SysHome, or the global default.

To match Active Directory users with explicit domains, use the syntax user@domain.  If Active Directory may allow the user to authenticate using both user and user@domain, or with multiple domains, you must create a separate record for each.

If SysAuth is disabled (0), the presence of any shadow record in AuthFile will cause system authentication to be enabled for shadow records only.  In the log file, SysAuth will appear to have a value of 2 with an origin of "Override".  This is useful if you want to give access to only a specific set of system users.

Username Suffix

You may limit access to only those users whose usernames which end in a specified suffix by setting the SysAuthSuffix option.  For example, setting "SysAuthSuffix @domain" would allow "joe@domain" but would prohibit "joe" or "bob".  On Windows or other Active Directory systems, this allows you limit system authentication to a single domain.  Arbitrary strings such as "-exp" can also be used to create a logical separation of users.  SysAuthSuffix only affects System Authentication, including Shadow Authentication.  It does not apply to non-shadow AuthFile records.

Session Caching

Because servedat authenticates each individual transaction, not just client sessions, there may be thousands of queries per second.  To avoid overloading the system authentication database, system user records are cached for a period of time defined by the AuthCache option.  If you make changes to a system user's authentication record, those changes will not take effect in servedat until after at least AuthCache seconds have passed.  Restarting servedat will clear the cache immediately, and force all clients to retry.

Database Details

Windows: 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.

macOS: Authentication is performed via PAM using a custom "servedat" PAM module installed in /etc/pam.d/servedat.  User records are acquired from the system passwd database via getpwnam() while supplemental group lists are acquired from the system group database via getgrouplist().  The passwd and group database sources are controlled by OpenDirectory.

Linux, FreeBSD, and AIX: Authentication is performed via PAM using the existing sshd module.  User records are acquired from the system passwd database via getpwnam().  Supplemental group lists are acquired from the system group database via getgrouplist().  The passwd and group database sources are specified in /etc/nsswitch.conf.

Solaris x86: Authentication is performed via PAM using the existing login module.  User records are acquired from the system passwd database via getpwnam().  Supplemental group lists are acquired from the system group database via getgrouplist().  The passwd and group database sources are specified in /etc/nsswitch.conf.

Solaris Sparc and HP-UX: Authentication and user record lookup is first performed in the system passwd database via getpwnam().  If a record cannot be found or the user record starts with a '+', and an NIS domain is available, then NIS will be queried via yp_match().  Note that a local passwd entry will override an NIS network entry.  If a record is found but lacks a password, the password crypt will be retrieved from the shadow database via getspnam().  The NIS service or its source must provide the password as a unix crypt hash.  Supplemental group lists are acquired from the system group database via getgrouplist().

All systems using PAM authentication may specify an alternative PAM service module by using the ServiceName (-V) option.

Privilege Details

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, or on an individual basis using Shadow Authentication.

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 unshadowed AuthFile) and the given username and password are the same on both the servedat system and the network file server.

For more details about NAS authentication, see Tech Note 0031.