KRB5_AUTH_RULES(7) Standards, Environments, and Macros KRB5_AUTH_RULES(7)

NAME

krb5_auth_rules - overview of Kerberos V5 authorization

DESCRIPTION

When kerberized versions of the ftp, rdist, rcp, rlogin, rsh, telnet,
or ssh clients are used to connect to a server, the identity of the
originating user must be authenticated to the Kerberos V5
authentication system. Account access can then be authorized if
appropriate entries exist in the ~/.k5login file, the gsscred table,
or if the default GSS/Kerberos authentication rules successfully map
the Kerberos principal name to Unix login name.


To avoid security problems, the ~/.k5login file must be owned by the
remote user on the server the client is attempting to access. The
file should contain a private authorization list comprised of
Kerberos principal names of the form principal/instance@realm. The
/instance variable is optional in Kerberos principal names. For
example, different principal names such as jdb@ENG.EXAMPLE.COM and
jdb/happy.eng.example.com@ENG.EXAMPLE.COM would each be legal, though
not equivalent, Kerberos principals. The client is granted access if
the ~/.k5login file is located in the login directory of the remote
user account and if the originating user can be authenticated to one
of the principals named in the file. See kadm5.acl(5) for more
information on Kerberos principal names.


When no ~/.k5login file is found in the remote user's login account,
the Kerberos V5 principal name associated with the originating user
is checked against the gsscred table. If a gsscred table exists and
the principal name is matched in the table, access is granted if the
Unix user ID listed in the table corresponds to the user account the
client is attempting to access. If the Unix user ID does not match,
access is denied. See gsscred(8).


For example, an originating user listed in the gsscred table with the
principal name jdb@ENG.EXAMPLE.COM and the uid 23154 is granted
access to the jdb-user account if 23154 is also the uid of jdb-user
listed in the user account database. See passwd(5).


Finally, if there is no ~/.k5login file and the Kerberos V5 identity
of the originating user is not in the gsscred table, or if the
gsscred table does not exist, the client is granted access to the
account under the following conditions (default GSS/Kerberos auth
rules):

o The user part of the authenticated principal name is the
same as the Unix account name specified by the client.

o The realm part of the client and server are the same,
unless the krb5.conf(5) auth_to_local_realm parameter is
used to create equivalence.

o The Unix account name exists on the server.


For example, if the originating user has the principal name
jdb@ENG.EXAMPLE.COM and if the server is in realm SALES.EXAMPLE.COM,
the client would be denied access even if jdb is a valid account name
on the server. This is because the realms SALES.EXAMPLE.COM and
ENG.EXAMPLE.COM differ.


The krb5.conf(5) auth_to_local_realm parameter also affects
authorization. Non-default realms can be equated with the default
realm for authenticated name-to-local name mapping.

FILES

~/.k5login
Per user-account authorization file.


/etc/passwd
System account file. This information may also be in a
directory service. See passwd(5).

ATTRIBUTES

See attributes(7) for a description of the following attributes:


+--------------------+-----------------+
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
+--------------------+-----------------+
|Interface Stability | Evolving |
+--------------------+-----------------+

SEE ALSO

ftp(1), rcp(1), rdist(1), rlogin(1), rsh(1), telnet(1), kadm5.acl(5),
krb5.conf(5), passwd(5), attributes(7), gss_auth_rules(7), gsscred(8)

November 22, 2021 KRB5_AUTH_RULES(7)