samba - Jan 2022 - nsupdate failed: GSSAPI error: A token had an invalid message integrity check

On Fri, 2022-01-28 at 15:57 -0600, Michael Jones wrote:
> 
> 
> 
> > 
> > So which was your DC built with, 'Heimdal' or 'MIT' ?
> 
>  
> Those flags are specifically about overriding the krb5 library that
> the samba package carries, to force it to use whatever the system
> happens to have.
> 
> In this case, I specified neither, so it's using whatever 4.15.3
> comes with. Note that I did not package samba myself, I'm just using
> the Gentoo package for it. So if I'm understanding something about
> how Samba is distributed and Samba doesn't come with a pre-specified
> krb5 implementation, then I'm getting whatever the Gentoo packagers
> use. Given the release notes say MIT Krb5 is experimental, I assume
> it's the Heimdal implementation.
You need to find out which you are using, Heimdal or MIT.
> 
> 
> 
> Now that you've pointed out this discrepancy, I'll adjust the
> settings to see if that does any good.
> 
> However, I've been having this problem for several months, and only
> updated to 4.15 last night, whereupon the automatic dependency solver
> decided to replace the system heimdal with mit-krb5, now that samba
> is using it's built in krb5 implementation. (The depsolver solves
> deps and the depsolver wills, i suppose).
Samba has been using the builtin Heimdal since Samba 4 was released,
though there is also an experimental version that uses MIT (this
version should not be used in production).
> 
The TSIG warning line happened before that, when I knew I was
using
> heimdal. So I'm skeptical that I'll see a behavior difference. But
I
> do agree that having only one krb implementation is much less likely
> to have other problems.
 
> >Originally, I had a single shared smb.conf across all of my samba
> machines, with appropriate include = /etc/samba/smb-%L.conf configs
> for each machine.
> >This worked great at first, but has subsequently broken more and
> more
> as I've upgraded samba. The config in the email is the result of
> removing quite a lot of configuration lines that have solved some
> problem or another over the years to try to figure out where things
> are breaking on my DC. 
> 
> I've been subscribed to this mailing list for at least 5 years, and
> quite a lot of the traffic on it ultimately culminates in someone
> telling the person asking for help that their configuration is wrong
> in some way.
We do not write your smb.conf, all we can do is to point out any
errors.
> 
> Perhaps samba needs a config checker that has all these rules built
> in, instead of wasting time on the mailing list? Or even have samba
> reject configuration lines that don't apply to a domain controller,
> if it's so sensitive to these settings?
The problem with that idea, is what may be wrong in one smb.conf, is
perfectly valid in another. To get something to parse the smb.conf
based on what the server role is, would probably have to be extremely
large and entail some form of AI and mind reading capabilities :-)

Rowland

Thank you for the help

On Fri, Jan 28, 2022 at 4:20 PM Rowland Penny via samba <
samba at lists.samba.org> wrote:
> On Fri, 2022-01-28 at 15:57 -0600, Michael Jones wrote:
> You need to find out which you are using, Heimdal or MIT.
>
It's using the version bundled with samba.  I've never attempted to
override that, so it's always been whatever version is bundled with each
samba release, since the DC was first installed. If that's Heimdal, then
it's always been Heimdal.

Samba has been using the builtin Heimdal since Samba 4 was
released,
> though there is also an experimental version that uses MIT (this
> version should not be used in production).

That's fine. I don't have samba configured to use MIT, and never have.

Yet I've had the problem I'm asking for help with both before and after
my
bind-tools package was switched by my package manager from the system's
heimdal to the system's mit-krb5.

Note that bind-tools using the mit-krb5 package *does not* mean that samba
ever has.

Regardless, I do agree with you that using MIT is not the right thing to
do, and am waiting on the DC to install Heimdal as I write this.

However, it doesn't seem like this has anything to do with the problem in
my original email.

We do not write your smb.conf, all we can do is to point out
any
> errors
> The problem with that idea, is what may be wrong in one smb.conf, is
> perfectly valid in another. To get something to parse the smb.conf
> based on what the server role is, would probably have to be extremely
> large and entail some form of AI and mind reading capabilities :-)
>
> Rowland
>
The configuration lines were added when I experienced a problem. The
problem went away when the config lines were added (repeat per config line,
generally speaking).
Either the configuration lines are errors enough that they shouldn't be
allowed in the role that this instance of samba is running as, or they
aren't errors.

Typically I have to find out why something stopped working when I upgrade
samba, and find that the new version either stops doing something I want,
or starts doing something I don't want. The lack of consistency with the
behavior each release is the ultimate driver behind why there are hundreds
of guides telling people to add configuration lines that the mailing list
considers major problems, and why the few people who have run into a
problem they couldn't solve and therefore email the mailing list so
frequently have configurations that you think are set up incorrectly.

Compound that with the Samba software's logs having a predisposition to say
an error occurred, but give no real information about what the error was,
what might have caused it, how to fix it, or really anything. This leads to
people who may not be experts at samba, but are experts at computer admin,
finding their own solutions that only work by accident, further compounding
the problem of bad configuration files. I'm a software engineer for my day
job, so I have my own share of people "holding it wrong", and
sympathize.
It's not an easy problem, but it is one that I've mitigated by having my
log messages lean toward over-explaining, even to the point of
condescension for particularly difficult situations.

Really, what I want is a single git repository that represents the
configuration for all of my samba machines, with common configuration
settings specified in smb.conf, and per machine settings specified in
appropriately named config files, and I had that working for over a year,
and it broke upon upgrade to some samba version, i don't recall which. So
this DC has config lines left over from when it shared the same git
repository as all my member machines. If it hasn't caused a problem until
now, i've generally left it alone.

Regardless, I appreciate your feedback on my configuration, and I'll take
it under advisement. Thank you.

However, I don't believe that the settings you omitted from my smb.conf are
related to nsupdate encountering the error: "GSSAPI error: A token had an
invalid message integrity check", are they? Or is there some influence
between, e.g. "winbind ..." settings and the DNS updater mechanism
that I'm
not understanding?