samba - Mar 2021 - Failed to prepare gensec: NT_STATUS_INVALID_SERVER_STATE

Run this one : 
https://raw.githubusercontent.com/thctlo/samba4/master/samba-check-set-sysvol.sh

And post the output, looking at our output below, 3000006 and 3000010 should not
be there,  in these outputs.
So run this on both DC's and compair the output files. 
You might have forgotten to sync the idmap.tdb on the DC's. 
See:
https://wiki.samba.org/index.php/Joining_a_Samba_DC_to_an_Existing_Active_Directory
Quote : To use a Sysvol Replication workaround, all domain controllers (DC) must
use the same ID mappings for built-in users and groups.
these should always be the same on all AD-DC's. 
And the 300000 range is correct for the AD-DC's.. 

You might want to read Debian bug , maybe it applies, i dont know, i've not
seen it in my network.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986168

This may be related to Debian bug: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968943

It is almost surely related to Ubuntu bug number # 1900856:
https://bugs.launchpad.net/ubuntu/+source/cifs-utils/+bug/1900856
(last 2 additions are from the bug report #986168)

See if this applied to you, not on the cifs part
but on the kerberos cache part

+ what Rowland said. ;-) good i checked the list before i mailed this. 


Greetz, 

Louis

> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens Stefan Bellon
via
> samba
> Verzonden: woensdag 31 maart 2021 13:03
> Aan: Andrew Bartlett via samba
> CC: Andrew Bartlett
> Onderwerp: Re: [Samba] Failed to prepare gensec:
> NT_STATUS_INVALID_SERVER_STATE
> 
> On Wed, 31 Mar, Andrew Bartlett via samba wrote:
> 
> > On Wed, 2021-03-31 at 09:06 +0200, Stefan Bellon via samba wrote:
> 
> > > I have the feeling this is directly connected to sysvol
> > > permissions.
> >
> > That would be incredibly unlikely.  This is about failing to setup the
> > Kerberos code that accepts incoming tickets, so it could fail if the
> > DC things it is not a DC or can't find the secrets.ldb entry etc.
> 
> I'm fully open to suggestions and ideas on how to debug this further.
> 
> I can only tell you my observation, that after I do a
"sysvolreset" and
> do not touch the sysvol at all, neither from GNU/Linux side nor from
> Windows side, then the log.smbd is completely free of those messages.
> 
> As soon as I edit a group policy on the windows side, the messages
> appear in the log and also sysvolcheck reports issues.
> 
> Are the permissions that I showed in my last email correct? Is it
> expected that on the GNU/Linux side the uid and gid of those folders is
> something in the 3000000 range? Or is it expected that those belong to
> root:root below sysvol?
> 
> Greetings,
> Stefan
> 
> --
> Stefan Bellon
> 
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba

First of all, thanks for your help and suggestions. Very much welcome.

On Wed, 31 Mar, L.P.H. van Belle via samba wrote:
> Run this one : 
>
https://raw.githubusercontent.com/thctlo/samba4/master/samba-check-set-sysvol.sh
> 
> And post the output, looking at our output below, 3000006 and 3000010
> should not be there,  in these outputs. So run this on both DC's and
> compair the output files.
default-rights-sysvol.acl looks identical on both DC1 and DC2:

# file: /var/lib/samba/sysvol
# owner: root
# group: root
user::rwx
user:root:rwx
user:3000000:rwx
user:3000001:r-x
user:3000002:rwx
user:3000003:r-x
group::rwx
group:3000000:rwx
group:3000001:r-x
group:3000002:rwx
group:3000003:r-x
mask::rwx
other::---
default:user::rwx
default:user:root:rwx
default:user:3000000:rwx
default:user:3000001:r-x
default:user:3000002:rwx
default:user:3000003:r-x
default:group::---
default:group:3000000:rwx
default:group:3000001:r-x
default:group:3000002:rwx
default:group:3000003:r-x
default:mask::rwx
default:other::---
> You might have forgotten to sync the idmap.tdb on the DC's. See:
>
https://wiki.samba.org/index.php/Joining_a_Samba_DC_to_an_Existing_Active_Directory
Before I touched anything, I wrote up a guide of how to do the setup
and migration. I played it trough completely in a playground
environment with three VMs "testolddc", "testdc1", and
"testdc2". After
that "succeeded", I did the exact same steps when doing the real
"dc1"
and "dc". My documentation includes the following steps:

- on main DC1:
# rm -f /var/lib/samba/private/idmap.ldb.bak
# tdbbackup -s .bak /var/lib/samba/private/idmap.ldb
# scp /var/lib/samba/private/idmap.ldb.bak DC2

- on new DC2:
# chown root.root /var/lib/samba/private/idmap.ldb.bak
#
  mv /var/lib/samba/private/idmap.ldb.bak /var/lib/samba/private/idmap.ldb

# net cache flush
# samba-tool ntacl sysvolcheck
# samba-tool ntacl sysvolreset
# samba-tool ntacl sysvolcheck

That's what I did.
> Quote : To use a Sysvol Replication workaround, all domain
> controllers (DC) must use the same ID mappings for built-in users and
> groups. these should always be the same on all AD-DC's. And the
> 300000 range is correct for the AD-DC's.. 
I set up DC1 and DC2 from scratch in parallel (i.e. they have the same
packages installed and the same users and groups set up), using the same
Debian Bullseye image and my same step-by-step guide.
> You might want to read Debian bug , maybe it applies, i dont know,
> i've not seen it in my network.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986168
I can confirm that when doing "klist", the ticket cache is in files
named /tmp/krb5cc_%{euid}_%{something} for all users except root, where
the ticket cache is /tmp/krb5cc_0 without the suffix.
> This may be related to Debian bug: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968943
Not sure whether this is my setup ... I do not mount shares on UNIX
side at all, it's just the netlogon/sysvol stuff for Windows.
> It is almost surely related to Ubuntu bug number # 1900856:
> https://bugs.launchpad.net/ubuntu/+source/cifs-utils/+bug/1900856
> (last 2 additions are from the bug report #986168)
> 
> See if this applied to you, not on the cifs part
> but on the kerberos cache part
So, do you suggest I add

[libdefaults]
    default_ccache_name = FILE:/tmp/krb5cc_%{euid}

to /etc/samba/smb.conf?

Would that however explain why sysvolcheck fails as soon as I did some
edit operation on the Windows side?

Greetings,
Stefan

-- 
Stefan Bellon