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)