sis.5 (2010 09)

s
sis(5) sis(5)
C. The remote system has an authorization name database file,
aname, that contains the user
principal. The
aname file should contain a mapping of the user principal to an account on the
remote system.
D. The user name in the user principal is the same as the user name of the account being
accessed, and the local and remote systems are in the same realm.
If authorization succeeds, the user will not see a prompt for a password (when a password is required)
and the connection to the remote system will succeed. If the authentication or authorization fails, the
user will be notified of the error and will not be allowed to continue.
Bypassing or Enforcing Authentication/Authorization
If the authentication or authorization fails, the service can be rerun with a special command-line option
(
-P) to request non-Kerberos authentication. However, when a password is required, it will be sent
across the network in a readable form. Typically, this special command-line option should only be used to
access nonsecure remote systems.
The
ftp and telnet daemons have a special command-line option (
-A) which can be used to ensure
that nonsecure systems are denied access.
To prevent nonsecure access through the rcp, remsh or rlogin commands, the
inetd.conf file on the
remote system should be edited to comment out the entries for
shell and login.
SERVICES
ftp, ftpd file transfer program
rlogin, rlogind remote login
telnet, telnetd user interface and server for Telnet protocol
rcp, remshd remote file copy
remsh, remshd execute from a remote shell
TROUBLESHOOTING
For the correct execution of SIS, it is important that the secure environment be properly installed,
configured and running. The following is a quick checklist to verify this:
1. The DCE, Praesidium/Security Server, or Kerberos security system should be running on the Ker-
beros server. The /etc/services
file should contain entries for the Kerberos ports.
2. The user’s user principal must be entered into the Key Distribution Center’s database. Use the
appropriate tool (for example,
kadmin or HP DCE’s dcecp) to list the database and to verify that
the user has a user principal configured.
3. The Kerberos configuration directory on the local and remote systems should contain a
krb.conf,
krb.realms, and a server key table file. Generally, the Kerberos configuration directory will be
/krb5 and the server key table file will be named v5srvtab.
4. The user principal must be specified in the
/etc/krb5/.k5login.login_name or
˜/.k5login
on the local and remote systems. The ˜/.k5login lists the principals and realm names which
have access permission for the user’s account.
Alternatively, the secure system can use an authorization name database,
aname, on the local and
remote systems. An entry in this file will authorize the user name in a user principal to the
specified login name.
Verify that
/etc/krb5/.k5login.login_name or ˜/.k5login exists, has the correct permis-
sions (that is, -rw-r--r--), and includes the user principal. Or, use the appropriate tool (for
example, krb5_anadd on a non-HP DCE system) to verify that the user principal is included in
the aname file.
Note: In the remote system, if the
/etc/krb5/ directory exists, Kerberos ignores the .k5login
file in remote account’s home directory.
5. The server key table file on the remote system should contain a host principal. The root user can
verify the contents of the v5srvtab through the command:
klist -k.Ifklist supports the -k
option, type this command and verify that a host principal is listed.
Alternatively, if the validation tool,
krbval, is available on the system, use the command: krbval
-v.
2 Hewlett-Packard Company − 2 − HP-UX 11i Version 3: September 2010