krb5_auth_rules(5) Standards, Environments, and Macros krb5_auth_rules(5)NAMEkrb5_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 authentica‐
tion 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 prin‐
cipal names of the form principal/instance@realm. The /instance vari‐
able is optional in Kerberos principal names. For example, different
principal names such as jdb@ENG.ACME.COM and
jdb/happy.eng.acme.com@ENG.ACME.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 gkadmin(1M) and kadm5.acl(4) 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(1M).
For example, an originating user listed in the gsscred table with the
principal name jdb@ENG.ACME.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(4).
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 ta‐
ble 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(4) 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.ACME.COM and if the server is in realm SALES.ACME.COM, the
client would be denied access even if jdb is a valid account name on
the server. This is because the realms SALES.ACME.COM and ENG.ACME.COM
differ.
The krb5.conf(4) auth_to_local_realm parameter also affects authoriza‐
tion. 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(4).
ATTRIBUTES
See attributes(5) for a description of the following attributes:
┌─────────────────────────────┬─────────────────────────────┐
│ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
├─────────────────────────────┼─────────────────────────────┤
│Interface Stability │Committed │
└─────────────────────────────┴─────────────────────────────┘
SEE ALSOftp(1), rcp(1), rdist(1), rlogin(1), rsh(1), telnet(1), gkadmin(1M),
gsscred(1M), kadm5.acl(4), krb5.conf(4), passwd(4), attributes(5),
gss_auth_rules(5)SunOS 5.11 07 Apr 2006 krb5_auth_rules(5)