|
|
User account
06-20-2013
root:
password = Xlen7kw02f234
lastupdate = 1894726232|
|
|
|
krb5_auth_rules(5) Standards, Environments, and Macros krb5_auth_rules(5) NAME
krb5_auth_rules - Overview of Kerberos V5 authorization DESCRIPTION
When a user uses kerberized versions of the ftp, rdist, rcp, rlogin, rsh, or telnet clients to connect to a server, even if the user's claimed Kerberos V5 identity is authenticated, the user is not necessarily authorized. Authentication merely proves that the user is "who he says he is" to the Kerberos V5 authentication system. Authorization also needs to be done, since it determines if that Kerberos identity is permitted to access the Solaris user account that the client wants to access. Each user may have a private authorization list in a file ~/.k5login in his login directory (on the server). Each line in this file should contain a Kerberos principal name of the form principal/instance@realm. If the server finds a ~/.k5login file, then access is granted to the account if and only if the originating user is authenticated to one of the principals named in the ~/.k5login file. If there is no ~/.k5login file, the originating user will then be checked against the gsscred table (see gsscred(1M)). If the originating user's Kerberos V5 identity is in the gsscred table, and if the UNIX user id in the gsscred table corresponds to the user account the client is trying access, then the originating user is granted access to the account on the server. If the UNIX user id does not match, then the originating user is denied access. For example, suppose the originating user has a principal name of jdb@ENG.ACME.COM and the target account is jdb-user. If jdb@ENG.ACME.COM appears in the gsscred table with uid 23154 and if jdb-user appears in the user account database (see passwd(4)) with uid 23154, then access to account jdb-user is granted. Of course, normally, the target account name in this example would be jdb and not jdb-user. Finally, if there is no ~/.k5login file and if the originating user's Kerberos V5 identity is not in the gsscred table, then the user will be granted access to the account if and only if all of the following are true: o The user part of the authenticated principal name is the same as the target account name specified by the client. o The realm part of the client and server are the same. o The target account name exists on the server. For example, if the originating user has a principal name of jdb@ENG.ACME.COM and if the server is in realm SALES.ACME.COM, then even if jdb is a valid account name on the server, the client would be denied access. This is because the realms SALES.ACME.COM and ENG.ACME.COM differ. 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 |Evolving | +-----------------------------+-----------------------------+ SEE ALSO
ftp(1), rcp(1), rdist(1), rlogin(1), rsh(1), telnet(1), gsscred(1M), passwd(4), attributes(5), gss_auth_rules(5) NOTES
To avoid security problems, the ~/.k5login file must be owned by the remote user. SunOS 5.10 13 Apr 2004 krb5_auth_rules(5)