Copyright (c) 2006, Sun Microsystems, Inc. All Rights Reserved
The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License.
You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License.
When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
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.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 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 GSS/Kerberos auth rules):
The user part of the authenticated principal name is the same as the Unix account name specified by the client.
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.
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 authorization. Non-default realms can be equated with the default realm for authenticated name-to-local name mapping.
Per user-account authorization file.
System account file. This information may also be in a directory service. See passwd(4).
See attributes(5) for a description of the following attributes:
| ATTRIBUTE TYPE ATTRIBUTE VALUE |
| Interface Stability Evolving |
ftp(1), rcp(1), rdist(1), rlogin(1), rsh(1), telnet(1), gsscred(1M), kadm5.acl(4), krb5.conf(4), passwd(4), attributes(5), gss_auth_rules(5)