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