1 AllowedWorkstationNames and Krb5
2 --------------------------------
4 Microsoft uses the clientAddresses *multiple value* field in the krb5
5 protocol (particularly the AS_REQ) to communicate it's netbios name.
6 This is (my guess) to permit the userWorkstations field to work.
8 The KDC I imagine checks the netbios address against this value, in
9 the same way that the Samba server does this.
11 The checking of this implies a little of the next question:
13 Is a DAL the layer we need?
14 ---------------------------
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 abstraction layer - is this account permitted to login to
19 this computer, at this time?
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 back-end agnostic server.
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
29 I'll be very interested if the DAL really works for eDirectory too.
30 Perhaps all we need to do is add in the same kludges as we have in
31 Samba 3.0 for eDirectory. Hmm...
33 That said, the current layer provides us with a very good start, and
34 any redefinition would occour from that basis.
37 GSSAPI layer requirements
38 -------------------------
40 Welcome to the wonderful world of canonicalisation
42 The MIT GSSAPI libs do not support kinit returning a different
43 realm to what the client asked for, even just in case differences.
45 Heimdal has the same problem, and this applies to the krb5 layer, not
48 We need to test if the canonicalisation is controlled by the KDCOption
49 flags, windows always sends the Canonicalize flags
51 Old Clients (samba3 and HPUX clients) uses 'selfmade' gssapi/krb5
52 for using it in the CIFS session setup. Because they use krb5_mk_req()
53 they get a chksum field depending on the encryption type, but that's wrong
54 for GSSAPI (see rfc 1964 section 1.1.1). The Cheksum type 8003
55 should be used in the Authenticator of the AP-REQ! That allows the channel bindings,
56 the GCC_C_* req_flags and optional delegation tickets to be passed from the client to the server.
57 Hower windows doesn't seems to care about if the checksum is of the wrong type,
58 for CIFS SessionSetups, it seems that the req_flags are just set to 0.
59 So this can't work for LDAP connections with sign or seal, or for any DCERPC
62 So we need to also support old clients!
64 Principal Names, long and short names
65 -------------------------------------
67 As far as servicePrincipalNames are concerned, these are not
68 canonicalised, except as regards the realm in the reply. That is, the
69 client gets back the principal it asked for, with the realm portion
70 'fixed' to uppercase, long form.
72 The short name of the realm seems to be accepted for at least AS_REQ
73 operations, but because the server performs canonicalisation, this
74 causes pain for current client libraries.
76 The canonicalisation of names matters not only for the KDC, but also
77 for code that has to deal with keytabs.
82 There is another post somewhere (ref lost for the moment) that details
83 where in active directory the list of stored aliases for HOST/ is.
84 This should be read, parsed and used to allow any of these requests to
87 For example, this is how HTTP/, DNS/ and CIFS/ can use HOST/ without
91 Jean-Baptiste.Marchand@hsc.fr reminds me:
93 > This is the SPNMappings attribute in Active Directory:
95 > http://msdn.microsoft.com/library/en-us/adschema/adschema/a_spnmappings.asp
97 We implement this in hdb-ldb.
100 Returned Salt for PreAuthentication
101 -----------------------------------
103 When the server replies for pre-authentication, it returns the Salt,
104 which may be in the form of a principalName that is in no way
105 connected with the current names. (ie, even if the userPrincipalName
106 and samAccountName are renamed, the old salt is returned).
108 This is probably the kerberos standard salt, kept in the 'Key'. The
109 standard generation rules are found in a Mail from Luke Howard dated
113 From: Luke Howard <lukeh@padl.com>
114 Message-Id: <200411100231.iAA2VLUW006101@au.padl.com>
116 Content-Type: text/plain; charset=US-ASCII
117 Organization: PADL Software Pty Ltd
119 Date: Wed, 10 Nov 2004 13:31:21 +1100
120 Versions: dmail (bsd44) 2.6d/makemail 2.10
121 Cc: huaraz@moeller.plus.com, samba-technical@lists.samba.org
122 Subject: Re: Samba-3.0.7-1.3E Active Directory Issues
123 X-BeenThere: samba-technical@lists.samba.org
124 X-Mailman-Version: 2.1.4
126 Reply-To: lukeh@padl.com
128 Did some more testing, it appears the behaviour has another
129 explanation. It appears that the standard Kerberos password salt
130 algorithm is applied in Windows 2003, just that the source principal
133 Here is what I've been able to deduce from creating a bunch of
136 Type of account Principal for Salting
137 ========================================================================
138 Computer Account host/<SAM-Name-Without-$>.realm@REALM
139 User Account Without UPN <SAM-Name>@REALM
140 User Account With UPN <LHS-Of-UPN>@REALM
142 Note that if the computer account's SAM account name does not include
143 the trailing '$', then the entire SAM account name is used as input to
144 the salting principal. Setting a UPN for a computer account has no
147 It seems to me odd that the RHS of the UPN is not used in the salting
148 principal. For example, a user with UPN foo@mydomain.com in the realm
149 MYREALM.COM would have a salt of MYREALM.COMfoo. Perhaps this is to
150 allow a user's UPN suffix to be changed without changing the salt. And
151 perhaps using the UPN for salting signifies a move away SAM names and
152 their associated constraints.
154 For more information on how UPNs relate to the Kerberos protocol,
157 http://www.ietf.org/proceedings/01dec/I-D/draft-ietf-krb-wg-kerberos-referrals-02.txt
169 Heimdal is built such that it should be able to serve multiple realms
170 at the same time. This isn't relevant for Samba's use, but it shows
171 up in a lot of generalisations throughout the code.
177 Samba is a giant state machine, and as such have very different
178 requirements to those traditionally expressed for kerberos and GSSAPI
181 Samba requires all of the libraries it uses to be state machine safe in
182 their use of internal data. This does not mean thread safe, and an
183 application could be thread safe, but not state machine safe (if it
184 instead used thread-local variables).
186 So, what does it mean for a library to be state machine safe? This is
187 mostly a question of context, and how the library manages whatever
188 internal state machines it has. If the library uses a context
189 variable, passed in by the caller, which contains all the information
190 about the current state of the library, then it is safe. An example
191 of this state is the sequence number and session keys for an ongoing
194 The other issue affecting state machines is 'blocking' (waiting for a
195 read on a network socket).
197 Heimdal has this 'state machine safety' in parts, and we have modified
198 the lorikeet branch to improve this behviour, when using a new,
201 Heimdal uses a per-context variable for the 'krb5_auth_context', which
202 controls the ongoing encrypted connection, but does use global
203 variables for the ubiquitous krb5_context parameter.
205 The modification that has added most to 'state machine safety' of
206 GSSAPI is the addition of the gsskrb5_acquire_creds function. This
207 allows the caller to specify a keytab and ccache, for use by the
208 GSSAPI code. Therefore there is no need to use global variables to
209 communicate this information.
211 At a more theoritical level (simply counting static and global
212 variables) Heimdal is not state machine safe for the GSSAPI layer.
213 The Krb5 layer alone is much closer, as far as I can tell, blocking
216 To deal with blocking, we could have a fork()ed child per context,
217 using the 'GSSAPI export context' function to transfer
218 the GSSAPI state back into the main code for the wrap()/unwrap() part
219 of the operation. This will still hit issues of static storage (one
220 gss_krb5_context per process, and multiple GSSAPI encrypted sessions
221 at a time) but these may not matter in practice.
224 GSSAPI and Kerberos extensions
225 ------------------------------
227 This is a general list of the other extensions we have made to / need from
228 the kerberos libraries
232 - gsskrb5_get_initiator_subkey() (return the opposite key to what the
233 lucid context and get_subkey() calls return).
235 - gsskrb5_get_authz_data()
237 - gsskrb5_acquire_creds() (takes keytab and/or ccache as input
238 parameters, see keytab and state machine discussion)
243 Because windows machine account handling is very different to the
244 tranditional 'MIT' keytab operation. This starts when we look at the
245 basis of the secrets handling:
247 Traditional 'MIT' behaviour is to use a keytab, continaing salted key
248 data, extracted from the KDC. (In this modal, there is no 'service
249 password', instead the keys are often simply application of random
250 bytes). Heimdal also implements this behaviour.
252 The windows modal is very different - instead of sharing a keytab with
253 each member server, a password is stored for the whole machine. The
254 password is set with non-kerberos mechanisms (particularly SAMR, a
255 DCE-RPC service) and when interacting on a kerberos basis, the
256 password is salted by the client. (That is, no salt infromation
257 appears to be convayed from the KDC to the member).
259 In dealing with this modal, the traditional file keytab seems
260 outmoded, because it is not the primary source of the keys, and as
261 such we have replaced it with an IN-MEMORY keytab. This avoids Samba4
262 needing to deal with system files for it's internal operation. (We
263 will however forward-port parts of Samba3's net ads keytab, for the
264 benifit of other applications).
266 When dealing with a windows KDC, the behaviour regarding case
267 sensitivity and canonacolisation must be accomidated. This means that
268 an incoming request to a member server may have a wide variety of
269 service principal names. These include:
271 machine$@REALM (samba clients)
272 HOST/foo.bar@realm (win2k clients)
273 HOST/foo@realm (win2k clients, using netbios)
274 cifs/foo.bar@realm (winxp clients)
275 cifs/foo@realm (winxp clients, using netbios)
277 as well as all case variations on the above.
279 Because that all got 'too hard' to put into a keytab (and because we
280 still wanted to supply a keytab to the GSSAPI code), a 'wildcard'
281 keytab was devised. MEMORY_WILDCARD: is much like MEMORY:, except it
282 only matches on kvno, rather than on the principal name.
284 Extra Heimdal functions used
285 ----------------------------
286 (an attempt to list some of the Heimdal-specific functions I know we use)
288 krb5_make_principal()
289 krb5_free_keyblock_contents()
294 We have modified Heimdal's 'hdb' interface to specify the 'type' of
295 Principal being requested. This allows us to correctly behave with
296 the different 'classes' of Principal name.
298 We currently define 2 classes:
302 I also now specify the kerberos principal as an explict parameter, not
303 an in/out value on the entry itself.
305 Inside hdb-ldb, we add krbtgt as a special class of principal, because
306 of particular special-case backend requirements.
311 Samba4 needs to be built as a single binary (design requirement), and
312 this should include the KDC. Samba also (and perhaps more
313 importantly) needs to control the configuration environment of the
316 The interface we have defined for libkdc allow for packet injection
317 into the post-socket layer, with a defined krb5_context and
318 kdb5_kdc_configuration structure. These effectively redirect the
319 kerberos warnings, logging and database calls as we require.
324 An important detail in the use of libkdc is that we use our own socket
325 lib. This allows the KDC code to be as portable as the rest of samba
326 (this cuts both ways), but far more importantly it ensures a
327 consistancy in the handling of requests, binding to sockets etc.
329 To handle TCP, we will use of our socket layer in much the same way as
330 we deal with TCP for CIFS. Tridge has promised this generalisation.
332 Kerberos logging support
333 ------------------------
335 Samba now (optionally in the main code, required for the KDC) uses the
336 krb5_log_facility from Heimdal. This allows us to redirect the
337 warnings and status from the KDC (and client/server kerberos code) to
338 Samba's DEBUG() system.
340 Similarly important is the Heimdal-specific krb5_get_error_string()
341 function, which does a lot to reduce the 'administrator pain' level,
342 by providing specific, english text-string error messages instead of
343 just error code translations.