'\" te

.\" Copyright (c) 2006, 2013, Oracle and/or its affiliates. All rights reserved.

.SH NAME

krb5_auth_rules \- overview of Kerberos V5 authorization

.SH DESCRIPTION

.sp

.LP

When kerberized versions of the \fBftp\fR, \fBrcp\fR, \fBrlogin\fR, \fBrsh\fR, \fBssh\fR, \fBtelnet\fR, or \fBssh\fR 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 \fB~/.k5login\fR file, the \fBgsscred\fR table, or if the default GSS/Kerberos authentication rules successfully map the Kerberos principal name to Unix login name.

.sp

.LP

To avoid security problems, the \fB~/.k5login\fR 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 \fIprincipal/instance\fR@\fI realm\fR. The \fI/instance\fR variable is optional in Kerberos principal names. For example, different principal names such as \[email protected]\fR and \fBjdb/[email protected]\fR would each be legal, though not equivalent, Kerberos principals. The client is granted access if the \fB~/.k5login\fR 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 \fBkadm5.acl\fR(4) for more information on Kerberos principal names.

.sp

.LP

When no \fB~/.k5login\fR file is found in the remote user's login account, the Kerberos V5 principal name associated with the originating user is checked against the \fBgsscred\fR table. If a \fBgsscred\fR 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 \fBgsscred\fR(1M).

.sp

.LP

For example, an originating user listed in the \fBgsscred\fR table with the principal name \[email protected]\fR and the \fBuid\fR  \fB23154\fR is granted access to the \fBjdb-user\fR account if \fB23154\fR is also the \fBuid\fR of \fBjdb-user\fR listed in the user account database. See \fBpasswd\fR(4).

.sp

.LP

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

.RS +4

.TP

.ie t \(bu

.el o

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

.RE

.RS +4

.TP

.ie t \(bu

.el o

The realm part of the client and server are the same, unless the \fBkrb5.conf\fR(4)  \fIauth_to_local_realm\fR parameter is used to create equivalence.

.RE

.RS +4

.TP

.ie t \(bu

.el o

The Unix account name exists on the server.

.RE

.sp

.LP

For example, if the originating user has the principal name \[email protected]\fR and if the server is in realm \fBSALES.ACME.COM\fR, the client would be denied access even if \fBjdb\fR is a valid account name on the server. This is because the realms \fBSALES.ACME.COM\fR and \fBENG.ACME.COM\fR differ.

.sp

.LP

The \fBkrb5.conf\fR(4)  \fIauth_to_local_realm\fR parameter also affects authorization. Non-default realms can be equated with the default realm for authenticated \fBname-to-local name\fR mapping.

.SH FILES

.sp

.ne 2

.mk

.na

\fB\fB~/.k5login\fR\fR

.ad

.RS 15n

.rt

Per user-account authorization file.

.RE

.sp

.ne 2

.mk

.na

\fB\fB/etc/passwd\fR\fR

.ad

.RS 15n

.rt

System account file. This information may also be in a directory service. See \fBpasswd\fR(4).

.RE

.SH SEE ALSO

.sp

.LP

\fBftp\fR(1), \fBrcp\fR(1), \fBrsh\fR(1), \fBtelnet\fR(1), \fBgsscred\fR(1M), \fBkadm5.acl\fR(4), \fBkrb5.conf\fR(4), \fBpasswd\fR(4), \fBattributes\fR(5), \fBgss_auth_rules\fR(5)