diff options
| -rw-r--r-- | source4/auth/kerberos-notes.txt | 760 |
1 files changed, 0 insertions, 760 deletions
diff --git a/source4/auth/kerberos-notes.txt b/source4/auth/kerberos-notes.txt deleted file mode 100644 index 78efe179c1..0000000000 --- a/source4/auth/kerberos-notes.txt +++ /dev/null @@ -1,760 +0,0 @@ -Copyright Andrew Bartlett <abartlet@samba.org> 2005-2009 -Copyright Donald T. Davis <don@mit.edu> - -Released under the GPLv3 - -Important context for porting to MIT ------------------------------------- - -This document should be read in conjuction with the Samba4 source code. -DAL and KDC requirements are expressed (as an implementation against Heimdal's -HDB abstraction layer) in Samba4's source4/kdc/hdb-samba4.c in particular. -hbd-samba4.c is the biggest piece of samba-to-krb glue layer, so the main -part of the port to MIT is to replace hdb-samba4 with a similar glue layer -that's designed for MIT's code. - -PAC requirements are implemeneted in source4/kdc/pac-glue.c - -The plugins (both of the above are Heimdal plugins) for the above are loaded -in source4/kdc/kdc.c - -For GSSAPI requirements, see auth/gensec/gensec_gssapi.c (the consumer of -GSSAPI in Samba4) - -For Kerberos requirements, see auth/kerberos/krb5_init_context.c . - -Samba has its own credentials system, wrapping GSS creds, just as GSS -creds wrap around krb5 creds. For the interaction between Samba4 credentials -system and GSSAPI and Kerberos see auth/credentials/credentials_krb5.c . - -AllowedWorkstationNames and Krb5 --------------------------------- - -Microsoft uses the clientAddresses *multiple value* field in the krb5 -protocol (particularly the AS_REQ) to communicate the client's netbios -name (legacy undotted name, <14 chars) - -This is (my guess) to support the userWorkstations field (in user's AD record). -The idea is to support client-address restrictions, as was standard in NT: -The AD authentication server I imagine checks the netbios address against -this userWorkstations value (BTW, the NetLogon server does this, too). - -The checking of this field implies a little of the next question: - -Is a DAL the layer we need? ---------------------------- - -Looking at what we need to pass around, I don't think -the DAL is even the right layer; what we really want -is to create an account-authorization abstraction layer -(e.g., is this account permitted to login to this computer, -at this time?). -Here is how we ended up doing this in Heimdal: - * We created a separate plugin, with this API: - typedef struct hdb_entry_ex { - void *ctx; - hdb_entry entry; - void (*free_entry)(krb5_context, struct hdb_entry_ex *); - } hdb_entry_ex; - - * The void *ctx is a "private pointer," provided by the 'get' method's - hdb_entry_ex retval. The APIs below use the void *ctx so as to find - additional information about the user, not contained in the hdb_entry - structure. Both the provider and the APIs below understand how to cast - the private void *ctx pointer. - - typedef krb5_error_code - (*krb5plugin_windc_pac_generate)(void *, krb5_context, - struct hdb_entry_ex *, krb5_pac*); - typedef krb5_error_code - (*krb5plugin_windc_pac_verify)(void *, krb5_context, - const krb5_principal, - struct hdb_entry_ex *, - struct hdb_entry_ex *, - krb5_pac *); - typedef krb5_error_code - (*krb5plugin_windc_client_access)(void *, - krb5_context, - struct hdb_entry_ex *, - KDC_REQ *, krb5_data *); - - * (The krb5_data* here is critical, so that samba's KDC can return - the right NTSTATUS code in the 'error string' returned to the client. - Otherwise, the windows client won't get the right error message to - the user (such as 'password expired' etc). The pure Kerberos error - is not enough) - - typedef struct krb5plugin_windc_ftable { - int minor_version; - krb5_error_code (*init)(krb5_context, void **); - void (*fini)(void *); - rb5plugin_windc_pac_generate pac_generate; - krb5plugin_windc_pac_verify pac_verify; - krb5plugin_windc_client_access client_access; - } krb5plugin_windc_ftable; - This API has some heimdal-specific stuff, that'll have to change when we port the plugin to MIT krb. - * 1st callback (pac_generate) creates an initial PAC from the user's AD record. - * 2nd callback (pac_verify) check that a PAC is correctly signed, add additional groups (for cross-realm tickets) and re-sign with the key of the target kerberos service's account - * 3rd callback (client_access) perform additional access checks, such as allowedWorkstations and account expiry. - * for example, to register this plugin, use the kdc's standard - plugin-system at Samba4's initialisation: - /* first, setup the table of callback pointers */ - /* Registar WinDC hooks */ - ret = krb5_plugin_register(krb5_context, - PLUGIN_TYPE_DATA, "windc", - &windc_plugin_table); - /* once registered, the KDC will invoke the callbacks */ - /* while preparing each new ticket (TGT or app-tkt) */ - * an alternate way to register the plugin is with a config-file that names - a DSO (Dynamically Shared Object). - - -This plugin helps bridge an important gap: The user's AD record is much -richer than the Heimdal HDB format allows, so we do AD-specific access -control checks in an AD-specific layer (ie, the plugin), not in the -DB-agnostic KDC server. - -In Novell's pure DAL approach, the DAL only read in the principalName as -the key, so it had trouble performing access-control decisions on things -other than the name (like the addresses). - -There is another, currently unhandled challenge in this area - the need to handle -bad password counts (and good password notification), so that a single policy can -be applied against all means of checking a password (NTLM, Kerberos, LDAP Simple -bind etc) - -The Original work by Novell in creating a DAL did not seem to provide a way to -update the PW counts information. Nevertheless, we know that this is very much -required (and may have been addressed in Simo's subsequent IPA-KDC design), -because in Samba3+eDirectory, great lengths are taken to update this information. - -GSSAPI layer requirements -------------------------- - -Welcome to the wonderful world of canonicalisation - -The MIT Krb5 libs (including GSSAPI) 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 too applies to the krb5 layer, not -just gssapi. - -there's two kinds of name-canonicalization that can occur: - * lower-to-upper case conversion, because Windows domain names are - usually in upper case; - * an unrecognizable subsitution of names, such as might happen when - a user requests a ticket for a NetBIOS domain name, but gets back - a ticket for the corresponging FQDN. - -As developers, we should test if the AD KDC's name-canonicalisation -can be turned off with the KDCOption flags in the AS-REQ or TGS-REQ; -Windows clients always send the Canonicalize flags as KDCOption values. - -Old Clients (samba3 and HPUX clients) use 'selfmade' gssapi/krb5 tokens -for use in the CIFS session setup. these hand-crafted ASN.1 packets don't -follow rfc1964 perfectly, so server-side krblib code has to be flexible -enough to accept these bent tokens. -It turns out that Windows' GSSAPI server-side code is sloppy about checking -some GSSAPI tokens' checksums. During initial work to implement an AD client, -it was easier to make an acceptable solution (to Windows servers) than to -correctly implement the GSSAPI specification, particularly on top of the -(inflexible) MIT Kerberos API. It did not seem possible to write a correct, -seperate GSSAPI implementation on top of MIT Kerberos's public krb5lib API, -and at the time, the effort did not need to extend beyond what Windows would -require. - -The upshot is that old Samba3 clients send GSSAPI tokens bearing incorrect -checksums, which AD's Krb5lib cheerfully accepts (but accepts the good checksums, -too). Similarly, Samba4's heimdal krb5lib accepts these incorrect checksums. -Accordingly, if MIT's krb5lib wants to interoperate with the old Samba3 clients, -then MIT's library will have to do the same. - -Because these old clients use krb5_mk_req() -the app-servers get a chksum field depending on the encryption type, but that's -wrong for GSSAPI (see rfc 1964 section 1.1.1). The Checksum type 8003 should -be used in the Authenticator of the AP-REQ! That (correct use of the 8003 type) -would allows the channel bindings, the GCC_C_* req_flags and optional delegation -tickets to be passed from the client to the server. However windows doesn't -seem to care whether the checksum is of the wrong type, and for CIFS SessionSetups, -it seems that the req_flags are just set to 0. -This deviant checksum can't work for LDAP connections with sign or seal, or -for any DCERPC connection, because those connections do not require the -negotiation of GSS-Wrap paraemters (signing or sealing of whole payloads). -Note: CIFS has an independent SMB signing mechanism, using the Kerberos key. - -see heimdal/lib/gssapi/krb5/accept_sec_context.c, lines 390-450 or so. - -This bug-compatibility is likely to be controversial in the kerberos community, -but a similar need for bug-compatibility arose around MIT's & Heimdal's both -failing to support TGS_SUBKEYs correctly, and there are numerous other cases. -see https://lists.anl.gov/pipermail/ietf-krb-wg/2009-May/007630.html - -So MIT's krb5lib needs to also support old clients! - -Principal Names, long and short names -------------------------------------- - -As far as servicePrincipalNames are concerned, these are not -canonicalised by AD's KDC, 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. -Heimdal doesn't canonicalize names, but Samba4 does some canonicalization: -For hostnames and usernames, Samba4 canonicalizes the requested name only -for the LDAP principal-lookup, but then Samba4 returns the retrieved LDAP -record with the request's original, uncanonicalized hostname replacing the -canonicalized name that actually was retrieved. -AB says that for usernames, Samba4 used to return the canonicalized username, -as retrieved from LDAP. The reason for the different treatment was that -the user needs to present his own canonicalized username to servers, for -ACL-matching. For hostnames this isn't necessary. -So, for bug-compatibility, we may need to optionally disable any -namne-canonicalization that MIT's KDC does. - -The short name of the realm seems to be accepted for at least AS_REQ -operations, but the AD KDC always performs realm-canonicalisation, -which converts the short realm-name to the canonical long form. -So, this causes pain for current krb client libraries. - -The canonicalisation of names matters not only for the KDC, but also -for code that has to deal with keytabs. -With credential-caches, when canonicalization leads to cache-misses, -the client just asks for new credentials for the variant server-name. -This could happen, for example, if the user asks to access the server -twice, using different variants of the server-name. - -We also need to handle type 10 names (NT-ENTERPRISE), which are a full -principal name in the principal field, unrelated to the realm. -The principal field contains both principal & realm names, while the -realm field contains a realm name, too, possibly different. -For example, an NT-ENTERPRISE principal name might look like: -joeblow@microsoft.com@NTDEV.MICROSOFT.COM , -<--principal field-->|<----realm name--->| - -Where joe@microsoft.com is the leading portion, and NTDEV.MICROSOFT.COM is -the realm. This is used for the 'email address-like login-name' feature of AD. - -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 list is read & parsed by the AD KDC, so as to allow any of these -aliased ticket-requests to use the HOST/ key. - -Samba4 currently has set: -sPNMappings: host=ldap,dns,cifs,http (but dns's presence is a bug, somehow) - -AD actually has ~50 entries: - -sPNMappings: host=alerter,appmgmt,cisvc,clipsrv,browser,dhcp,dnscache,replicat - or,eventlog,eventsystem,policyagent,oakley,dmserver,dns,mcsvc,fax,msiserver,i - as,messenger,netlogon,netman,netdde,netddedsm,nmagent,plugplay,protectedstora - ge,rasman,rpclocator,rpc,rpcss,remoteaccess,rsvp,samss,scardsvr,scesrv,seclog - on,scm,dcom,cifs,spooler,snmp,schedule,tapisrv,trksvr,trkwks,ups,time,wins,ww - w,http,w3svc,iisadmin,msdtc - -Domain members that expect the longer list will break in damb4, as of 6/09. -AB says he'll try to fix this right away. - -For example, this is how HTTP/, and CIFS/ can use HOST/ without -any explicit entry in the servicePrincipalName attribute - - -For example, the application-server might have (on its AD record): -servicePrincipalName: HOST/my.computer@MY.REALM - -but the client asks for a ticket to cifs/my.computer@MY.REALM -AD looks in LDAP for both name-variants -AD then transposes cifs -> host after performing the lookup in the -directory (for the original name), then looks for host/my.computer@MY.REALM - -for hostnames & usernames, alternate names appear as extra values in -the multivalued "principal name" attributes: - - For hostnames, the other names (other than it's short name, implied - from the CN), is stored in the servicePrincipalName - - For usernames, the other names are stored in the userPrincipalName - attribute, and can be full e-mail address like names, such as - joe@microsoft.com (see above). - -Jean-Baptiste.Marchand@hsc.fr 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 ------------------------------------ -AD's records for servers are keyed by CN or by servicePrincipalName, -but for win2k boxes, these records don't include servicePrincipalName, -so, the CN attribute is used instead. -Despite not having 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 the computer's entry in the AD LDAP database -(ie, be able to obtain tickets for that host name in the KDC). - -Returned Salt for PreAuthentication ------------------------------------ - -When the KDC 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 the kerberos standard salt, kept in the 'Key'. The -AD generation rules are found in a Mail from Luke Howard dated -10 Nov 2004. The MIT glue layer doesn't really need to care about -these salt-handling details; the samba4 code & the LDAP backend -will conspire to make sure that MIT's KDC gets correct salts. - - -From: Luke Howard <lukeh@padl.com> -Organization: PADL Software Pty Ltd -To: lukeh@padl.com -Date: Wed, 10 Nov 2004 13:31:21 +1100 -Cc: huaraz@moeller.plus.com, samba-technical@lists.samba.org -Subject: Re: Samba-3.0.7-1.3E Active Directory Issues -------- - -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: -[SAM name in this mail means the AD attribute samAccountName . - E.g., jbob for a user and jbcomputer$ for a computer.] - -[UPN is the AD userPrincipalName attribute. For example, jbob@mydomain.com] - -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 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. - -Samba4's code originally tried internally to make it possible to use -Heimdal's multi-realms-per-KDC ability, but this was ill-conceived, -and AB has recently (6/09) ripped the last of that multi-realms -stuff out of samba4. AB says that in AD, it's not really possible -to make this work; several AD components structurally assume that -there's one realm per KDC. However, we do use this to support -canonicalization of realm-names: case variations, plus long-vs-short -variants of realm-names. - -Other odd things: - - Heimdal supports multiple passwords on a client account: Samba4 - seems to call hdb_next_enctype2key() in the pre-authentication - routines to allow multiple passwords per account in krb5. - (I think this was intended to allow multiple salts). - AD doesn't support this, so the MIT port shouldn't bother with - this. - -State Machine safety when using Kerberos and GSSAPI libraries -------------------------------------------------------------- - -Samba's client-side & app-server-side libraries are built on 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). Samba's non-blocking I/O doesn't like -waiting for libkrb5 to go away for awhile to talk to the KDC. - -Samba4 provides a hook 'send_to_kdc', that allows Samba4 to take over the -IO handling, and run other events in the meantime. This uses a -'nested event context' (which presents the challenges that the kerberos -library might be called again, while still in the send_to_kdc hook). - -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 to tunnelling a ccache (containing a set of tickets) -through the gssapi, by temporarily casting the ccache pointer to a -gss credential pointer. -This new API is Heimdal's samba4-requested gss_krb5_import_cred() fcn; -this will have to be rewritten or ported in the MIT port. - -This replaces an older scheme using the KRB5_CCACHE -environment variable to get the same job done. This tunnelling trick -enables a command-line app-client to run kinit tacitly, before running -GSSAPI for service-authentication. This tunnelling trick avoids the -more usual approach of keeping the ccache pointer in a global variable. - -No longer true; the krb5_context global is gone now: -[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 gss_krb5_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 about keytab & ccache. - -At a more theoritical level (simply counting static and global -variables) Heimdal is not state machine safe for the GSSAPI layer. -(Heimdal is now (6/09) much more nearly free of globals.) -The Krb5 layer alone is much closer, as far as I can tell, blocking -excepted. . - - -As an alternate to fixing MIT Kerberos for better safety in this area, -a new design might be implemented in Samba, where blocking read/write -is made to the KDC in another (fork()ed) child process, and the results -passed back to the parent process for use in other non-blocking operations. - -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 -gss_krb5_context per process, and multiple GSSAPI encrypted sessions -at a time) but these may not matter in practice. - -This approach has long been controversial in the Samba team. -An alternate way would be to be implement E_AGAIN in libkrb5: similar -to the way to way read() works with incomplete operations. to do this -in libkrb5 would be difficult, but valuable. - -In the short-term, we deal with blocking by taking over the network -send() and recv() functions, therefore making them 'semi-async'. This -doens't apply to DNS yet.These thread-safety context-variables will -probably present porting problems, during the MIT port. This will -probably be most of the work in the port to MIT. - - - -GSSAPI and Kerberos extensions ------------------------------- - -This is a general list of the other extensions we have made to / need from -the kerberos libraries - - - DCE_STYLE : Microsoft's hard-coded 3-msg Challenge/Response handshake - emulates DCE's preference for C/R. Microsoft calls this DCE_STYLE. - MIT already has this nowadays (6/09). - - - gsskrb5_get_initiator_subkey() (return the exact key that Samba3 - has always asked for. gsskrb5_get_subkey() might do what we need - anyway). This is necessary, because in some spots, Microsoft uses - raw Kerberos keys, outside the Kerberos protocls, and not using Kerberos - wrappings etc. Ie, as a direct input to MD5 and ARCFOUR, without using - the make_priv() or make_safe() calls. - - - gsskrb5_acquire_creds() (takes keytab and/or ccache as input - parameters, see keytab and state machine discussion in prev section) - -Not needed anymore, because MIT's code now handles PACs fully: - - gss_krb5_copy_service_keyblock() (get the key used to actually - encrypt the ticket to the server, because the same key is used for - the PAC validation). - - gsskrb5_extract_authtime_from_sec_context (get authtime from - kerberos ticket) - - gsskrb5_extract_authz_data_from_sec_context (get authdata from - ticket, ie the PAC. Must unwrap the data if in an AD-IFRELEVENT)] -The new function to handle the PAC fully - - gsskrb5_extract_authz_data_from_sec_context() - -Samba still needs this one: - - gsskrb5_wrap_size (find out how big the wrapped packet will be, - given input length). - -Keytab requirements -------------------- - -Because windows machine account handling is very different to the -traditional 'MIT' keytab operation. -This starts when we look at the basics of the secrets handling: - -Samba file-servers can have many server-name simultaneously (kindof -like web servers' software virtual hosting), but since these servers -are running in AD, these names are free to be set up to all share -the same secret key. In AD, host-sharing server names almost always -share a secret key like this. In samba3, this key-sharing was optional, so -some samba3 hosts' keytabs did hold multiple keys. samba4 abandons this -traditional "old MIT" style of keytab, and only supports one key per keytab, -and multiple server-names can use that keytab key in common. -Heimdal offered "in-memory keytabs" for servers that use passwords. -These server-side passwords were held in a Samba LDB database called secrets.ldb, -and the heimdal library would be supplied the password from the ldb file and -would construct an in-memory keytab struct containing the password, -just as if the library had read an MIT-style keytab file. -Unfortunately, only later, at recv_auth() time, would the heimdal library -convert the PW into a salted-&-hashed AES key, by hashing 10,000 times with -SHA-1. So, nowadays, this password-based in-memory keytab is seen as too -slow, and is falling into disuse. - -Traditional 'MIT' behaviour is to use a keytab, containing salted key -data, extracted from the KDC. (In this modal, there is no 'service -password', instead the keys are often simply application of random -bytes). Heimdal also implements this behaviour. - -The windows modal is very different - instead of sharing a keytab with -each member server, a random utf-16 pseudo-textual password is stored -for the whole machine. -The password is set with non-kerberos mechanisms (particularly SAMR, -a DCE-RPC service) and when interacting on a kerberos basis, the -password is salted by the member server (ie, an AD server-host). -(That is, no salt information appears to be conveyed from the AD KDC -to the member server. ie, the member server must use the rule's -described in Luke's mail above). - -pre-win7 AD and samba3/4 both use SAMR, an older protocol, to jumpstart -the member server's PW-sharing with AD (the "windows domain-join process"). -This PW-sharing transfers only the PW's utf-16 text, without any salting -or hashing, so that non-krb security mechanisms can use the same utf-16 -text PW. for windows 7, this domain-joining uses LDAP for PW-setting. - -In dealing with this model, we use both the traditional file -keytab and in-MEMORY keytabs. - -When dealing with a windows KDC, the behaviour regarding case -sensitivity and canonacolisation must be accomidated. This means that -an incoming request to a member server may have a wide variety of -service principal names. These include: - -machine$@REALM (samba clients) -HOST/foo.bar@realm (win2k clients) -HOST/foo@realm (win2k clients, using netbios) -cifs/foo.bar@realm (winxp clients) -cifs/foo@realm (winxp clients, using netbios) - -as well as all case variations on the above. - -Heimdal's GSSAPI expects to get a principal-name & a keytab, possibly containing -multiple principals' different keys. However, AD has a different problem to -solve, which is that the client may know the member-server by a non-canonicalized -principal name, yet AD knows the keytab contains exactly one key, indexed by -the canonical name. So, GSSAPI is unprepared to canonicalize the server-name -that the cliet requested, and is also overprepared to do an unnecessary search -through the keytab by principal-name. So samba's server-side GSSAPI calls game -the GSSAPI, by supplying the server's known canonical name, and the one-key keytab. -this doesn't really affect the port to mit-krb. - -Because the number of U/L case combinations got 'too hard' to put into a keytab in the -traditional way (with the client to specify the name), we either -pre-compute the keys into a traditional keytab or make an in-MEMORY -keytab at run time. In both cases we specifiy the principal name to -GSSAPI, which avoids the need to store duplicate principals. - -We use a 'private' keytab in our private dir, referenced from the -secrets.ldb by default. - -Extra Heimdal functions used ----------------------------- -these fcns didn't exist in the MIT code, years ago, when samba started. -AB will try to build a final list of these fcns. - -(an attempt to list some of the Heimdal-specific functions I know we use) - -krb5_free_keyblock_contents() - -also a raft of prinicpal manipulation functions: - -Prncipal Manipulation ---------------------- - -Samba makes extensive use of the principal manipulation functions in -Heimdal, including the known structure behind krb_principal and -krb5_realm (a char *). for example, -krb5_parse_name_flags(smb_krb5_context->krb5_context, name, - KRB5_PRINCIPAL_PARSE_MUST_REALM, &principal); -krb5_princ_realm(smb_krb5_context->krb5_context, principal); -krb5_unparse_name_flags(smb_krb5_context->krb5_context, principal, - KRB5_PRINCIPAL_UNPARSE_NO_REALM, &new_princ); -These are needed for juggling the AD variant-structures for server names. - -Authz data extraction ---------------------- - -We use krb5_ticket_get_authorization_data_type(), and expect it to -return the correct authz data, even if wrapped in an AD-IFRELEVENT container. - -KDC/hdb Extensions --------------- - -We have modified Heimdal's 'hdb' interface to specify the 'class' of -Principal being requested. This allows us to correctly behave with -the different 'classes' of Principal name. This is necessary because -of the AD structure, which uses very different record-structures -for user-principals, trust principals & server-principals. - -We currently define 3 classes: - - client (kinit) - - server (tgt) - - krbtgt (kinit, tgt) the kdc's own ldap record - -I also now specify the kerberos principal as an explict parameter to LDB_fetch(), -not an in/out value on the struct hdb_entry parameter itself. - -Private Data pointer (and windc hooks) (see above): - In addition, I have added a new interface hdb_fetch_ex(), which - returns a structure including a private data-pointer, which may be used - by the windc plugin inferface functions. The windc plugin provides - the hook for the PAC, as well as a function for the main access control routines. - - A new windc plugin function should be added to increment the bad password counter - on failure. - -libkdc (doesn't matter for IPA; Samba invokes the Heimdal kdc as a library call, -but this is just a convenience, and the MIT port can do otherwise w/o trouble.) ------- - -Samba4 needs to be built as a single binary (design requirement), and -this should include the KDC. Samba also (and perhaps more -importantly) needs to control the configuration environment of the -KDC. - -The interface we have defined for libkdc allow for packet injection -into the post-socket layer, with a defined krb5_context and -kdb5_kdc_configuration structure. These effectively redirect the -kerberos warnings, logging and database calls as we require. - -Using our socket lib (para 3 does matter for the send_to_kdc() plugin). -See also the discussion about state machine safety above) --------------------- - -An important detail in the use of libkdc is that we use samba4's own socket -lib. This allows the KDC code to be as portable as the rest of samba -(this cuts both ways), but far more importantly it ensures a -consistancy in the handling of requests, binding to sockets etc. - -To handle TCP, we use of our socket layer in much the same way as -we deal with TCP for CIFS. Tridge created a generic packet handling -layer for this. - -For the client, samba4 likewise must take over the socket functions, -so that our single thread smbd will not lock up talking to itself. -(We allow processing while waiting for packets in our socket routines). -send_to_kdc() presents to its caller the samba-style socket interface, -but the MIT port will reimplement send_to_kdc(), and this routine will -use internally the same socket library that MIT-krb uses. - -Kerberos logging support (this will require porting attention) ------------------------- - -Samba4 now (optionally in the main code, required for the KDC) uses the -krb5_log_facility from Heimdal. This allows us to redirect the -warnings and status from the KDC (and client/server kerberos code) to -Samba's DEBUG() system. - -Similarly important is the Heimdal-specific krb5_get_error_string() -function, which does a lot to reduce the 'administrator pain' level, -by providing specific, english text-string error messages instead of -just error code translations. (this isn't necessarty for the port, -but it's more useful than MIT's default err-handling; make sure -this works for MIT-krb) - - -Short name rules ----------------- - -Samba is highly likely to be misconfigured, in many weird and -interesting ways. As such, we have a patch for Heimdal that avoids -DNS lookups on names without a . in them. This should avoid some -delay and root server load. (this may need to be ported to MIT.) - -PAC Correctness ---------------- - -We now put the PAC into the TGT, not just the service ticket. - -Forwarded tickets ------------------ - -We extract forwarded tickets from the GSSAPI layer, and put -them into the memory-based credentials cache. -We can then use them for proxy work. - - -Kerberos TODO -============= - -(Feel free to contribute to any of these tasks, or ask -abartlet@samba.org about them). - -Lockout Control (still undone in samba4 on heimdal) --------------- - -We need to get (either if PADL publishes their patch, or write our -own) access control hooks in the Heimdal KDC. We need to lockout -accounts (eg, after 10 failed PW-attemps), and perform other controls. -This is standard AD behavior, that samba4 needs to get right, whether -heimdal or MIT-krb is doing the ticket work. - -Gssmonger ---------- - -Microsoft has released a krb-specific testsuite called gssmonger, -which tests interop. We should compile it against lorikeet-heimdal, -MIT and see if we can build a 'Samba4' server for it. -GSSMonger wasn't intended to be Windows-specific. - -Kpasswd server (kpasswd server is now finished, but not testsuite) --------------- - -I have a partial kpasswd server which needs finishing, and a we need a -client testsuite written, either via the krb5 API or directly against -GENSEC and the ASN.1 routines. -Samba4 likes to test failure-modes, not just successful behavior. - -Currently it only works for Heimdal, not MIT clients. This may be due -to call ordering constraints. - - -Correct TCP support -------------------- - -Samba4 socket-library's current TCP support does not send back 'too large' -error messages if the high bit is set. This is needed for a proposed extension -mechanism (SSL-armored kinit, by Leif Johansson <leifj@it.su.se>), -but is likewise unsupported in both current Heimdal and MIT. - -========================================================================= -AB says MIT's 1.7 announcement about AD support covers Luke Howard's -changes. It all should be easy for IPA to exploit/use during the port -of Samba4 to MIT. -AB says Likewise software will likely give us their freeware NTLM/MIT-krb -implementation. |