3.39. <AuthBy UNIX>

<AuthBy UNIX> authenticates users from a user database stored in a standard Unix password file or similar format. It is implemented in AuthUNIX.pm. It does not log (but does reply to) accounting requests. For more information about the file format, see Section 9.4. Unix password file. Since Unix password files only have encrypted passwords, <AuthBy UNIX> can not work with CHAP or MSCHAP authentication.
For performance reasons, <AuthBy UNIX> opens and reads the password and group files at start-up, reinitialisation and whenever the file modification times change, (i.e. they are cached within Radiator). Since these files are cached in memory, large password files can require large amounts of memory. If you set the Nocache parameter, the files will be reread for every authentication, and will not be cached internally (this can be slow if you have a large password or group files, and should rarely be necessary).
It is not necessary to be running on a Unix host in order to use <AuthBy UNIX>. It will work equally well on Windows and NT, but you are probably less likely to need it there.
By using the Match parameter you can also specify other file formats if you need to.
When attempting to authenticate a user, <AuthBy UNIX> will encrypt the password from the user and compare it to the one in the password file. If the encrypted passwords match, AuthBy UNIX will reply with an Access-Accept message. If the user does not appear in the password file, an Access-Reject message is sent to the client. <AuthBy UNIX> caches the password file and group file internally, and rereads the files when the modification time changes. If the Nocache parameter is set the password and group files will be reread for every authentication.
It is important to note that on its own, <AuthBy UNIX> does not implement check or reply items, and therefore can only be used for “Authenticate only” applications. However, you can use it in conjunction with another AuthBy module that does use check and reply items. For more information, see Section 7. Check and reply items. If you do this, you can also use the Group check item, which will check whether the user is a member of a group defined in the GroupFilename file.
You can use AddToReply to easily add standard reply items to all users authenticated by <AuthBy UNIX>. For more information see Section 3.14.20. AddToReply
<AuthBy UNIX> understands also the same parameters as <AuthBy xxxxxx>. For more information, see Section 3.32. <AuthBy xxxxxx>.

3.39.1. Filename

Specifies the filename of the password file. Defaults to /etc/passwd. The file name can include special formatting characters. For more information, see Section 3.3. Special formatters.
On systems with shadow password files, such as Solaris, Filename can name the shadow file. In order to support this, Radiator must have permission to read the shadow file (this usually means it must run as root).
# password file is in /usr/local/etc/local_passwd
Filename /usr/local/etc/local_passwd

3.39.2. Match

This parameter allows you to use flat files with different formats to the standard Unix password format. Match is a regular expression that is expected to match and extract the user name, password and (optional) primary group ID fields from each line in the password file. The default extracts the first two colon separated fields as user name and password, followed by a UID, followed by an (optional) primary group ID (i.e. standard Unix password file format).
# fields are separated by vertical bar |
Match ^([^\|]*)\|([^\|]*)
The default Match expression is:
Match ^([^:]*):([^:]*):?[^:]*:?([^:]*)

3.39.3. GroupFilename

Specifies the name of the group file. The group file is in standard Unix group file format. Used to check "Group=" check items when authentication is cascaded from another module. Defaults to /etc/group/.
# group file is in /usr/local/etc/local_group
GroupFilename /usr/local/etc/local_group

3.39.4. Nocache

Disables caching of the password and group files, and forces them to be reread for every Authentication. If not set, AuthBy UNIX will only reread the files when their modification time changes. Do not use this parameter unless you have to, because it can be very slow for any more than 1000 users or so.
# Do not cache so we can do some simple testing
# without restarting the server all the time