Standards, Environments, and Macros krb5authrules(5)
NAME
krb5authrules - 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
GS/Kerberos authentication rules successfully map the Ker-
beros 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.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 ori-
ginating 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 table does not exist, the client is
granted access to the account under the following conditions
(default GS/Kerberos auth rules):
SunOS 5.11 Last change: 07 Apr 2006 1
Standards, Environments, and Macros krb5authrules(5)
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) authtolocalrealm
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) authtolocalrealm 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(4).
ATRIBUTES
See attributes(5) for a description of the following attri-
butes:
ATRIBUTE TYPE ATRIBUTE VALUE
Interface Stability Evolving
SEE ALSO
ftp(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), gssauthrules(5)
SunOS 5.11 Last change: 07 Apr 2006 2
|
