[bionic] samba PANIC, INTERNAL ERROR: Signal 11
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| samba |
Unknown
|
Unknown
|
||
| samba (Ubuntu) |
Undecided
|
Andreas Hasenack |
Bug Description
Our Ubuntu clients are in an AD domain using realm. Accessing a samba share (SSO) with dolphin/nautilus (smb://HOST/share) is working on ubuntu clients where the host with the shared directory is ubuntu 16.04 or 17.10.
Accessing the shared folder on ubuntu 18.04 with same configuration as 16.04 or 17.10 clients throws a panic on the system with 18.04:
/var/log/
=======
[2018/04/06 13:43:50.360655, 5] ../source3/
init msg_type=0x81 msg_flags=0x0
[2018/04/06 13:43:50.361179, 3] ../source3/
Transaction 0 of length 194 (0 toread)
[2018/04/06 13:43:50.361241, 5] ../source3/
[2018/04/06 13:43:50.361264, 5] ../source3/
size=190
smb_com=0x72
smb_rcls=0
smb_reh=0
smb_err=0
smb_flg=24
smb_flg2=51267
smb_tid=0
smb_pid=65534
smb_uid=0
smb_mid=0
smt_wct=0
smb_bcc=155
[2018/04/06 13:43:50.361467, 3] ../source3/
switch message SMBnegprot (pid 2538) conn 0x0
[2018/04/06 13:43:50.361554, 4] ../source3/
setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0
[2018/04/06 13:43:50.361617, 5] ../libcli/
Security token: (NULL)
[2018/04/06 13:43:50.361667, 5] ../source3/
UNIX token of user 0
Primary group is 0 and contains 0 supplementary groups
[2018/04/06 13:43:50.361766, 5] ../source3/
change_
[2018/04/06 13:43:50.363559, 3] ../source3/
Requested protocol [PC NETWORK PROGRAM 1.0]
[2018/04/06 13:43:50.363638, 3] ../source3/
Requested protocol [MICROSOFT NETWORKS 1.03]
[2018/04/06 13:43:50.363677, 3] ../source3/
Requested protocol [MICROSOFT NETWORKS 3.0]
[2018/04/06 13:43:50.363712, 3] ../source3/
Requested protocol [LANMAN1.0]
[2018/04/06 13:43:50.363747, 3] ../source3/
Requested protocol [LM1.2X002]
[2018/04/06 13:43:50.363782, 3] ../source3/
Requested protocol [DOS LANMAN2.1]
[2018/04/06 13:43:50.363817, 3] ../source3/
Requested protocol [LANMAN2.1]
[2018/04/06 13:43:50.363852, 3] ../source3/
Requested protocol [Samba]
[2018/04/06 13:43:50.363888, 3] ../source3/
Requested protocol [NT LANMAN 1.0]
[2018/04/06 13:43:50.363924, 3] ../source3/
Requested protocol [NT LM 0.12]
[2018/04/06 13:43:50.364019, 5] ../lib/
check lock order 2 for /var/run/
[2018/04/06 13:43:50.364077, 5] ../lib/
release lock order 2 for /var/run/
[2018/04/06 13:43:50.364259, 5] ../source3/
Making default auth method list for server role = 'standalone server', encrypt passwords = yes
[2018/04/06 13:43:50.364282, 5] ../source3/
Attempting to register auth backend trustdomain
[2018/04/06 13:43:50.364300, 5] ../source3/
Successfully added auth method 'trustdomain'
[2018/04/06 13:43:50.364316, 5] ../source3/
Attempting to register auth backend ntdomain
[2018/04/06 13:43:50.364334, 5] ../source3/
Successfully added auth method 'ntdomain'
[2018/04/06 13:43:50.364352, 5] ../source3/
Attempting to register auth backend guest
[2018/04/06 13:43:50.364364, 5] ../source3/
Successfully added auth method 'guest'
[2018/04/06 13:43:50.364392, 5] ../source3/
Attempting to register auth backend sam
[2018/04/06 13:43:50.364404, 5] ../source3/
Successfully added auth method 'sam'
[2018/04/06 13:43:50.364415, 5] ../source3/
Attempting to register auth backend sam_ignoredomain
[2018/04/06 13:43:50.364427, 5] ../source3/
Successfully added auth method 'sam_ignoredomain'
[2018/04/06 13:43:50.364438, 5] ../source3/
Attempting to register auth backend sam_netlogon3
[2018/04/06 13:43:50.364450, 5] ../source3/
Successfully added auth method 'sam_netlogon3'
[2018/04/06 13:43:50.364461, 5] ../source3/
Attempting to register auth backend winbind
[2018/04/06 13:43:50.364473, 5] ../source3/
Successfully added auth method 'winbind'
[2018/04/06 13:43:50.364484, 5] ../source3/
Attempting to register auth backend unix
[2018/04/06 13:43:50.364502, 5] ../source3/
Successfully added auth method 'unix'
[2018/04/06 13:43:50.364514, 5] ../source3/
load_auth_module: Attempting to find an auth method to match guest
[2018/04/06 13:43:50.364527, 5] ../source3/
load_auth_module: auth method guest has a valid init
[2018/04/06 13:43:50.364539, 5] ../source3/
load_auth_module: Attempting to find an auth method to match sam_ignoredomain
[2018/04/06 13:43:50.364551, 5] ../source3/
load_auth_module: auth method sam_ignoredomain has a valid init
[2018/04/06 13:43:50.365880, 3] ../auth/
GENSEC backend 'gssapi_spnego' registered
[2018/04/06 13:43:50.365916, 3] ../auth/
GENSEC backend 'gssapi_krb5' registered
[2018/04/06 13:43:50.365930, 3] ../auth/
GENSEC backend 'gssapi_krb5_sasl' registered
[2018/04/06 13:43:50.365942, 3] ../auth/
GENSEC backend 'spnego' registered
[2018/04/06 13:43:50.365954, 3] ../auth/
GENSEC backend 'schannel' registered
[2018/04/06 13:43:50.365967, 3] ../auth/
GENSEC backend 'naclrpc_as_system' registered
[2018/04/06 13:43:50.365979, 3] ../auth/
GENSEC backend 'sasl-EXTERNAL' registered
[2018/04/06 13:43:50.365992, 3] ../auth/
GENSEC backend 'ntlmssp' registered
[2018/04/06 13:43:50.366004, 3] ../auth/
GENSEC backend 'ntlmssp_
[2018/04/06 13:43:50.366017, 3] ../auth/
GENSEC backend 'http_basic' registered
[2018/04/06 13:43:50.366029, 3] ../auth/
GENSEC backend 'http_ntlm' registered
[2018/04/06 13:43:50.366042, 3] ../auth/
GENSEC backend 'krb5' registered
[2018/04/06 13:43:50.366055, 3] ../auth/
GENSEC backend 'fake_gssapi_krb5' registered
[2018/04/06 13:43:50.366109, 5] ../auth/
Starting GENSEC mechanism spnego
[2018/04/06 13:43:50.366144, 5] ../auth/
Starting GENSEC submechanism gse_krb5
[2018/04/06 13:43:50.366323, 0] ../lib/
=====
[2018/04/06 13:43:50.366346, 0] ../lib/
INTERNAL ERROR: Signal 11 in pid 2538 (4.7.6-Ubuntu)
Please read the Trouble-Shooting section of the Samba HOWTO
[2018/04/06 13:43:50.366368, 0] ../lib/
=====
[2018/04/06 13:43:50.366387, 0] ../source3/
PANIC (pid 2538): internal error
[2018/04/06 13:43:50.366896, 0] ../source3/
BACKTRACE: 33 stack frames:
#0 /usr/lib/
#1 /usr/lib/
#2 /usr/lib/
#3 /usr/lib/
#4 /lib/x86_
#5 /usr/lib/
#6 /usr/lib/
#7 /usr/lib/
#8 /usr/lib/
#9 /usr/lib/
#10 /usr/lib/
#11 /usr/lib/
#12 /usr/lib/
#13 /usr/lib/
#14 /usr/lib/
#15 /usr/lib/
#16 /usr/lib/
#17 /usr/lib/
#18 /usr/lib/
#19 /usr/lib/
#20 /usr/lib/
#21 /usr/lib/
#22 /usr/lib/
#23 /usr/lib/
#24 /usr/sbin/
#25 /usr/lib/
#26 /usr/lib/
#27 /usr/lib/
#28 /usr/lib/
#29 /usr/lib/
#30 /usr/sbin/
#31 /lib/x86_
#32 /usr/sbin/
[2018/04/06 13:43:50.367078, 0] ../source3/
smb_panic(): calling panic action [/usr/share/
30 ../sysdeps/
mail: cannot send message: Process exited with a non-zero status
[2018/04/06 13:43:51.587520, 0] ../source3/
smb_panic(): action returned status 36
[2018/04/06 13:43:51.587618, 0] ../source3/
coredump is handled by helper binary specified at /proc/sys/
client
======
HOST: Ubuntu 18.04RC (2018-04-06), amd64
samba: 4.7.6+dfsg~
krb5: 1.16-2build1
sssd: 1.16.0-5ubuntu2
This is a blocker for us to upgrade from 16.04 to 18.04 after release. :-(
Related branches
- Christian Ehrhardt : Approve on 2018-08-22
- Canonical Server Team: Pending requested 2018-06-22
-
Diff: 1601 lines (+1289/-21)8 files modifieddebian/changelog (+1089/-0)
debian/control (+4/-4)
debian/patches/VERSION.patch (+2/-2)
debian/rules (+4/-2)
debian/samba-common-bin.install (+1/-0)
debian/samba-common.config (+4/-4)
debian/smb.conf (+15/-9)
debian/source_samba.py (+170/-0)
- Christian Ehrhardt : Approve on 2018-04-24
- Canonical Server Core Reviewers: Pending requested 2018-04-19
-
Diff: 67 lines (+45/-0)3 files modifieddebian/changelog (+8/-0)
debian/patches/passdb_dont_return_ok_if_pinfo_not_filled.patch (+36/-0)
debian/patches/series (+1/-0)
Andreas Hasenack (ahasenack) wrote : | #1 |
Changed in samba (Ubuntu): | |
status: | New → Incomplete |
tags: | added: bionic |
summary: |
- samba PANIC, INTERNAL ERROR: Signal 11 + [bionic] samba PANIC, INTERNAL ERROR: Signal 11 |
Alexander Fieroch (fieroch) wrote : | #2 |
crash file on 18.04 when accessing smb share with 17.10
Alexander Fieroch (fieroch) wrote : | #3 |
smb.conf (Ubuntu 17.10) where smb share is working and not crashing smbd if another client accesses this share.
That 17.10 client for example accesses 18.04 where smbd crashes afterwards.
Alexander Fieroch (fieroch) wrote : | #4 |
smb.conf (18.04) where smbd crashes after a client accesses its share
all our clients should have equal or similar smbd settings
Alexander Fieroch (fieroch) wrote : | #5 |
Trying to access a share on 18.04 with smbclient from 17.10 lets smbd crash too.
The other way round is working - Accessing a share on 17.10 with 18.04 and smbclient shows me the shared folder content.
Andreas Hasenack (ahasenack) wrote : | #6 |
The smb.conf file for the 18.04 box shows it as being a standalone server, not a domain member. Is that expected? Are you managing its users locally via smbpasswd?
Andreas Hasenack (ahasenack) wrote : | #7 |
Was this 18.04 box a fresh install of samba 4.7.6, or did you at some point have 4.7.4 or earlier and upgrade?
Andreas Hasenack (ahasenack) wrote : | #8 |
Ok, I can reproduce this with a simple "smbclient -L localhost -N" and this smb.conf:
[global]
dns proxy = No
domain master = No
kerberos method = secrets and keytab
local master = No
log file = /var/log/
map to guest = Bad User
max log size = 1000
obey pam restrictions = Yes
pam password change = Yes
panic action = /usr/share/
passwd chat = *Enter\
passwd program = /usr/bin/passwd %u
security = USER
server role = standalone server
server string = %h %a
syslog = 0
unix password sync = Yes
usershare allow guests = Yes
idmap config * : backend = tdb
The moment I remove your "kerberos method" option (i.e., comment it), the crash no longer happens.
Andreas Hasenack (ahasenack) wrote : | #9 |
Can you elaborate on how this 18.04 machine is supposed to authenticate users and give them access or not to a share, since it's not part of the AD realm, at least according to smb.conf? In the meantime I'll check with upstream.
Changed in samba (Ubuntu): | |
status: | Incomplete → Triaged |
status: | Triaged → Confirmed |
Alexander Fieroch (fieroch) wrote : | #10 |
> The smb.conf file for the 18.04 box shows it as being a standalone server, not a domain member. Is that expected? Are you managing its users locally via smbpasswd?
After uploading I noticed that too. No it is not intended. I changed it to
security = ADS
again and added same settings as in 17.10. Unfortunately smbd is still crashing after accessing the share on 18.04.
> Was this 18.04 box a fresh install of samba 4.7.6, or did you at some point have 4.7.4 or earlier and upgrade?
I upgraded from 16.04 to the development release of 18.04 earlier this year. It is very possible that I had samba 4.7.4 at some point earlier this year.
I have another system with a fresh install of 18.04. smbd also crashes there.
> The moment I remove your "kerberos method" option (i.e., comment it), the crash no longer happens.
Hm, it still keeps crashing for me.
Now I changed smb.conf on 18.04 to this still crashing configuration:
[global]
dns proxy = No
domain master = No
kerberos method = secrets and keytab
local master = No
log file = /var/log/
map to guest = Bad User
max log size = 1000
obey pam restrictions = Yes
pam password change = Yes
panic action = /usr/share/
passwd chat = *Enter\
passwd program = /usr/bin/passwd %u
realm = MPI-DORTMUND.MPG.DE
security = ADS
server role = member server
server string = %h %a
syslog = 0
unix password sync = Yes
usershare allow guests = Yes
workgroup = MPI-DORTMUND
idmap config * : backend = tdb
> Can you elaborate on how this 18.04 machine is supposed to authenticate users and give them access or not to a share, since it's not part of the AD realm, at least according to smb.conf?
The 18.04 machine should prefer kerberos for authenticating users. Local authentication using sssd for AD is working fine. Kerberos authentication is working fine too.
There is a shared directory users should have access. It is working the other way round - on 17.10 with same settings:
[share]
create mask = 0640
directory mask = 0750
force group = "Domain Users"
invalid users = root
path = /mnt/share
read only = No
valid users = +ntwsadmins "+Domain Users"
Andreas Hasenack (ahasenack) wrote : | #11 |
After changing security to ADS, did you join the realm/domain again? You might have some incorrect local databases. Can you start fresh with 4.7.6 on this box?
Also, even on a fresh 4.7.6, I couldn't get "kerberos method = secrets and keytab" to work without crashing, that's the samba bug I filed upstream. I think there is something wrong when it attempts "secrets". I was able to setup a standalone samba server and authenticate to it using plain kerberos (smbclient -k) just fine, but I had to set the dedicated keytab option to /etc/krb5.keytab (which is the system keytab file anyway).
Do you really need to specify "kerberos method"? The default value (not specify it) doesn't work for you case?
The bug in 4.7.4 is only when samba seems to only affect samba when used as a directory controller itself:
o BUG 13228: This is a major issue in Samba's ActiveDirectory domain
controller code. It might happen that AD objects have missing or broken
linked attributes. This could lead to broken group memberships e.g.
All Samba AD domain controllers set up with Samba 4.6 or lower and then
upgraded to 4.7 are affected. The corrupt database can be fixed with
'samba-tool dbcheck --cross-ncs --fix'.
Alexander Fieroch (fieroch) wrote : | #12 |
Do I really have to rejoin the client to AD after changing samba security to ADS? I'm not using samba "net join" and no winbind for AD binding. I've created the AD machine account with realm and I'm using sssd for authentication to AD DC.
BTW "realm" changed my "security = ADS" in smb.conf to "security = user"....
However, I could reproduce the smb crash anytime when
security = ADS
is set. It doesn't matter if I specify "kerberos method" or not.
When set to
security = user
and disabled
# kerberos method = secrets and keytab
smb is not crashing anymore but I also cannot authenticate with my AD user account (using sssd).
Enabling
kerberos method = secrets and keytab
and
security = user
let's smb crash too.
Andreas Hasenack (ahasenack) wrote : | #13 |
Ok, so to summarize:
- sssd is providing user and groups from AD (via /etc/nsswitch.conf)
- realmd was used to join the machine to AD for the above
- local user authentication is done via pam_sss and using kerberos. Shell users get a ticket upon login
- samba is not using winbind
I have a feeling samba is missing it's account with the AD server. I don't know if the sssd join works for samba's "security = ADS", I have never tested that. I always used net ads join. Is this how you configured the non-18.04 samba member servers? With just sssd, no "net ads join"?
The crash also seems to indicate that the "secrets" bit of "secrets and keytab" is returning a null pointer to the code, so maybe samba isn't finding the secret.
Do you have a populated /etc/krb5.keytab?
Can you try these commands:
net ads testjoin -k
net ads status -k
After having acquired a kerberos ticket most likely (for -k to work).
Alexander Fieroch (fieroch) wrote : | #14 |
> Ok, so to summarize:
> - sssd is providing user and groups from AD (via /etc/nsswitch.conf)
> - realmd was used to join the machine to AD for the above
> - local user authentication is done via pam_sss and using kerberos. Shell users get a ticket upon login
> - samba is not using winbind
that's right
> I have a feeling samba is missing it's account with the AD server.
The machine account on the AD server does exist.
> I don't know if the sssd join works for samba's "security = ADS", I have never tested that.
Up to 17.10 it is working using realm to join the client to the AD and smb is working too.
> I always used net ads join. Is this how you configured the non-18.04 samba member servers? With just sssd, no "net ads join"?
Yes, all our clients and servers are not joined to AD by "net ads join". These are all joined by realm and use sssd.
> The crash also seems to indicate that the "secrets" bit of "secrets and keytab" is returning a null pointer to the code, so maybe samba isn't finding the secret.
> Do you have a populated /etc/krb5.keytab?
local /etc/krb5.keytab is generated by realm when AD machine account is created on the server.
> Can you try these commands:
> net ads testjoin -k
Join to domain is not valid: NT code 0xfffffff6
I also get this message on 17.10, where smb is not crashing.
> net ads status -k
objectClass: top
objectClass: person
objectClass: organizationalP
objectClass: user
objectClass: computer
cn: m15015-vm-lin3
distinguishedName: CN=m15015-
instanceType: 4
whenCreated: 20180412075138.0Z
whenChanged: 20180413071746.0Z
uSNCreated: 99733897
uSNChanged: 99802204
name: m15015-vm-lin3
objectGUID: cc30fbce-
userAccountControl: 69632
codePage: 0
countryCode: 0
lastLogon: 131680786856152060
localPolicyFlags: 0
pwdLastSet: 131679930989191696
primaryGroupID: 515
objectSid: S-1-5-21-
accountExpires: 9223372036854775807
logonCount: 148
sAMAccountName: m15015-vm-lin3$
sAMAccountType: 805306369
operatingSystem: Ubuntu
operatingSystem
dNSHostName: m15015-vm-lin3
userPrincipalName: <email address hidden>
servicePrincipa
servicePrincipa
objectCategory: CN=Computer,
isCriticalSyste
dSCorePropagati
lastLogonTimestamp: 131679931011068668
msDS-SupportedE
Andreas Hasenack (ahasenack) wrote : | #15 |
What happens in terms of accessing the share in the 18.04 server when you use these settings:
a)
kerberos method = system keytab
b)
kerberos method = dedicated keytab
dedicated keytab file = /etc/krb5.keytab
c) kerberos method = default
Alexander Fieroch (fieroch) wrote : | #16 |
a)
security = ADS
kerberos method = system keytab
no smb crash, but I cannot authenticate with AD users:
SPNEGO login failed: NT_STATUS_
b)
security = ADS
kerberos method = dedicated keytab
dedicated keytab file = /etc/krb5.keytab
same as in a)
c)
security = ADS
kerberos method = default
smb crashes on access
Andreas Hasenack (ahasenack) wrote : | #17 |
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@
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:/
Alexander Fieroch (fieroch) wrote : | #18 |
> 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.
yes, the krb5.keytab created by realm does not contain cifs/* and contains
# klist -e -k /etc/krb5.keytab
Keytab name: FILE:/etc/
KVNO Principal
---- -------
2 m15015-
2 m15015-
2 m15015-
2 m15015-
2 m15015-
2 m15015-
2 <email address hidden> (aes256-
2 <email address hidden> (aes128-
2 <email address hidden> (des3-cbc-sha1)
2 <email address hidden> (arcfour-hmac)
2 <email address hidden> (des-cbc-md5)
2 <email address hidden> (des-cbc-crc)
2 <email address hidden> (aes256-
2 <email address hidden> (aes128-
2 <email address hidden> (des3-cbc-sha1)
2 <email address hidden> (arcfour-hmac)
2 <email address hidden> (des-cbc-md5)
2 <email address hidden> (des-cbc-crc)
But in previous samba version there was no cifs/* in keytab and smb didn't crash on access. So is it really necessary?
> 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.
Hm, I'm sure it did change the smb.conf previously (maybe this changed recently?). That's why I had "security = user" instead of "security = ADS" in my smb.conf. But now I cannot see any changes in smb.conf too after joining to AD with realm.
So you mean in a) I should try his, right?
security = auto
server role = standalone server
kerberos method = secrets and keytab
smbd crashes here.
What is the best way to add the correct cifs/* in /etc/krb5.keytab?
> SSSD by default likes "<email address hidden>", and samba might expect just "username", or "username@
Ok, what is the recommended configuration in sssd.conf and smb.conf?
> b)
So you mean in b) I should try his, right?
security = auto
kerberos method = secrets and keytab
server role = member server
afterwards "net ads join" gives me:
# net ads join -U ntfieroch
Enter ntfieroch's password:
Using short domain name -- MPI-DORTMUND
Joined 'M15015-VM-LIN3' to dns domain 'mpi-dortmund.
DNS Update for m15015-
Andreas Hasenack (ahasenack) wrote : | #19 |
(sorry if I'm telling you something you already know: the text below is also for my own benefit and thought process)
Joining a domain means basically creating a computer account in the AD. That is what allows the computer to query the domain for information like usernames, uid numbers, and even authenticate users.
sssd can do that, for its own benefit. It installs a pam module, a nss module, configures files accordingly, and you get a machine where users can login to the linux system and be treated almost like local users, as if they were in /etc/{passwd,
Samba can also join a domain, of course, and it stores the credentials for that locally somewhere. I believe that's ultimately what the "kerberos method" setting controls: if it's in the secrets.tdb database, or in a normal kerberos keytab. I believe when you use "net ads join", it uses secrets.tdb. You can check the /etc/krb5.keytab to see if it changed after you ran "net ads join".
Now, the question is how to take advantage of the already running sssd (for your linux users to login on the box via ssh, login, gdm, etc) for samba. As we know, for samba to authenticate and recognize a windows user, that user also needs to appear as a linux user, as if it existed in /etc/passwd. That's one of the functions of winbind, or nss_ldap, or even sssd. But samba also needs to contact the kerberos server (AD in this case) to authenticate the user and obtain a TGT, and for that it needs to have its own account. An account that sssd created, not "net ads join" in your case. Samba should be able to use the system keytab (that's /etc/krb5.keytab), where apparently sssd did all the work for us, but we are seeing segfaults in our way when messing with that parameter.
In the release notes for samba 4.8.0, for example, they state that having winbind is required for domain membership, because the rpc calls were delegated to it (https:/
You have evidence that in previous ubuntu releases it is possible: using only sssd, and having samba authenticate domain users. I don't know if by design, or by accident. Or maybe you are using just a subset of all the possible rpc calls and it works.
I have documentation that says "net ads join" is necessary for this to work (it's in the smb.conf manpage). It doesn't elaborate if winbind is needed, though. Above when you said "it works" after trying "net ads join", did you mean just the join, or that samba started to authenticate domain users normally?
Bottom line is, I don't know if you can use sssd for samba, or if you need both sssd and winbind. I would have to experiment with it. The segfault is a bug, and shouldn't happen even with invalid configurations, so that has to be fixed. But it might be unrelated to the big question.
What I suggest:
- try the net ads join way. It's what the samba documentation recommends
- check if "net ads join" creates another entry in the keytab file
- subscribe to https:/
Stefan Metzmacher (metze) wrote : | #20 |
This is https:/
Does changing 'secrets and keytab' to 'keytab' help?
Stefan Metzmacher (metze) wrote : | #21 |
I just noticed https:/
https:/
Andreas Hasenack (ahasenack) wrote : | #22 |
The "kerberos method" options that were tried are in https:/
Stefan Metzmacher (metze) wrote : | #23 |
Can someone try what happens with
https:/
together with "kerberos method = secrets and keytab"?
I'd guess it should behave like "system keytab" or "dedicated keytab",
but it would be good to have this verified.
Andreas Hasenack (ahasenack) wrote : | #24 |
I have it building in a ppa and will try shortly
Andreas Hasenack (ahasenack) wrote : | #25 |
Packages from https:/
Andreas Hasenack (ahasenack) wrote : | #26 |
After a lot of experimentation, I got my samba server, with "security = ads" but no winbind and no "net ads join" command, to authenticate an AD user using kerberos.
What nailed it was to use setspn on the windows side to add cifs/<hostname> to the computer account, like this (for a "bionic-sssd" computer account):
setspn -S cifs/bionic-sssd bionic-sssd
After that, this worked:
<email address hidden>
WARNING: The "syslog" option is deprecated
Try "help" to get a list of possible commands.
smb: \> dir
. D 0 Wed Apr 18 20:29:20 2018
.. D 0 Wed Apr 18 20:50:25 2018
hello.txt N 13 Wed Apr 18 20:29:20 2018
7950756 blocks of size 1024. 6300604 blocks available
smb: \> <email address hidden>
Ticket cache: FILE:/tmp/
Default principal: <email address hidden>
Valid starting Expires Service principal
04/18/18 20:51:05 04/19/18 06:51:05 <email address hidden>
renew until 04/19/18 20:51:05
04/18/18 20:51:49 04/19/18 06:51:05 <email address hidden>
<email address hidden>
uid=45001119(<email address hidden>) gid=45000513(domain <email address hidden>) groups=
<email address hidden>
<email address hidden>
My smb.conf has:
[global]
workgroup = LOWTECH
realm = LOWTECH.INTERNAL
kerberos method = system keytab
server role = member server
security = ads
...
Ah, and I didn't have to use the updated packages from my ppa, because I set "kerberos method = system keytab", so it wasn't trying "secrets" which is where the crash happens.
At some point I also installed libwbclient-sssd, during the experimentation. I can't say if it was essential now.
Alexander Fieroch (fieroch) wrote : | #27 |
> Above when you said "it works" after trying "net ads join", did you mean just the join, or that samba started to authenticate domain users normally?
After additionally trying "net ads join" samba started to authenticate domain users normally. I can access a shared directory with a domain user without smb crash.
> check if "net ads join" creates another entry in the keytab file
Yes, "net ads join" additionally adds cifs/* entries in the keytab file.
I'm asking <email address hidden> if an additional "net ads join" is necessary when joining to AD by realm and use sssd for authentication.
> After a lot of experimentation, I got my samba server, with "security = ads" but no winbind and no "net ads join" command, to authenticate an AD user using kerberos.
> What nailed it was to use setspn on the windows side to add cifs/<hostname> to the computer account, like this (for a "bionic-sssd" computer account):
>
> setspn -S cifs/bionic-sssd bionic-sssd
Same here! It is also working with adding SPN host/ instead of cifs/.
Is there any linux tool that can rpc and create SPNs on the DC?
Alexander Fieroch (fieroch) wrote : | #28 |
after adding cifs/ entries on Windows DC to the machine account with setspn there are no cifs/ entries in local keytab file what "net ads join" alternatively has added and samba shares still are accessible.
Changed in samba (Ubuntu): | |
assignee: | nobody → Andreas Hasenack (ahasenack) |
status: | Confirmed → In Progress |
Andreas Hasenack (ahasenack) wrote : | #29 |
For the release team: this fixes a crash bug, but in a not very common scenario: domain was joined via sssd and not samba's net join command, and the config tells samba to look first at the secrets database which is only populated via net join.
The MP at https:/
There is no need to respin isos because of this, but if it happens for some other reason, it would be cool if this could get in. Otherwise, I can transform it into an SRU for bionic once CC is opened for development.
Launchpad Janitor (janitor) wrote : | #30 |
This bug was fixed in the package samba - 2:4.7.6+
---------------
samba (2:4.7.
* debian/
[PATCH] s3:passdb: Do not return OK if we don't have pinfo filled.
Thanks to Andreas Schneider <email address hidden>. (LP: #1761737)
-- Andreas Hasenack <email address hidden> Wed, 18 Apr 2018 11:49:55 -0300
Changed in samba (Ubuntu): | |
status: | In Progress → Fix Released |
Thanks for filing this bug in Ubuntu.
Could you please attach:
- /etc/samba/smb.conf
- the core dump or crash file (look in /var/crash)
So all these samba servers are joined to an AD realm domain, and have shares and whatnot, but when the share on a 18.04 server is accessed you get this crash? Could you please also attach the smb.conf file from one of these client computers that try to access the share on the 18.04 one?
Can you also try to access the 18.04 share with smbclient from:
- itself? smbclient //localhost/share -U somevaliduser
- the same computer where accessing it via nautilus/dolphin triggers the crash: smbclient //18.04server/share -U somevaliduser
Thanks