MIT Krb5 KDC in the AD DC

[Andrew Bartlett]

On Wed, 2014-07-16 at 18:16 +0200, Guenther Deschner wrote:
> Hi,
> 
> On 01/07/14 00:06, Andrew Bartlett wrote:
> > On Mon, 2014-06-30 at 18:38 +0200, Andreas Schneider wrote:
> >> On Thursday 19 June 2014 15:03:24 Andrew Bartlett wrote:
> >>> G'Day Andreas,
> >> 
> >> Hi Andrew,
> >> 
> >>> I'm just wanting to touch base with you as to how we can 
> >>> progress your MIT KDC efforts?
> >> 
> >> there were no efforts during my vacation. Günther just rebased 
> >> the code. We will be back working on this and proposing patches 
> >> by the end of this week hopefully.
> >> 
> >> We will try to write together what to look at and where we see 
> >> that we need improvements.
> >> 
> >> We know that what we have isn't perfect and some things are ugly 
> >> but we know were we need to rewrite code again to make it 
> >> cleaner.
> >> 
> >> 
> >> So we will try to bring it in a state it is easy you know what
> >> to review and then have an explanation of the code we think is
> >> not ready yet.
> >> 
> >> Maybe we can have a chat next week then.
> > 
> > I look forward to it.  I didn't want you feeling that I was 
> > indifferent to your efforts here, because on the contrary I see 
> > great benefits from opening Samba's AD DC capability up to 
> > platforms that can't use our embedded Heimdal, and getting out of 
> > the Kerberos-library business in the long term.
> 
> The current work branch has a bit more then 130 patches right now, so
> we would really like to start bringing pieces of it upstream now.
> 
> So what we did today was to move out all the krb5 wrapping calls out
> of the main branch to a separate branch. Getting this first series of
> patches upstream would make it much easier to step forward on this matter.
> 
> This new branch now contains most of the prerequisite work to make all
> of samba's DC code to compile with both a MIT or a Heimdal kerberos
> library in one of the next steps (in particular the krb5 client code
> which currently is not compiled at all when using a system MIT
> kerberos library).
> 
> Some of the commits might read a bit abstract and unrelated when seen
> isolated in the new branch. In that case one can always check the
> larger wip branch where - when seen in context - the order of commits
> explains much better why this and that is needed.
> 
> Again: the main wip branch is still this:
> 
> https://git.samba.org/?p=gd/samba/.git;a=shortlog;h=refs/heads/master-mit-kdc
> 
> while we ask for review of this branch for now:
> 
> https://git.samba.org/?p=gd/samba/.git;a=shortlog;h=refs/heads/master-mit-kdc-ok
> 
> Andrew, can you start reviewing this ?

Can we try and avoid adding back all this glue by taking an alternative
approach on the kpasswd server?  It is the only user of the gensec_krb5
code, which is essentially still the old, horrid, kerberos acceptor from
the 3.0 days.

Do we know if the MIT krb5 code already verifies the PAC at acceptance
time, for example (Heimdal does).  This would allow us to just trust the
PAC.

Or, could we wrap up the incoming packet 'just enough' to make it look
like GSSAPI, extract the PAC that way, and then do a reply attack on
ourselves for the password/operation decrypt step?

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140801/8d5a85e4/attachment.pgp>