1krb5_auth_rules(5) Standards, Environments, and Macros krb5_auth_rules(5)
2
3
4
6 krb5_auth_rules - overview of Kerberos V5 authorization
7
9 When kerberized versions of the ftp, rdist, rcp, rlogin, rsh, telnet,
10 or ssh clients are used to connect to a server, the identity of the
11 originating user must be authenticated to the Kerberos V5 authentica‐
12 tion system. Account access can then be authorized if appropriate
13 entries exist in the ~/.k5login file, the gsscred table, or if the
14 default GSS/Kerberos authentication rules successfully map the Kerberos
15 principal name to Unix login name.
16
17
18 To avoid security problems, the ~/.k5login file must be owned by the
19 remote user on the server the client is attempting to access. The file
20 should contain a private authorization list comprised of Kerberos prin‐
21 cipal names of the form principal/instance@realm. The /instance vari‐
22 able is optional in Kerberos principal names. For example, different
23 principal names such as jdb@ENG.ACME.COM and
24 jdb/happy.eng.acme.com@ENG.ACME.COM would each be legal, though not
25 equivalent, Kerberos principals. The client is granted access if the
26 ~/.k5login file is located in the login directory of the remote user
27 account and if the originating user can be authenticated to one of the
28 principals named in the file. See gkadmin(1M) and kadm5.acl(4) for more
29 information on Kerberos principal names.
30
31
32 When no ~/.k5login file is found in the remote user's login account,
33 the Kerberos V5 principal name associated with the originating user is
34 checked against the gsscred table. If a gsscred table exists and the
35 principal name is matched in the table, access is granted if the Unix
36 user ID listed in the table corresponds to the user account the client
37 is attempting to access. If the Unix user ID does not match, access is
38 denied. See gsscred(1M).
39
40
41 For example, an originating user listed in the gsscred table with the
42 principal name jdb@ENG.ACME.COM and the uid 23154 is granted access to
43 the jdb-user account if 23154 is also the uid of jdb-user listed in the
44 user account database. See passwd(4).
45
46
47 Finally, if there is no ~/.k5login file and the Kerberos V5 identity of
48 the originating user is not in the gsscred table, or if the gsscred ta‐
49 ble does not exist, the client is granted access to the account under
50 the following conditions (default GSS/Kerberos auth rules):
51
52 o The user part of the authenticated principal name is the
53 same as the Unix account name specified by the client.
54
55 o The realm part of the client and server are the same, unless
56 the krb5.conf(4) auth_to_local_realm parameter is used to
57 create equivalence.
58
59 o The Unix account name exists on the server.
60
61
62 For example, if the originating user has the principal name
63 jdb@ENG.ACME.COM and if the server is in realm SALES.ACME.COM, the
64 client would be denied access even if jdb is a valid account name on
65 the server. This is because the realms SALES.ACME.COM and ENG.ACME.COM
66 differ.
67
68
69 The krb5.conf(4) auth_to_local_realm parameter also affects authoriza‐
70 tion. Non-default realms can be equated with the default realm for
71 authenticated name-to-local name mapping.
72
74 ~/.k5login Per user-account authorization file.
75
76
77 /etc/passwd System account file. This information may also be in a
78 directory service. See passwd(4).
79
80
82 See attributes(5) for a description of the following attributes:
83
84
85
86
87 ┌─────────────────────────────┬─────────────────────────────┐
88 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
89 ├─────────────────────────────┼─────────────────────────────┤
90 │Interface Stability │Evolving │
91 └─────────────────────────────┴─────────────────────────────┘
92
94 ftp(1), rcp(1), rdist(1), rlogin(1), rsh(1), telnet(1), gkadmin(1M),
95 gsscred(1M), kadm5.acl(4), krb5.conf(4), passwd(4), attributes(5),
96 gss_auth_rules(5)
97
98
99
100SunOS 5.11 07 Apr 2006 krb5_auth_rules(5)