r6797: Typo fix.
[samba.git] / source / auth / kerberos / kerberos-notes.txt
1 AllowedWorkstationNames and Krb5
2 --------------------------------
3
4 Microsoft uses the clientAddresses *multiple value* field in the krb5
5 protocol to communicate it's netbios name.  This is (my guess) to
6 permit the userWorkstations field to work.
7
8 The KDC I imagine checks the netbios address against this value, in
9 the same way that the Samba server does this.
10
11
12
13 Is a DAL the layer we need?
14 ---------------------------
15
16 Looking at what we need to pass around, I start to seriously wonder if
17 the DAL is even the right layer - we seem to want to create an account
18 authorization abstracton layer - is this account permitted to login to
19 this computer, at this time?
20
21 This information in AD is much richer than the Heimdal HDB, and it
22 seems to make sense to do AD-specific access control checks in an
23 AD-specific layer, not in the backend agnostic server.
24
25 Because the DAL only reads in the principalName as the key, it has
26 trouble performing access control decisions on things other than the
27 name.
28
29 I'll be very intersted if the DAL really works for eDirectory too.
30 Perhaps all we need to do is add in the same cludges as we have in
31 Samba 3.0 for eDirectory.  Hmm...
32
33
34 GSSAPI layer requirements
35 -------------------------
36
37 Welcome to the wonderful world of canonicalisation
38
39 The Heimdal GSSAPI libs do not support kinit returning a different
40 realm to what the client asked for, even just in case differences.
41
42 No idea on MIT
43
44
45 Principal Names, long and short names
46 -------------------------------------
47
48 As far as servicePrincipalNames are concerned, these are not
49 canonicalised, except as regards the realm in the reply.  That is, the
50 client gets back the principal it asked for, with the realm portion
51 'fixed' to uppercase, long form.  
52
53 The short name of the realm seems to be accepted for at least AS_REQ
54 operations, but because the server performs canonicalisation, this
55 causes pain for current client libraries. 
56
57
58 HOST/ Aliases
59 -------------
60
61 There is another post somehwere (ref lost for the moment) that details
62 where in active directory the list of stored aliases for HOST/ is.
63 This should be read, parsed and used to allow any of these requests to
64 use the HOST/ key.
65
66 For example, this is how HTTP/, DNS/ and CIFS/ can use HOST/ without
67 any explicit entry.
68
69 Returned Salt for PreAuthentication
70 -----------------------------------
71
72 When the server replies for pre-authentication, it returns the Salt,
73 which may be in the form of a principalName that is in no way
74 connected with the current names.  (ie, even if the userPrincipalName
75 and samAccountName are renamed, the old salt is returned).
76
77 This is probably the kerberos standard salt, kept in the 'Key'.  The
78 standard generation rules are found in a Mail from Luke howard dated
79 10 Nov 2004:
80
81
82 From: Luke Howard <lukeh@padl.com>
83 Message-Id: <200411100231.iAA2VLUW006101@au.padl.com>
84 MIME-Version: 1.0
85 Content-Type: text/plain; charset=US-ASCII
86 Organization: PADL Software Pty Ltd
87 To: lukeh@padl.com
88 Date: Wed, 10 Nov 2004 13:31:21 +1100
89 Versions: dmail (bsd44) 2.6d/makemail 2.10
90 Cc: huaraz@moeller.plus.com, samba-technical@lists.samba.org
91 Subject: Re: Samba-3.0.7-1.3E Active Directory Issues
92 X-BeenThere: samba-technical@lists.samba.org
93 X-Mailman-Version: 2.1.4
94 Precedence: list
95 Reply-To: lukeh@padl.com
96
97 Did some more testing, it appears the behaviour has another
98 explanation. It appears that the standard Kerberos password salt
99 algorithm is applied in Windows 2003, just that the source principal
100 name is different.
101
102 Here is what I've been able to deduce from creating a bunch of
103 different accounts:
104
105 Type of account         Principal for Salting
106 ========================================================================
107 Computer Account                host/<SAM-Name-Without-$>.realm@REALM
108 User Account Without UPN        <SAM-Name>@REALM
109 User Account With UPN           <LHS-Of-UPN>@REALM
110
111 Note that if the computer account's SAM account name does not include
112 the trailing '$', then the entire SAM account name is used as input to
113 the salting principal. Setting a UPN for a computer account has no
114 effect.
115
116 It seems to me odd that the RHS of the UPN is not used in the salting
117 principal. For example, a user with UPN foo@mydomain.com in the realm
118 MYREALM.COM would have a salt of MYREALM.COMfoo. Perhaps this is to
119 allow a user's UPN suffix to be changed without changing the salt. And
120 perhaps using the UPN for salting signifies a move away SAM names and
121 their associated constraints.
122
123 For more information on how UPNs relate to the Kerberos protocol,
124 see:
125
126 http://www.ietf.org/proceedings/01dec/I-D/draft-ietf-krb-wg-kerberos-referrals-02.txt
127
128 -- Luke
129
130 --
131
132
133
134
135 Heimdal oddities
136 ----------------
137
138 Heimdal is built such that it should be able to serve muliple realms
139 at the same time.  This isn't relevent for Samba's use, but it shows
140 up in a lot of generalisations thougout the code.
141
142
143 GSSAPI and Kerberos extensions
144 ------------------------------
145
146 This is a general list of the extensions we have made to / need from the kerberos libraries
147
148  - DCE_STYLE
149
150  - gsskrb5_get_initiator_subkey()
151
152  - gsskrb5_get_authz_data()
153
154  - case insensitive keytab
155  - in-memory keytab
156  - wildcard keytab (for in-memory operations)
157
158
159 KDC Extensions
160 --------------
161
162 We have modified Heimdal's 'hdb' interface to specify the 'type' of
163 prinicpal being requested.  This allows us to correctly behave with
164 the different 'classes' of prinicpal name. 
165
166 We currently define 3 classes:
167  - krbtgt
168  - client (kinit)
169  - server (tgt)
170
171 I also now specify the kerberos principal as an explict parameter, not
172 an in/out value on the entry itself.
173
174
175
176