kerberos-notes.txt

samba最新软件

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.

The checking of this implies a little of the next question:

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...

That said, the current layer provides us with a very good start, and
any redefinition would occour from that basis.


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.

Heimdal has the same problem, and this applies to the krb5 layer, not
just gssapi.

We need to test if the canonicalisation is controlled by the KDCOption
flags, windows always sends the Canonicalize flags

Old Clients (samba3 and HPUX clients) uses 'selfmade' gssapi/krb5
for using it in the CIFS session setup. Because they use krb5_mk_req()
they get a chksum field depending on the encryption type, but that's wrong
for GSSAPI (see rfc 1964 section 1.1.1). The Cheksum type 8003
should be used in the Authenticator of the AP-REQ! That allows the channel bindings,
the GCC_C_* req_flags and optional delegation tickets to be passed from the client to the server.
Hower windows doesn't seems to care about if the checksum is of the wrong type,
for CIFS SessionSetups, it seems that the req_flags are just set to 0.
So this can't work for LDAP connections with sign or seal, or for any DCERPC
connection.

So we need to also support old clients!

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. 

The canonicalisation of names matters not only for the KDC, but also
for code that has to deal with keytabs.

We also need to handle type 10 names (NT-ENTERPRISE), which are a full
principal name in the principal field, unrelated to the realm.

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.


[e-mail] reminds me:

> This is the SPNMappings attribute in Active Directory:

> http://msdn.microsoft.com/library/en-us/adschema/adschema/a_spnmappings.asp

We implement this in hdb-ldb.

Implicit names for Win2000 Accounts
-----------------------------------

Despite not having a DNS name, nor a servicePrincipalName on accounts
created by computers running win2000, it appears we are expected to
have an implicit mapping from host/computer.full.name and
host/computer to it's entry.

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 <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Organization: PADL Software Pty Ltd
To: [e-mail]
Date: Wed, 10 Nov 2004 13:31:21 +1100
Versions: dmail (bsd44) 2.6d/makemail 2.10
Cc: [e-mail], [e-mail]
Subject: Re: Samba-3.0.7-1.3E Active Directory Issues
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail]

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/<SAM-Name-Without-$>.realm@REALM
User Account Without UPN        <SAM-Name>@REALM
User Account With UPN           <LHS-Of-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 [e-mail] 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.

Other odd things:
 - Support for multiple passwords on a client account:  we seem to
   call hdb_next_enctype2key() in the pre-authentication routines to
   allow multiple passwords per account in krb5.  (I think this was
   intened to allow multiple salts)

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.  An 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 has this 'state machine safety' in parts, and we have modified
the lorikeet branch to improve this behviour, when using a new,
non-standard API.  

Heimdal uses a per-context variable for the 'krb5_auth_context', which
controls the ongoing encrypted connection, but does use global
variables for the ubiquitous krb5_context parameter.  

The modification that has added most to 'state machine safety' of
GSSAPI is the addition of the gsskrb5_acquire_creds function.  This
allows the caller to specify a keytab and ccache, for use by the
GSSAPI code.  Therefore there is no need to use global variables to
communicate this information. 

At a more theoritical level (simply counting static and global
variables) Heimdal is not state machine safe for the GSSAPI layer.
The Krb5 layer alone is much closer, as far as I can tell, blocking
excepted. .

To deal with blocking, we could have a fork()ed child per context,
using the 'GSSAPI export context' function to transfer
the GSSAPI state back into the main code for the wrap()/unwrap() part
of the operation.  This will still hit issues of static storage (one