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 (particularly the AS_REQ) to communicate it's netbios name.
   6 This is (my guess) to 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 abstraction 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 back-end 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 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...
  32
  33
  34 GSSAPI layer requirements
  35 -------------------------
  36
  37 Welcome to the wonderful world of canonicalisation
  38
  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.
  41
  42 Not looked into this on Heimdal quite yet.
  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 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
  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
  70 Jean-Baptiste.Marchand@hsc.fr reminds me:
  71
  72 > This is the SPNMappings attribute in Active Directory:
  73
  74 > http://msdn.microsoft.com/library/en-us/adschema/adschema/a_spnmappings.asp
  75
  76
  77 Returned Salt for PreAuthentication
  78 -----------------------------------
  79
  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).
  84
  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
  87 10 Nov 2004:
  88
  89
  90 From: Luke Howard <lukeh@padl.com>
  91 Message-Id: <200411100231.iAA2VLUW006101@au.padl.com>
  92 MIME-Version: 1.0
  93 Content-Type: text/plain; charset=US-ASCII
  94 Organization: PADL Software Pty Ltd
  95 To: lukeh@padl.com
  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
 102 Precedence: list
 103 Reply-To: lukeh@padl.com
 104
 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
 108 name is different.
 109
 110 Here is what I've been able to deduce from creating a bunch of
 111 different accounts:
 112
 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
 118
 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
 122 effect.
 123
 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.
 130
 131 For more information on how UPNs relate to the Kerberos protocol,
 132 see:
 133
 134 http://www.ietf.org/proceedings/01dec/I-D/draft-ietf-krb-wg-kerberos-referrals-02.txt
 135
 136 -- Luke
 137
 138 --
 139
 140
 141
 142
 143 Heimdal oddities
 144 ----------------
 145
 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.
 149
 150
 151 State Machine safety
 152 --------------------
 153
 154 Samba is a giant state machine, and as such have very different
 155 requirements to those traditionally expressed for kerberos and GSSAPI
 156 libraries.
 157
 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).
 162
 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
 169 encrypted session).
 170
 171 The other issue affecting state machines is 'blocking' (waiting for a
 172 read on a network socket).
 173
 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.
 179
 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.
 182
 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
 187 at a time).
 188
 189
 190 GSSAPI and Kerberos extensions
 191 ------------------------------
 192
 193 This is a general list of the other extensions we have made to / need from
 194 the kerberos libraries
 195
 196  - DCE_STYLE
 197
 198  - gsskrb5_get_initiator_subkey() (return the opposite key to what the
 199    lucid context and get_subkey() calls return).
 200
 201  - gsskrb5_get_authz_data()
 202
 203  - case insensitive keytab
 204  - in-memory keytab
 205  - wildcard keytab (for in-memory operations)
 206
 207 KDC Extensions
 208 --------------
 209
 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.
 213
 214 We currently define 3 classes:
 215  - krbtgt
 216  - client (kinit)
 217  - server (tgt)
 218
 219 I also now specify the kerberos principal as an explict parameter, not
 220 an in/out value on the entry itself.
 221
 222 libkdc
 223 ------
 224
 225 Samba4 needs to be built as a single binary (design requirement), and
 226 this should include the KDC.  Samba also (and perhaps more
 227 importantly) needs to control the configuration environment of the
 228 KDC.
 229
 230 The interface we have defined for libkdc allow for packet injection
 231 into the post-socket layer, with a defined krb5_context and
 232 kdb5_kdc_configuration structure.  These effectively redirect the
 233 kerberos warnings, logging and database calls as we require.
 234
 235 Using our socket lib
 236 --------------------
 237
 238 An important detail in the use of libkdc is that we use our own socket
 239 lib.  This allows the KDC code to be as portable as the rest of samba
 240 (this cuts both ways), but far more importantly it ensures a
 241 consistancy in the handling of requests, binding to sockets etc.
 242
 243 To handle TCP, we will use of our socket layer in much the same way as
 244 we deal with TCP for CIFS.
 245
 246 Kerberos logging support
 247 ------------------------
 248
 249 Samba now (optionally in the main code, required for the KDC) uses the
 250 krb5_log_facility from Heimdal.  This allows us to redirect the
 251 warnings and status from the KDC (and client/server kerberos code) to
 252 Samba's DEBUG() system.
 253
 254 We have added krb5_freelog() to be the opposite of krb5_initlog(), and
 255 ensure we do not leak memeory in this operation. (krb5_closelog() does
 256 not free everything that krb5_initlog creates).
 257
 258
 259