AllowedWorkstationNames and Krb5 -------------------------------- Microsoft uses the clientAddresses *multiple value* field in the krb5 protocol (particularly the AS_REQ) to communicate it's netbios name. This is (my guess) to permit the userWorkstations field to work. The KDC I imagine checks the netbios address against this value, in the same way that the Samba server does this. Is a DAL the layer we need? --------------------------- Looking at what we need to pass around, I start to seriously wonder if the DAL is even the right layer - we seem to want to create an account authorization abstraction layer - is this account permitted to login to this computer, at this time? This information in AD is much richer than the Heimdal HDB, and it seems to make sense to do AD-specific access control checks in an AD-specific layer, not in the back-end agnostic server. Because the DAL only reads in the principalName as the key, it has trouble performing access control decisions on things other than the name. I'll be very interested if the DAL really works for eDirectory too. Perhaps all we need to do is add in the same kludges as we have in Samba 3.0 for eDirectory. Hmm... GSSAPI layer requirements ------------------------- Welcome to the wonderful world of canonicalisation The MIT GSSAPI libs do not support kinit returning a different realm to what the client asked for, even just in case differences. Not looked into this on Heimdal quite yet. Principal Names, long and short names ------------------------------------- As far as servicePrincipalNames are concerned, these are not canonicalised, except as regards the realm in the reply. That is, the client gets back the principal it asked for, with the realm portion 'fixed' to uppercase, long form. The short name of the realm seems to be accepted for at least AS_REQ operations, but because the server performs canonicalisation, this causes pain for current client libraries. HOST/ Aliases ------------- There is another post somewhere (ref lost for the moment) that details where in active directory the list of stored aliases for HOST/ is. This should be read, parsed and used to allow any of these requests to use the HOST/ key. For example, this is how HTTP/, DNS/ and CIFS/ can use HOST/ without any explicit entry. Jean-Baptiste.Marchand@hsc.fr remainds me: > This is the SPNMappings attribute in Active Directory: > http://msdn.microsoft.com/library/en-us/adschema/adschema/a_spnmappings.asp Returned Salt for PreAuthentication ----------------------------------- When the server replies for pre-authentication, it returns the Salt, which may be in the form of a principalName that is in no way connected with the current names. (ie, even if the userPrincipalName and samAccountName are renamed, the old salt is returned). This is probably the kerberos standard salt, kept in the 'Key'. The standard generation rules are found in a Mail from Luke Howard dated 10 Nov 2004: From: Luke Howard Message-Id: <200411100231.iAA2VLUW006101@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: lukeh@padl.com Date: Wed, 10 Nov 2004 13:31:21 +1100 Versions: dmail (bsd44) 2.6d/makemail 2.10 Cc: huaraz@moeller.plus.com, samba-technical@lists.samba.org Subject: Re: Samba-3.0.7-1.3E Active Directory Issues X-BeenThere: samba-technical@lists.samba.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: lukeh@padl.com Did some more testing, it appears the behaviour has another explanation. It appears that the standard Kerberos password salt algorithm is applied in Windows 2003, just that the source principal name is different. Here is what I've been able to deduce from creating a bunch of different accounts: Type of account Principal for Salting ======================================================================== Computer Account host/.realm@REALM User Account Without UPN @REALM User Account With UPN @REALM Note that if the computer account's SAM account name does not include the trailing '$', then the entire SAM account name is used as input to the salting principal. Setting a UPN for a computer account has no effect. It seems to me odd that the RHS of the UPN is not used in the salting principal. For example, a user with UPN foo@mydomain.com in the realm MYREALM.COM would have a salt of MYREALM.COMfoo. Perhaps this is to allow a user's UPN suffix to be changed without changing the salt. And perhaps using the UPN for salting signifies a move away SAM names and their associated constraints. For more information on how UPNs relate to the Kerberos protocol, see: http://www.ietf.org/proceedings/01dec/I-D/draft-ietf-krb-wg-kerberos-referrals-02.txt -- Luke -- Heimdal oddities ---------------- Heimdal is built such that it should be able to serve multiple realms at the same time. This isn't relevant for Samba's use, but it shows up in a lot of generalisations throughout the code. State Machine safety -------------------- Samba is a giant state machine, and as such have very different requirements to those traditionally expressed for kerberos and GSSAPI libraries. Samba requires all of the libraries it uses to be state machine safe in their use of internal data. This does not mean thread safe, and an application could be thread safe, but not state machine safe (if it instead used thread-local variables). So, what does it mean for a library to be state machine safe? This is mostly a question of context, and how the library manages whatever internal state machines it has. If the library uses a context variable, passed in by the caller, which contains all the information about the current state of the library, then it is safe. A n example of this state is the sequence number and session keys for an ongoing encrypted session). The other issue affecting state machines is 'blocking' (waiting for a read on a network socket). Heimdal is not state machine safe for the GSSAPI layer in particular. Krb5 alone is much closer, as far as I can tell (the exception being the error string handling). Adding safety is so 'easy', it is very, very tempting to modify the APIs required and 'just do it'. Testing is a different problem however. We may just use a fork()ed child to handle this, and have one process per context. This is primarily to solve the non-blocking issue. I had hoped to use the 'GSSAPI export context' function to transfer the GSSAPI state back into the main code for the wrap()/unwrap() part of the operation, but we still hit issues of static storage (one gss_krb5_context per process, and multiple GSSAPI encrypted sessions at a time). GSSAPI and Kerberos extensions ------------------------------ This is a general list of the other extensions we have made to / need from the kerberos libraries - DCE_STYLE - gsskrb5_get_initiator_subkey() (return the opposite key to what the lucid context and get_subkey() calls return). - gsskrb5_get_authz_data() - case insensitive keytab - in-memory keytab - wildcard keytab (for in-memory operations) KDC Extensions -------------- We have modified Heimdal's 'hdb' interface to specify the 'type' of Principal being requested. This allows us to correctly behave with the different 'classes' of Principal name. We currently define 3 classes: - krbtgt - client (kinit) - server (tgt) I also now specify the kerberos principal as an explict parameter, not an in/out value on the entry itself.