10 The authentication server

Note:: The HELIOS authentication server is only available for UNIX based operating systems. The “authutil” client tool (10.2 “authutil”) is available for all platforms.

The authentication server is a foundation service providing login authorization and user credential information for all HELIOS servers and tools. In versions prior to UB, HELIOS services worked directly against the UNIX password and group files or with NIS-based group and password maps. Over time, additional ways of reading user settings were provided, e.g. the Apple user/group storage, LDAP databases, Windows PDC (Primary Domain Controller) and AD (Active Directory), shadow password files and so on. For multi-server environments a central master server storing user information allows other services to access the information from it. Another benefit is that this system allows storing more than the basic user information which goes beyond the standard UNIX password and group file based settings.

The authentication server supports local host users, NIS, LDAP, Mac OS X Password Server and Windows AD/PDC user settings and passwords for all HELIOS services and tools. It is designed to support different databases in parallel (e.g. local UNIX users, and LDAP server) and works completely asynchronously to handle multiple requests without blocking concurrent requests. Its built-in server fail safety allows restarting the authentication service without interrupting other services. Central caching of information speeds up lookups and ensures that all services use identical information.

The goal of the authentication server is to integrate well into different systems. Its central service allows enhancing the authentication server, while staying fully compatible with all HELIOS services and tools.

10.1 The authentication server program

10.1.1 Different user authentication needs

HELIOS provides various services which can use different login methods:

Clear text login
UNIX crypt login
Random number login
LanManager login
NTLMv1 login
NTLMv2 login
DHX128 login
DHCAST128 login
DHX2 login
RSA crypted login

To support all these login methods, including passwords up to 64 characters, it is required that the local user database, NIS or LDAP, stores an additional HELIOS crypted password. On a local system the HELIOS crypted password is stored in “HELIOSDIR/var/conf/passwd”. HELIOS products without this additional password are not supported and will not work. The “authutil” tool allows setting and changing passwords for local host users, and provides crypt, MD5 and HELIOS passwords to import these into an LDAP database.

The authentication server works read-only against LDAP and Windows AD/PDC. The modification of user settings is only supported against local host users or NIS users if the server is the NIS master server. LDAP and Windows AD/PDC users are managed with their own tools.

The following user information is provided from the authentication server to the HELIOS services.

Item	Type	Description
shortname	utf8 str	Host shortname of the user
uid	int32	Primary user ID for this user
gid	int32	Primary group ID for this user
add-gids	int32	Additional group member IDs
fullname	utf8 str	UTF-8 full name (“:” chars are not allowed)
homedir	utf8 str	Home directory path
shell	utf8 str	Start shell program
group names	utf8 str	Name of all groups
cryptpwd	string	Crypted password
heliospwd	hex str	HELIOS crypted password

The listed information is required, additional information may be provided in the future. If additional information needs to be verified, the “var/authsrv/login.pl” script allows verifying additional settings, e.g. login hours to manage access (see also 10.1.4 “Login notification script”).

10.1.2 PAM

PAMs (Pluggable Authentication Modules) are supported on some host operating systems. HELIOS does not need or use any PAMs. As PAM is not available on all systems and cannot support all required authentication methods (listed in 10.1.1 “Different user authentication needs”) the authentication server works without any PAM support. PAM can be activated in parallel to be used by other services.

10.1.3 Authentication server telnet port

Authentication server statistics can be reported to custom applications by the “authsrv” TCP/IP connection via port “2008”. See 8.6 “socket” for a description of the “socket” utility.

: Issue socket 2008

help

Display command overview.

status

List the registered name services (Local, NIS, LDAP, MACOSX, PDC).

users

List user information (authorization; number of references; user ID; user name; full name; time in cache).

groups

List group information (authorization; number of references; group ID; group name; time in cache).

entities

Sum up the users and groups information.

quit

Quit.

10.1.4 Login notification script

Each time a user completes a successful login, i.e. user name and password match, the authentication server calls a custom notification script with the user parameters. The script can exit with:

exit 0      Continue login session 
exit 1      Deny login 
exit 10     Account disabled 
exit 11     Password expired

A custom script allows verifying additional parameters such as the remote TCP/IP address, checking if the user is already logged in from a different IP address and denying or allowing the login request. Another idea is to contact an LDAP database, to verify other information of this user account before allowing the login. To use this script it must be stored as “var/authsrv/login.pl”. The script can be any kind of application or script but it is required to be executable, e.g. mode “711”, and the name must be “login.pl”, even if it is not Perl based. We recommend using a Perl script to stay compatible on different platforms. The following very simple script will log all login parameters tab separated into “/tmp/logfile”:

#!/usr/bin/perl 
my $logfile = "/tmp/logfile"; 
open(LOGF,">> $logfile") || die "authsrv: cannot open: $logfile $!\n"; 
foreach (@ARGV) { 
  print LOGF $_, "\t"; 
} 
print LOGF "\n"; 
close(LOGF); 
exit 0;

The “login.pl” parameters are:

Variable	Description
$ARGV[0]	Host user ID
$ARGV[1]	Host user login name
$ARGV[2]	Windows (AD/PDC) domain name
$ARGV[3]	PID of the server requesting the login
$ARGV[4]	Server name requesting the login, e.g. “afpsrv”, “pcshare”, “websharesrv”
$ARGV[5]	TCP/IP address of the remote client requesting the login
$ARGV[6]	Authentication system providing this user account (local, NIS, LDAP, PDC)

Note:: Changes to the authentication settings require an “authsrv” service restart to take effect.

10.1.5 Local host users/groups

The following list shows the user/group database files used on a server host, e.g. Oracle Solaris. Depending on the operating system an additional shadow like “/etc/passwd” is used. On OS X all user/group information is stored in the Apple user/group storage.

HELIOSDIR/var/conf/passwd	# HELIOS crypted password file
/etc/passwd	# UNIX user file
/etc/group	# UNIX group file
/etc/shadow	# Solaris/Linux password file
/etc/security/passwd	# AIX password file

The Enable Local Authentication checkbox in the HELIOS Admin Local tab must be activated in order to make local authentication work.

10.1.6 NIS users/groups

The Enable NIS checkbox in the HELIOS Admin NIS tab must be activated in order to make NIS authentication work. See 10.3 “Configuration with NIS”.

10.1.7 LDAP

For information on configuring the authentication server for LDAP users, see: www.helios.de/web/EN/support/ldap.html. It includes sample configurations for OS X Server, OpenLDAP, and the Univention LDAP server.

10.1.8 AD/PDC users/groups

The authentication server supports Windows AD/PDC (Active Directory or Primary Domain Controller) for user authentication. The Windows AD/PDC server will provide user name and password as well as primary and supplementary group information. A backup AD/PDC server can be configured and will automatically be used if the main server fails. Unique user IDs are automatically assigned for each user name.

Note:: User and group must belong to the same domain otherwise the related server process will issue an “unable to access user info” error in the system messages.

AD/PDC template user

The required home directory is provided by a template user. The actual user name will replace the template user name in the home directory path.

Creating a PDC user home directory and setting the permissions (assuming that the template PDC user home directory should be located below “/home_pdc”):

: Create a directory for PDC user “myuser”:
# dt mkdir /home_pdc/myuser

: Let ”myuser” log in to the HELIOS server and retrieve its UID:GID values using “authutil”:
# authutil user -n myuser … uid: 50337186 gid: 50332161:Domain Users …

: Then use “dt chown” to set UID:GID:
# dt chown 50337186:50332161 /home_pdc/myuser

: If necessary adjust the permissions using “dt chmod”.

The groups of the template user are provided in addition to the AD/PDC groups.

In case the AD/PDC server does not provide the primary group the template user's primary group is used. For compatibility reasons, users of previous installations, e.g. HELIOS UB⁺, always get their primary group from the template user (see 10.1.9 “Migration from UB⁺”).

Supported AD/PDC servers

Windows Server 2008, 2012

If local UNIX users and AD/PDC users are used in parallel, the authentication order in the NameServices preference must be first local and then AD/PDC.

It is required to set up a user on the AD/PDC server, to enable the authentication server to connect to the AD/PDC server. This user name and password must be specified in the authentication server setup (Fig. 10.1). The credentials can be of any user that exists on the AD/PDC server, so no administrative privileges are required.

Groups in groups

Groups in groups are supported. Every group in group membership is resolved and the complete list of groups is provided for AD/PDC users.

Requirements

The PDC authentication requires the “HELIOS PDC Logon” service (see 10.1.10 “HELIOS PDC Logon”) to be installed on the Windows host that should act as the PDC to the HELIOS installation. This host need not be a Primary or Backup Domain Controller; any Windows host that is part of the desired domain will do.

AD/PDC setup procedure

: Set up a user and password on the Windows AD/PDC server.

Note:: Make sure that user & group names over all specified name services are unique. If e.g. a user or group name already exists locally it should not exist in NIS or LDAP or AD/PDC.

Complete the AD/PDC settings via HELIOS Admin (Fig. 10.1):

Fig. 10.1: HELIOS Admin AD/PDC setup

: In the AD/PDC tab activate the Enable AD/PDC checkbox.

: Specify the Primary Server via TCP/IP address or DNS name.

: Specify Login Name and Password which the authentication server should use to connect to the AD/PDC server.

: Specify an existing local UNIX user as template user in the Local Template User field.

: Save the settings.

Restart the authentication server:

# srvutil stop -f authsrv 
# srvutil start authsrv

Now all HELIOS services should work with the AD/PDC user accounts. A test login can be verified via the HELIOS “authutil” utility (see 10.2 “authutil”):

# authutil login -n username -p password

If a login via “authutil” works without any errors, the Windows AD/PDC authentication can be used by all HELIOS services.

10.1.9 Migration from UB⁺

If you still use the older PDC authentication method (“helauthcreate.exe”) which was used in the pre-UB2 versions, you should migrate to the new method. See the chapter “Migration from UB⁺” in the HELIOS Base UB2 manual.

10.1.10 HELIOS PDC Logon

Note:: If you are using a Windows 2003 or older PDC, the HELIOS PDC Logon software must be installed on a different domain member running Windows 2008 or higher.

HELIOS PDC Logon is installed as a Windows service by running the “setup.exe” program, which is located in the “HELIOS Applications” volume, in the “Windows\AuthServer Tools\HELIOS PDC Logon” folder.

After the installation, the service can be stopped or started using the Windows “Services” utility, or by using the command:
net start heliospdclogon and net stop heliospdclogon, respectively.

Note:: The TCP port 2030 must be open to allow the HELIOS PDC Logon service.

Group inclusion and exclusion

In Windows domain users can be members of many groups. In contrast some UNIX variants only allow a very limited number of groups per user. Known limits are:

OS	Groups	Comment
Solaris 8-11	16	Can be changed to max. 32 (1024 since Solaris 10 8/11, 11.1)
AIX 5.3-7	128	2048 since AIX 7.1
Linux (kernel 2.6 and higher)	65536
OS X 10.6-10.12	16
Windows Server 2008-2012	1024

On UNIX systems you can use the following command line to query the current limit:
# getconf NGROUPS_MAX

To overcome this hurdle HELIOS PDC Logon can report to the “authsrv” only a subset of the groups PDC users are member of.

At startup HELIOS PDC Logon tries to read in two files “group-include.txt” and “group-exclude.txt”. These files reside where HELIOS PDC Logon is installed, i.e. in a default installation this would be “C:\Program Files\HELIOS PDC Logon”.

As its name suggest, “group-include.txt” specifies allowed group names, i.e. any PDC group not mentioned there is ignored. Likewise “group-exclude.txt” specifies group names that are ignored, i.e. all PDC groups not mentioned there are allowed. The exclude list takes precedence over the include list, i.e. a group name that is in both files is filtered out nonetheless.

Group filter file format

The group files have to be UTF-8 encoded. The files have to start with the magic line: # heliospdclogon filter file. The groups must be listed line-separated.

Note:: The “HELIOS PDC Logon” service needs to be restarted if the group filter files have been changed.

Command line options

The “heliospdclogon.exe” utility can also be used from command line.

Usage:

heliospdclogon [-hvisp] [install|remove|dumpgroups]

-h: Display help text.
-v: Be more verbose.
-i: Ignore groups in unsupported domains.
-s: Ignore groups by -i silently.
-p <port>: Listen on this port.

heliospdclogon install: Registers “heliospdclogon” as a Windows service.
heliospdclogon remove: Removes “heliospdclogon” as a Windows service.
heliospdclogon dumpgroups: Prints local and domain groups “heliospdclogon” would report to “authsrv”. Can be used as a template for group filter lists. Group names are UTF-8 encoded.

Example 1:

# cd "C:\Program Files\HELIOS PDC Logon"
# heliospdclogon dumpgroups >group-include.txt

This command writes the complete group list to the file “group-include.txt”, including the required header for a group filter file.

Example 2:

# cd "C:\Program Files\HELIOS PDC Logon"
# heliospdclogon remove
# heliospdclogon -i -s install

These commands remove the Windows service and re-register it with the -i and -s options to silently ignore unsupported domains.

Mapping of Windows SIDs to UNIX user and group IDs

Windows uses SIDs (Security Identifiers) to identify users and groups. HELIOS PDC Logon uses a consistent mapping from SIDs to UNIX user and group IDs:

The “Administrators” group is mapped to group ID 0.
The “Print Operators” group is mapped to group ID 1.
All other user and group SIDs are mapped to a UNIX ID in the range 16777216-83886079 (hex: 0x01000000-0x04FFFFFF), using a built-in algorithm.

10.1.11 HELIOS RSA-based password encryption

The HELIOS UB64 authentication server needs all its passwords to be accessible for the login authentication of the different services (e.g. AFP, SMB, Web). Different services may use different password algorithms for the authentication (MD5, RSA, NTLM, DHX128, etc). To support all these methods, the encrypted password must be verified against the user password entry which is stored in “HELIOSDIR/var/conf/passwd”. To ensure that nobody can read the clear text version of the password entries, all passwords are encrypted allowing only the authentication server to verify these passwords.

The “rsainit” option allows switching from standard HELIOS crypted passwords to RSA-crypted passwords. It generates a random private key file “passwd.key” and converts all existing standard HELIOS encrypted passwords into RSA encrypted passwords. HELIOS highly recommends to activate the RSA encrypted password file which has the following benefits:

Higher security using RSA algorithm with 1024 bit key encryption
Private password key file “passwd.key” per server offers higher security
Optional storage of the private key file on an external device (e.g. by a symlink to a file on a USB flash drive)
Customer accountability for the private master key (not HELIOS Software)

Note:

If the private key file “passwd.key” is missing, users cannot login to the HELIOS services anymore and there is no recovery option. The only option is to first reset all passwords and then issue an “rsainit” to create a new private key.

The private key file “passwd.key” is not included in the automatic backup of the configuration (see 4.9.1 “Automatic backup of the configuration”).

The new HELIOS RSA-based passwords do not affect Active Directory (AD/PDC) nor OS X Server Open Directory authentication environments because these systems use their own password back-end store and password authentication. Using HELIOS RSA passwords on a NIS server requires a HELIOS UB64 installation on the NIS server being RSA enabled via the “rsainit” option. Using HELIOS with a regular LDAP server requires that the HELIOS password be stored in the LDAP password field HeliosPassword. The LDAP user management utility must store the HELIOS RSA-encrypted password in this field. For this case the RSA password string can be printed using the “authutil” program. Section 10.2.7 “rsainit” describes RSA-encrypted password conversion options. 10.2.8 “RSA password migration samples” describes different cases on how RSA passwords can be enabled.

Note:: Technically, “passwd.key” only contains the customer part of the password. The key file itself is not sufficient to decrypt the encoded passwords.

10.1.12 Support

SE004 Authentication server support agreement

The authentication environment can be very complex, and sometimes customers wish to get direct support from HELIOS for planning, configuration, problem analysis and integration of the HELIOS authentication server with the customer NIS, LDAP, AD/PDC setup. For this purpose, a technical support agreement (part no SE004) is available from the HELIOS partner.

Duration three years
No automatic renewal
Available for: HELIOS UB64 or newer products
Covers NIS, LDAP, AD/PDC support
Single agreement covers multiple servers

Include customer signed “SE004.pdf” form with order.

10.2 authutil

The “authutil” utility is a tool for verifying the user/group configuration and managing passwords. It allows displaying user and group entries, validating logins or changing and setting passwords for local host users. “authutil” can generate MD5 passwords used for virtual WebShare users (see WebShare manual) or AFP volume passwords. It also allows printing UNIX or HELIOS crypted passwords for later import into an LDAP database. “authutil” has been designed for the use in scripts or for batch operations, e.g. setting passwords for local host users.

The following commands can be called with “authutil”:

authutil { user | group | guest | login | passwd | batch | rsainit } ...
authutil -h       (for general help)
authutil <cmd> -h (for help on the command <cmd>.)

10.2.1 user

Show information about a user. Either the user name or the user ID must be specified.

Usage:

authutil user [-n <name>] [-i <uid>] [-r] [-q] [-t <timeout>]

The following options are supported:

-n <name>: User name
-i <uid>: User ID
-r: Force refreshing user information rather than using cache data.
-q <quiet>: Print nothing if user does not exist, return exit status only.
-t <timeout>: Timeout in seconds to complete the request.

Example 1:

Querying information on a local user:

$ authutil user -n demouser 
        user: demouser 
         uid: 500 
         gid: 503:demouser 
   long name: Example Demo User 
last refresh: Tue Feb 20 11:32:59 2007 
      origin: local UNIX (*) 
     homedir: /Users/demouser 
      groups: demouser:503, QueueAdm:502

Note:: The origin: line states the used authentication method. This can be either “local UNIX”, “NIS/YP”, “LDAP” or “PDC”.

10.2.2 group

Show information about a group. Either the group name or the group ID must be specified.

Usage:

authutil group [-n <name>] [-i <gid>] [-r] [-q] [-t <timeout>]

The following options are supported:

-n <name>: Group name
-i <gid>: Group ID
-r: Refresh group information.
-q <quiet>: Print nothing if group does not exist, return exit status only.
-t <timeout>: Timeout in seconds to complete the request.

10.2.3 guest

Display guest user.

Usage:

authutil guest [-q] [-t <timeout>]

The following options are supported:

-q <quiet>: Print nothing if user does not exist, return exit status only.
-t <timeout>: Timeout in seconds to complete the request.

10.2.4 login

Verify user password.

Usage:

authutil login -n <name> -p <passwd> [-s] [-q] [-t <timeout>]
               [-m <method>] [-d <domain>]
authutil login -N

The following options are supported:

-n <name>: User name
-p <passwd>: User password
-s: Show user information if login was successful.
-q <quiet>: Print nothing if password was wrong, return exit status only.
-t <timeout>: Timeout in seconds to complete the request.
-m <method>: Encrypt the password before sending it to the authentication server. Available encryption methods. are: RSA, LM, NTLM, NTLMv2, HELPDC.
-d <domain>: AD/PDC domain name
-N: Print CIFS/SMB challenge.

10.2.5 passwd

On UNIX, set the HELIOS and UNIX password. On Windows, set only the HELIOS password, but also verify whether the password specified will result in a successful login.

Usage:

authutil passwd [name]
authutil passwd [-n <name>] [-o <oldpasswd>] [-p <passwd>]
                [-qCHMX] [-t <timeout>] [-m <method>]

The following options are supported:

-n <name>

User name

-o <oldpasswd>

Old password

-p <newpasswd>

New password

-q <quiet>

Print nothing if password change failed, return exit status only.

-C

Print UNIX encoded (crypt) password.

-H

Print HELIOS encoded password.

-M

Print MD5 digest of password.

Note:: Prior to RSA conversion, the old style HELIOS encoded password is printed. After RSA conversion, the RSA encoded password is printer.

-X

Do not change password (to be used with -C, -H or -M option).
You must be root to use this option!

-m <method>

Encrypt the passwords before sending them to the authentication server. The available encryption method is RSA.

-t <timeout>

Timeout in seconds to complete the request.

If the -C, -H, -M options are combined, the results are printed in the order crypt, HELIOS, MD5.

Note:

“root” can set passwords without knowing the old password:

authutil passwd -n username -p newpassword

Examples:

Return MD5 password used for virtual WebShare users:

$ authutil passwd -M -X -p WSpassword

Return HELIOS “hex” crypted password:

$ authutil passwd -H -X -p newpassword

Return UNIX “crypt” password:

$ authutil passwd -C -X -p newpassword

The options -M, -H, -C can also be combined, e.g.:

$ authutil passwd -C -H -M -X -p 123

The “echo” mode (-X option) is helpful when passwords are subject to be imported into a different system, e.g. an LDAP database.

Note:

The MD5 password must be inserted into the “var/conf/webshare.passwd” file. It is much easier to set passwords e.g. within the WebShare User Administration window.

At present, a password can only be set for local UNIX users or NIS users on a NIS master server. AD/PDC users must change the password using the AD/PDC tools.

Setting the HELIOS password with “authutil” on Windows only updates the “HELIOSDIR\var\conf\passwd” file and will NOT change the Windows password. This is required, e.g. for WebShare virtual users or if a user is specified for Script Server scripts or Tool Server tools.

10.2.6 batch

Read commands from the file <batchfile>. If <batchfile> is “-”, commands are read from “stdin”. If a command fails, “authutil” will continue with the next command from <batchfile>, unless option -e is given.

Usage:

authutil batch [-e] <batchfile>

The following option is supported:

-e: Exit immediately if a command failed

Example:

$ authutil batch cmd.txt

The “authutil” return exit code is always 0 on success and ≠0 on failures.

10.2.7 rsainit

Convert all existing HELIOS passwords to the highly secure RSA public-key cryptosystem.

On start, both “authsrv” and “authutil” check for the key file “passwd.key” (see 6.6.1 “HELIOSDIR/var/conf”) and use the key for HELIOS password RSA encoding. If the key file is missing, an error is logged but “authsrv” starts as usual (compatibility for old password encodings).

Important:: The HELIOS services need to be stopped before the conversion is started!

Issuing the authutil rsainit command will create an RSA key and, using this key, convert all entries in the “passwd” file to the new RSA format. Each entry that uses RSA encryption has the prefix “rsa_”, e.g.:
demouser:rsa_33e4a5c037a533685c96db3b8a218c1312caa4a1f963...

Any next authutil rsainit call uses the formerly created key and only converts “old” entries. Or a user may place a formerly created key in “passwd.key” to be used for the first conversion.

The “authutil rsainit” command also allows re-encoding already RSA encrypted passwords with a new RSA key. When calling authutil rsainit -O the former old key (“passwd.key”) is used to decrypt all existing entries which are then encrypted with the new key. When finished, “authutil” saves a new “passwd.key” file, and users can use their existing password for authentication.

“authutil” will only convert local entries. If RSA support for NIS users is required, all passwords must be converted on the NIS master server first by copying the converted file to the corresponding NIS directory and then copying the RSA key file “passwd.key” to each NIS slave on which all the local users are to be converted with “authutil” using the same key.

The RSA key file is only required when the HELIOS services (“authsrv”) are started. Access to the key file can be removed, if this is required for security reasons, as soon as HELIOS is running. This can be implemented, e.g. by using a symbolic link to a mounted USB flash drive, or any other removable device, on which the key file is stored.

Usage:

authutil rsainit [-O] [-b <bits>]

The following options are supported:

-O

Create a new RSA key, re-encode existing entries.

Note:: In case you made use of a symlink from “passwd.key” to your actual key file you need to re-create this link because it was overwritten with the new “passwd.key” file.

-b <bits>

Define bits used for the RSA key. Possible values are 1024, 2048, and 4096. The default is 1024.

10.2.8 RSA password migration samples

This section explains the commands to enable RSA passwords for different environments.

a) Single server with local host users

# stop-helios now
# authutil rsainit
# start-helios

The command generates the “var/conf/passwd.key” file and converts the “var/conf/passwd” entries to RSA-encrypted passwords.

b) Multi-server customer site with local host users

Assuming the customer prefers a single “passwd.key” file to be used on all of their servers, the conversion procedure would be:

: On the first server enter:

# stop-helios now
# authutil rsainit
# start-helios

: Now transfer “var/conf/passwd.key” to all other servers. Then issue on each of these servers:

# stop-helios now
# authutil rsainit
# start-helios

c) Re-creating a private key on a server with local host users

Although the server might already use RSA-encrypted passwords, for security reasons it may be required to create a new private key and convert existing passwords to the new key. This case is useful if somebody has stolen the private key and a completely different key should be used from now on.

# stop-helios now
# authutil rsainit -O
# start-helios

The command generates a new key and converts all passwords using both the old key and the new key. The result will be a new private key file “passwd.key” (which overwrites the previous key file), and all passwords are encrypted using the new key.

d) Re-creating all passwords using a pre-defined private key file

This is a special situation of b) for additional servers which should use a given key file to convert existing RSA passwords into new passwords using a new private key.

# stop-helios now
# cp my-new-key-file var/conf/passwd.key.new
# authutil rsainit -O
# mv var/conf/passwd.key.new var/conf/passwd.key
# start-helios

This procedure converts all passwords using the “passwd.key” for existing passwords and re-encodes them using the new key “passwd.key.new” and updates the “var/conf/passwd” file with new encrypted passwords. When finished, the new key file must be manually renamed to the default key file.

10.3 Configuration with NIS

The authentication server was designed to support the UNIX NIS (Network Information Service) system, which, in a network of several UNIX hosts, allows user names, group names, and passwords as well as other configuration details to be stored centrally on the NIS (formerly named “Yellow Pages”) Master host. This considerably simplifies the setup of new users, particularly if they each need access to more than one host. Please note that the user configuration data maintained under NIS is only stored on the Master NIS host. You can only change it with HELIOS Admin if the HELIOS host is the Master NIS host, and not one of the NIS Slaves.

You can edit the NIS password and group files to set up NIS users with standard UNIX NIS tools in the normal way. We would like to point out, however, that if the HELIOS host is the Master NIS host, then HELIOS Admin is much easier to use for setting up NIS users and groups than the standard UNIX tools. It can be used to set up both HELIOS users and regular UNIX users.

The user list “HELIOSDIR/var/conf/passwd” can also be used with the NIS system by setting up, on the NIS Master host, a second password file (“afppasswd”) which contains the names of all users of the Master host and its interconnected NIS Slaves. This additional password file is located in the same directory as the NIS password and group files, e.g.: “/var/yp/afppasswd”.

The “HELIOSDIR/var/conf/passwd” file of each host in the NIS system (master and slaves) can optionally include a line containing only “+:” at the position where the NIS user and group map should be included. It usually follows entries for the “root” and the system users, to make sure that it is still possible to log on to the host in case of a failure of the network connection to the Master:

root:rsa_6c81d86b8876d75e87ecba9cead8a605022903bc3e7f9c2413c89h70rtnz...
+:

The installation includes the “HELIOSDIR/etc/ypMakefile” script, which contains the necessary changes required to implement the HELIOS user list under NIS. Enter the group- and password-related information in “/var/yp/Makefile” according to the information given in “HELIOSDIR/etc/ypMakefile”.

Note:: You should be familiar with editing such files in order to provide proper operation of NIS administration.

When the NIS system is being used, the HELIOS Admin server automatically calls “HELIOSDIR/sbin/yp-update” whenever user or group data is changed, in order to update the NIS files.

10.3.1 HELIOS services configuration on a NIS Master

The HELIOS services do support NIS. The configuration on a NIS Master needs however a meticulous setup. This section describes the needed tasks for a NIS setup with HELIOS services. NIS can be set up with or without separate “passwd” and “group” files. In both cases an additional NIS map is required to hold the HELIOS passwords.

If your YP directory is not “/var/yp”, set the preference ypdir and replace “/var/yp” with your YP directory in the following instructions.

NIS configuration with separate “passwd”/“group” files

With this configuration, the YP directory contains separate files (“passwd” and “group”) which are used for the NIS “passwd” and “group” maps. This means that NIS users and groups are different from the local host users and groups in “/etc/passwd” and “/etc/group”.

Configure the additional NIS map “afppasswd”:

: Edit “/var/yp/Makefile” and add rules for the “afppasswd” map. See “HELIOSDIR/etc/ypMakefile” for an example Makefile.

: Touch “/var/yp/afppasswd” to create an initial empty map.

: Call “make” in “/var/yp”, restart NIS, and restart the HELIOS services.

All user/group changes on the NIS Master server via HELIOS Admin are stored in “/var/yp/passwd”, “/var/yp/group” and “/var/yp/afppasswd”.

NIS configuration without separate “passwd”/“group” files

With this configuration, NIS uses the files “/etc/passwd” and “/etc/group” for the “passwd” and “group” maps. This means that every user/group on the host is also a NIS user/group in the network.

Configure the additional NIS map “afppasswd”:

: Edit “/var/yp/Makefile” and add rules for the “afppasswd” map. See “HELIOSDIR/etc/ypMakefile” for an example Makefile. In the Makefile, replace “$(DIR)/afppasswd” with “HELIOSDIR/var/conf/passwd”, where HELIOSDIR is your HELIOS installation directory.

Set the ypmapdir preference to “/etc”:

prefvalue -k Programs/authsrv/ypmapdir -t str "/etc"

: Call “make” in “/var/yp”, restart NIS and then restart the HELIOS services.

All user/group changes on the NIS Master server via HELIOS Admin are stored in “/etc/passwd”, “/etc/group” and “HELIOSDIR/var/conf/passwd”.

NIS verification

: Check that the correct NIS entries are listed with the commands:

ypcat passwd 
ypcat group 
ypcat afppasswd

The authutil login -n nisuser -p password -s command should return no error message and display a user record like:

        user: nisuser 
         uid: 124 
         gid: 30:helios 
   long name: HELIOS Software Support 
last refresh: Fri Oct 26 15:30:43 2014 
      origin: NIS/YP (*) 
     homedir: /home/nisuser 
      groups: helios:30, usr:100

Note that the “origin” shows a NIS user.

HELIOS Manuals February 6, 2019

10 The authentication server

10.1 The authentication server program

10.1.1 Different user authentication needs

10.1.2 PAM

10.1.3 Authentication server telnet port

10.1.4 Login notification script

10.1.5 Local host users/groups

10.1.6 NIS users/groups

10.1.7 LDAP

10.1.8 AD/PDC users/groups

10.1.9 Migration from UB+

10.1.10 HELIOS PDC Logon

10.1.11 HELIOS RSA-based password encryption

10.1.12 Support

10.2 authutil

10.2.1 user

10.2.2 group

10.2.3 guest

10.2.4 login

10.2.5 passwd

10.2.6 batch

10.2.7 rsainit

10.2.8 RSA password migration samples

10.3 Configuration with NIS

10.3.1 HELIOS services configuration on a NIS Master

10.1.9 Migration from UB⁺