Thank you Rowland! I guess that's part of my confusion, I'm not sure how to best debug where Centrify ends and Samba begins. But if these log.smbd errors indicate Centrify vice Samba, I'm good with that. My global smb.conf is (didn't bother with the commented out stuff): [global] security = ADS realm = <our domain name> workgroup = <our workgroup name> netbios name = <the server name> machine password timeout = 0 passdb backend = tdbsam:/var/lib/samba/private/passdb.tdb kerberos method = secrets and keytab server signing = auto client ntlmv2 auth = yes ntlm auth = yes client use spnego = yes template shell = /bin/bash winbind use default domain = Yes winbind enum users = No winbind enum groups = No winbind nested groups = Yes idmap cache time = 0 idmap config * : backend = tdb idmap config * : range = 1000 - 200000000 idmap config * : base_tdb = 0 enable core files = false log level = 2 Scott ________________________________ From: samba <samba-bounces at lists.samba.org> on behalf of Rowland Penny via samba <samba at lists.samba.org> Sent: Friday, January 25, 2019 10:49 PM To: samba at lists.samba.org Subject: Re: [Samba] Troubleshooting help? On Fri, 25 Jan 2019 23:42:57 +0000 "Scott Z. via samba" <samba at lists.samba.org> wrote:> I'm terribly sorry if this isn't the proper place/method by which to > get help with troubleshooting Samba errors/issues, but it's the best > one I could find. I have an instance of Samba 4.8.3 running on a > Centos 7.6 VM server (kernel 3.10.0-957.1.3), along with Centrify > 5.5.2-578, that will allow folks to map a shared drive from their > Windows 10 machines generally fine, but quite regularly throws a > bunch of errors to the log.smbd file with stuff like the following: > > *** stack smashing detected ***; /usr/sbin/smbd terminated > ../lib/util/fault.c:79(fault report) > INTERNAL ERROR: singal 11 in pid ..... > Please read the Trouble-Shooting section of the Samba HOWTO > > These error messages have not proven to be very helpful, and I > regularly get called in off-hours because users suddenly lose the > ability to map to said share. I've tried googling the heck out of > the various cryptic error messages but haven't had much luck. > Typically a quick restart of the centrifydc-samba service fixes it, > bit this seems to happen every few weeks. I don't know if there's an > issue in my smb.conf or something else entirely happening, but if > anyone has any troubleshooting tips or hints please let me know! > Thanks! Scott > > p.s. - on same service I did a quick "systemctl status > centrifydc-samba", and it shows a couple dozen pids > with /usr/sbin/smbd next to them. I have no idea what these are, > aside from the obvious, but why are there so many?Whilst this may be a Samba fault, it might not be, it might be an interaction between Samba and Centrify. We do not provide Centrify and therefore cannot provide support for it. Having said that, Samba shouldn't crash, so can you provide us with a bit more info, lets start with your smb.conf Rowland -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
On Mon, 28 Jan 2019 17:19:03 +0000 Scott Z. <sudz28 at hotmail.com> wrote:> Thank you Rowland! I guess that's part of my confusion, I'm not sure > how to best debug where Centrify ends and Samba begins. But if these > log.smbd errors indicate Centrify vice Samba, I'm good with that. My > global smb.conf is (didn't bother with the commented out stuff):I have added some comments to your smb.conf: [global] security = ADS realm = <our domain name> workgroup = <our workgroup name> netbios name = <the server name> <-- don't really need this machine password timeout = 0 <-- Why is this turned off ? passdb backend = tdbsam:/var/lib/samba/private/passdb.tdb <-- you don need anything after 'tdbsam', but you do not need the whole line, it is the default setting kerberos method = secrets and keytab server signing = auto <-- bad idea to set this client ntlmv2 auth = yes <-- Default setting ntlm auth = yes <-- do you really want to use client use spnego = yes <-- Default setting template shell = /bin/bash winbind use default domain = Yes winbind enum users = No <-- Default setting winbind enum groups = No <-- Default setting winbind nested groups = Yes <-- Default setting idmap cache time = 0 <-- this turns winbind's cache off idmap config * : backend = tdb idmap config * : range = 1000 - 200000000 <-- bad range, you cannot have any local Unix users idmap config * : base_tdb = 0 <-- what is this ?? enable core files = false <-- if Samba crashes, you will not get any core dumps log level = 2 Or to put it another way, it only needs to be this: [global] security = ADS realm = <our domain name> workgroup = <our workgroup name> kerberos method = secrets and keytab template shell = /bin/bash winbind use default domain = Yes idmap config * : backend = tdb idmap config * : range = 1000 - 200000000 log level = 2 If this was a normal Samba Unix domain member it would also have (at least) these two lines: idmap config <our workgroup name> : backend = rid idmap config <our workgroup name> : range = 2000000001 - 300000000 You are using Samba 4.8.3, so you need to have winbind running, so now we come to the big question: Why do you feel you need Centrify instead of winbind ? What does it give you that Samba + winbind doesn't ? Rowland
I probably should have lead with this, but I did not create or deploy this particular setup, I was charged with keeping it going after the main person left. I have zero experience with Samba or Centrify, or I should say *had* no experience until this. So, I frankly have very little idea of what most of these options are for or why they're set the way they are. I can certainly edit per your suggestions and see if it helps at all. I have noticed that as people are getting window pop-ups asking them to enter their credentials (which they shouldn't get of course), I'm seeing a corresponding error in the log.smbd file that says "lookup_name_smbconf for <domain>\<user> failed", so I'm trying to see if I can find anything more specific about what might be causing that issue. Also, I do have samba-winbind-4.8.3 installed and winbind appears to be running (ps -ef |grep winbind returns two lines of "/usr/sbin/winbindd -s /etc/centrifydc/smb2.conf"). As to why this is using Centrify vice any other product, I cannot speak to that. Thanks much! Scott ________________________________ From: samba <samba-bounces at lists.samba.org> on behalf of Rowland Penny via samba <samba at lists.samba.org> Sent: Monday, January 28, 2019 8:35 AM To: samba at lists.samba.org Subject: Re: [Samba] Troubleshooting help? On Mon, 28 Jan 2019 17:19:03 +0000 Scott Z. <sudz28 at hotmail.com> wrote:> Thank you Rowland! I guess that's part of my confusion, I'm not sure > how to best debug where Centrify ends and Samba begins. But if these > log.smbd errors indicate Centrify vice Samba, I'm good with that. My > global smb.conf is (didn't bother with the commented out stuff):I have added some comments to your smb.conf: [global] security = ADS realm = <our domain name> workgroup = <our workgroup name> netbios name = <the server name> <-- don't really need this machine password timeout = 0 <-- Why is this turned off ? passdb backend = tdbsam:/var/lib/samba/private/passdb.tdb <-- you don need anything after 'tdbsam', but you do not need the whole line, it is the default setting kerberos method = secrets and keytab server signing = auto <-- bad idea to set this client ntlmv2 auth = yes <-- Default setting ntlm auth = yes <-- do you really want to use client use spnego = yes <-- Default setting template shell = /bin/bash winbind use default domain = Yes winbind enum users = No <-- Default setting winbind enum groups = No <-- Default setting winbind nested groups = Yes <-- Default setting idmap cache time = 0 <-- this turns winbind's cache off idmap config * : backend = tdb idmap config * : range = 1000 - 200000000 <-- bad range, you cannot have any local Unix users idmap config * : base_tdb = 0 <-- what is this ?? enable core files = false <-- if Samba crashes, you will not get any core dumps log level = 2 Or to put it another way, it only needs to be this: [global] security = ADS realm = <our domain name> workgroup = <our workgroup name> kerberos method = secrets and keytab template shell = /bin/bash winbind use default domain = Yes idmap config * : backend = tdb idmap config * : range = 1000 - 200000000 log level = 2 If this was a normal Samba Unix domain member it would also have (at least) these two lines: idmap config <our workgroup name> : backend = rid idmap config <our workgroup name> : range = 2000000001 - 300000000 You are using Samba 4.8.3, so you need to have winbind running, so now we come to the big question: Why do you feel you need Centrify instead of winbind ? What does it give you that Samba + winbind doesn't ? Rowland -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Centrify is *not* your friend as an ordinary file server or client. It's a high security tool suite, and as soon as you step aside from their recommended security structures it can become your direct enemy.>From painful experience, do *not* run its services on anything otherthan their primary maintaned operating system. Also, why in the devil do you need Centrify as a Samba server to mount shares from Windows? That's a CIFS client operation, not a server operation. If the shares are stable, you can use autofs and cifs-utils. Are they authenticating with the Centrify based server?
On Mon, 28 Jan 2019 23:45:32 -0500 Nico Kadel-Garcia <nkadel at gmail.com> wrote:> Centrify is *not* your friend as an ordinary file server or client. > It's a high security tool suite, and as soon as you step aside from > their recommended security structures it can become your direct enemy. > From painful experience, do *not* run its services on anything other > than their primary maintaned operating system.Sounds like you have had problems with Centrify.> > Also, why in the devil do you need Centrify as a Samba server to mount > shares from Windows? That's a CIFS client operation, not a server > operation. If the shares are stable, you can use autofs and > cifs-utils. Are they authenticating with the Centrify based server?The OP doesn't seem to know what their DC is, but based on them using Centos instead of RHEL, it is possibly a Windows DC. Rowland