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.
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...
34 GSSAPI layer requirements
35 -------------------------
37 Welcome to the wonderful world of canonicalisation
39 The MIT GSSAPI libs do not support kinit returning a different
40 realm to what the client asked for, even just in case differences.
42 Not looked into this on Heimdal quite yet.
45 Principal Names, long and short names
46 -------------------------------------
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.
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.
61 There is another post somewhere (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
66 For example, this is how HTTP/, DNS/ and CIFS/ can use HOST/ without
70 Jean-Baptiste.Marchand@hsc.fr remainds me:
72 > This is the SPNMappings attribute in Active Directory:
74 > http://msdn.microsoft.com/library/en-us/adschema/adschema/a_spnmappings.asp
77 Returned Salt for PreAuthentication
78 -----------------------------------
80 When the server replies for pre-authentication, it returns the Salt,
81 which may be in the form of a principalName that is in no way
82 connected with the current names. (ie, even if the userPrincipalName
83 and samAccountName are renamed, the old salt is returned).
85 This is probably the kerberos standard salt, kept in the 'Key'. The
86 standard generation rules are found in a Mail from Luke Howard dated
90 From: Luke Howard <lukeh@padl.com>
91 Message-Id: <200411100231.iAA2VLUW006101@au.padl.com>
93 Content-Type: text/plain; charset=US-ASCII
94 Organization: PADL Software Pty Ltd
96 Date: Wed, 10 Nov 2004 13:31:21 +1100
97 Versions: dmail (bsd44) 2.6d/makemail 2.10
98 Cc: huaraz@moeller.plus.com, samba-technical@lists.samba.org
99 Subject: Re: Samba-3.0.7-1.3E Active Directory Issues
100 X-BeenThere: samba-technical@lists.samba.org
101 X-Mailman-Version: 2.1.4
103 Reply-To: lukeh@padl.com
105 Did some more testing, it appears the behaviour has another
106 explanation. It appears that the standard Kerberos password salt
107 algorithm is applied in Windows 2003, just that the source principal
110 Here is what I've been able to deduce from creating a bunch of
113 Type of account Principal for Salting
114 ========================================================================
115 Computer Account host/<SAM-Name-Without-$>.realm@REALM
116 User Account Without UPN <SAM-Name>@REALM
117 User Account With UPN <LHS-Of-UPN>@REALM
119 Note that if the computer account's SAM account name does not include
120 the trailing '$', then the entire SAM account name is used as input to
121 the salting principal. Setting a UPN for a computer account has no
124 It seems to me odd that the RHS of the UPN is not used in the salting
125 principal. For example, a user with UPN foo@mydomain.com in the realm
126 MYREALM.COM would have a salt of MYREALM.COMfoo. Perhaps this is to
127 allow a user's UPN suffix to be changed without changing the salt. And
128 perhaps using the UPN for salting signifies a move away SAM names and
129 their associated constraints.
131 For more information on how UPNs relate to the Kerberos protocol,
134 http://www.ietf.org/proceedings/01dec/I-D/draft-ietf-krb-wg-kerberos-referrals-02.txt
146 Heimdal is built such that it should be able to serve multiple realms
147 at the same time. This isn't relevant for Samba's use, but it shows
148 up in a lot of generalisations throughout the code.
154 Samba is a giant state machine, and as such have very different
155 requirements to those traditionally expressed for kerberos and GSSAPI
158 Samba requires all of the libraries it uses to be state machine safe in
159 their use of internal data. This does not mean thread safe, and an
160 application could be thread safe, but not state machine safe (if it
161 instead used thread-local variables).
163 So, what does it mean for a library to be state machine safe? This is
164 mostly a question of context, and how the library manages whatever
165 internal state machines it has. If the library uses a context
166 variable, passed in by the caller, which contains all the information
167 about the current state of the library, then it is safe. A n example
168 of this state is the sequence number and session keys for an ongoing
171 The other issue affecting state machines is 'blocking' (waiting for a
172 read on a network socket).
174 Heimdal is not state machine safe for the GSSAPI layer in particular.
175 Krb5 alone is much closer, as far as I can tell (the exception being the
176 error string handling). Adding safety is so 'easy', it is very, very
177 tempting to modify the APIs required and 'just do it'. Testing is a
178 different problem however.
180 We may just use a fork()ed child to handle this, and have one process
181 per context. This is primarily to solve the non-blocking issue.
183 I had hoped to use the 'GSSAPI export context' function to transfer
184 the GSSAPI state back into the main code for the wrap()/unwrap() part
185 of the operation, but we still hit issues of static storage (one
186 gss_krb5_context per process, and multiple GSSAPI encrypted sessions
190 GSSAPI and Kerberos extensions
191 ------------------------------
193 This is a general list of the other extensions we have made to / need from
194 the kerberos libraries
198 - gsskrb5_get_initiator_subkey() (return the opposite key to what the
199 lucid context and get_subkey() calls return).
201 - gsskrb5_get_authz_data()
203 - case insensitive keytab
205 - wildcard keytab (for in-memory operations)
210 We have modified Heimdal's 'hdb' interface to specify the 'type' of
211 Principal being requested. This allows us to correctly behave with
212 the different 'classes' of Principal name.
214 We currently define 3 classes:
219 I also now specify the kerberos principal as an explict parameter, not
220 an in/out value on the entry itself.