Some notes on "Implement 'update keytab' for winbind and tools"

[Stefan Metzmacher]

Hi Andrew,

> For some reason this felt better as a mailing list post than just a MR
> update.
> 
> I'm really sorry to give a chunky bit of feedback right as I go on
> leave, I'm sure is quite frustrating and you will probably want some
> clarification.
> 
> Sadly I hadn't been paying attention to
> https://gitlab.com/samba-team/samba/-/merge_requests/1999
> 
> As Christmas is next week, I'll be stepping away from Samba mail and
> GitLab.
> 
> I do trust metze to continue to give you good feedback if you want to
> push this through while I've stepped away - please don't write me down
> as blocking this - but I'm also keen to try and help get a good 'update
> keytab for other things' solution for all of Samba, using our keys or
> gMSA keys.

While this sounds very interesting we still need ways to
export keytabs for our things like sshd, that also needs
the 'host/' service principal.

And at least my main goal with MR 1999 is that
we no longer need to mess with 'kerberos method' and prevent
winbindd from changing the password every week.

Also all the magic that we sometimes implicitly create
a keytab, see
https://gitlab.com/samba-team/samba/-/merge_requests/2190
s3:lib: No implicit keytab update for 'net ads changetrustpw'


The real end goal would be some kind of gensec proxy,
that lets a server or client connect over a unix socket
and the proxy checks which client credentials or service principals
are allowed by the proxy "consumer". Basically it would
pass the whole gss blobs back and forth and on success
only get the result of gss_export_sec_context() + auth_session_info
so basically only key material for the specific session.
The proxy would check if the client provides service principal
really matches what the proxy consumer was allowed to verify.

But that would be a very long way to go.

So I'd say that we go on with MR 1999 and make sure the
documentation clearly describes the risks.

And usage of gMSA's could be added later, I'll make sure
we'll have a useful syntax that will make it explicit
which credentials will be put into the keytab and this
could include gMSA's or single managed accounts in future.

But the basic infrastructure for an admin to control
how keytabs are updated is a clear win over the mess
we currently have. My hope is also to remove quite
some old code...

metze