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)