Stefan Bellon
2021-Mar-30 12:43 UTC
[Samba] Failed to prepare gensec: NT_STATUS_INVALID_SERVER_STATE
Hi all, I have set up two Samba 4.13.5 AD DC on Debian Bullseye recently and the logfile log.smbd is full of [2021/03/30 11:19:46.883518, 0] ../../source3/rpc_server/rpc_server.c:1086(dcesrv_auth_gensec_prepare) dcesrv_auth_gensec_prepare: Failed to prepare gensec: NT_STATUS_INVALID_SERVER_STATE I have not yet traced it down to the root cause, that's why I am here to ask for help. I have seen the message appear in the log file for unsuccessful login attempts as well as successful login attempts to a domain computer, but I've also seen the message appear when working in the GPMC. Background story follows: I was handed over a Samba 4.2.14 AD DC instance on an old Debian 8.11 (Jessie) VM which was running with a Samba process uptime for 3 years and where the Samba daemon did not survive a restart any more (VM snapshot restore to the rescue!). I figured it would be a good idea to move the domain to two newly set up Samba AD DC instances (with redundancy) and retire the old 4.2.14 instance completely. After reading through almost all of the pages at https://wiki.samba.org/index.php I set up the two new Samba 4.13.5 AD DC instances on Debian Bullseye, configured BIND9 9.16 accordingly (with DLZ and mirroring the other zones), moved DHCP and NTP to those machines as well and finally joined the domain and even made the first of the new DCs (DC1) the PDC. Additionally I set up Sysvol replication between the new DCs using unison (the old one will be retired anyway and PDC is one of the new ones). So far, I think, everything looks fine and "works". The old Samba 4.2.14 is still in the domain until I have confidence that I can safely remove it. And here those log messages come into play: I have the feeling that something is not quite right if I continuously get [2021/03/30 11:19:46.883518, 0] ../../source3/rpc_server/rpc_server.c:1086(dcesrv_auth_gensec_prepare) dcesrv_auth_gensec_prepare: Failed to prepare gensec: NT_STATUS_INVALID_SERVER_STATE messages in the log. Can you give me any hints of how to debug this any further and find out what's the root cause? I'm happy to supply configuration snippets and log files if the necessity arises. TIA. Greetings, Stefan -- Dipl.-Inf. Stefan Bellon Axivion GmbH Nobelstr. 15 70569 Stuttgart Germany Tel: +49 711 6204378-11 Fax: +49 711 6204378-99 https://www.axivion.com/ Geschaeftsfuehrung / Managing Directors: Stefan Bellon, Thomas Eisenbarth, Sebastian Rummler Sitz der Gesellschaft / Registered Office: Stuttgart Registergericht / Registration Court: Amtsgericht Stuttgart, HRB 720590 Pflichtangaben nach Art. 13 DSGVO / Mandatory information according to Art. 13 GDPR: https://www.axivion.com/pflichtangaben Unser Qualitaetsmanagementsystem ist zertifiziert nach ISO 9001 Our quality management system is certified according to ISO 9001 Treffen Sie uns! / Meet us! ICSA - International Conference on Software Architecture digital, 22.-26.03.2021 VECS - Vehicle Electronics and Connected Services, Gothenburg/Sweden, 19.-20.05.2021
Stefan Bellon
2021-Mar-31 07:06 UTC
[Samba] Failed to prepare gensec: NT_STATUS_INVALID_SERVER_STATE
On Tue, 30 Mar, Stefan Bellon via samba wrote:> [2021/03/30 11:19:46.883518, > 0] ../../source3/rpc_server/rpc_server.c:1086(dcesrv_auth_gensec_prepare) > dcesrv_auth_gensec_prepare: Failed to prepare gensec: > NT_STATUS_INVALID_SERVER_STATEI have the feeling this is directly connected to sysvol permissions. I observed that when I edit stuff in GPMC and get those messages in the log, then afterwards a sysvolcheck will fail and the messages keep coming even on successful domain user login. If I resetsysvol and do not touch GPMC afterwards, then the log messages do not appear (till the next action that most likely messes with the sysvol permissions). As the sysvol is the part that was not set up afresh on the new DCs but copied over from the old Samba, I wonder whether this is broken: root at dc1:~# cd /var/lib/samba/ root at dc1:~# ls -ald sysvol/ drwxrwx---+ 3 root 3000000 4096 Mar 30 23:22 sysvol/ root at dc1:~# ls -ald sysvol/xxx/Policies/\{31B2F340-016D-11D2-945F-00C04FB984F9\}/ drwxrwx---+ 4 3000008 3000008 4096 Mar 30 13:03 sysvol/xxx/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/ root at dc1:~# getfacl sysvol/ # file: sysvol # owner: root # group: 3000000 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::--- root at dc1:~# getfacl sysvol/xxx/Policies/\{31B2F340-016D-11D2-945F-00C04FB984F9\}/ # file: sysvol/xxx/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/ # owner: 3000008 # group: 3000008 user::rwx user:3000002:rwx user:3000003:r-x user:3000006:rwx user:3000010:r-x group::rwx group:3000002:rwx group:3000003:r-x group:3000006:rwx group:3000008:rwx group:3000010:r-x mask::rwx other::--- default:user::rwx default:user:3000002:rwx default:user:3000003:r-x default:user:3000006:rwx default:user:3000008:rwx default:user:3000010:r-x default:group::--- default:group:3000002:rwx default:group:3000003:r-x default:group:3000006:rwx default:group:3000008:rwx default:group:3000010:r-x default:mask::rwx default:other::--- First of all, I'm unsure of whether it's correct that the UNIX uid/gid (root:3000000 and 3000008:3000008) are set on the folders or whether they should just belong to root:root? And secondly, I'm wondering whether the acl premissions are correct either. The UIDs resolve as follows: root at dc1:~# wbinfo --sid-to-name=$(wbinfo --uid-to-sid=3000000) BUILTIN\Administrators 4 root at dc1:~# wbinfo --sid-to-name=$(wbinfo --uid-to-sid=3000001) BUILTIN\Server Operators 4 root at dc1:~# wbinfo --sid-to-name=$(wbinfo --uid-to-sid=3000002) NT AUTHORITY\SYSTEM 5 root at dc1:~# wbinfo --sid-to-name=$(wbinfo --uid-to-sid=3000003) NT AUTHORITY\Authenticated Users 5 root at dc1:~# wbinfo --sid-to-name=$(wbinfo --uid-to-sid=3000004) DS\Group Policy Creator Owners 2 root at dc1:~# wbinfo --sid-to-name=$(wbinfo --uid-to-sid=3000006) DS\Enterprise Admins 2 root at dc1:~# wbinfo --sid-to-name=$(wbinfo --uid-to-sid=3000008) DS\Domain Admins 2 root at dc1:~# wbinfo --sid-to-name=$(wbinfo --uid-to-sid=3000010) NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS 5 Any help would be very welcomed. Greetings, Stefan -- Stefan Bellon