Comment 17 for bug 1761737

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Ok

The smb.conf(5) manpage does state that for "security = ads" or "server role = member server" to work, the machine must have been joined to the domain via "net ads join". This is what creates the necessary secrets in the local secrets tdb database.

My hypothesis is that there was a change in 4.7.x and that when the secrets are not found, it crashes. Definitely a bug, but we might be in an unsupported configuration. I have yet to hear from upstream in their bug.

Here is what we could try:

a) Samba as a standalone server, but using kerberos for authentication. The users will exist "locally" via sssd, and samba will be just like any other kerberized service authenticating the users via the kdc. For that it will need an appropriate service key in /etc/krb5.keytab. I think realm (the tool) only extracts host/* keys, not cifs/* keys, and samba might want cifs/* ones.
Note that the realm tool does not change smb.conf as far as I can see, that's why you still had "security = user" or "server role = stanalone server" in your smb.conf before. That might be a hint.

Also, we have to be careful in this configuration to use the same username format. SSSD by default likes "<email address hidden>", and samba might expect just "username", or "username@WORKGROUP". That kind of thing.

b) Samba as a normal member server. For this you would have to use "net ads join". I'm not sure if this would require winbind, probably not.

I can try both scenarios in a clean VM, but I'm a bit out of time and can't commit to it just yet. If we can't address this for the release, then an SRU is in order.

I also just tried 4.7.7 quickly and can still reproduce the crash with the minimal smb.conf I showed in the upstream bug at https://bugzilla.samba.org/show_bug.cgi?id=13376.