Samba 4.x is an intimidating piece of software. If it can perfrom the same function and use the same config, I'm willing to try it.

Without log messages or process table info, it's hard to advise any further. Generally speaking, Samba4 can do everything that Samba 3.6 does. If your server is a domain member or standalone, it should be relatively straightforward.

I migrated my Samba 3.6 servers to Samba4 when the badlock vulnerability was announced. My servers are AD domain members, so the migration was fairly simple. Without knowing which role (domain controller, domain member, standalone) your Samba server is providing, it's difficult to comment on the complexity of migrating your server to Samba4.

Consider spinning up a VM that is similar to your current server, including the same Samba 3.6 packages and your current smb.conf. See if you can replicate the problem your users are experiencing. Try upgrading the VM to Samba4 to see if the enabled features in your smb.conf file work with Samba4. Running testparm should tell you if it works (or not). When I performed my upgrade, I first had to discover which Samba 3.6.x packages were installed, then I had to remove those packages before installing the Samba4 packages. Backup your current smb.conf file prior to removing your Samba 3.6 packages. Check here for info on updating Samba: https://wiki.samba.org/index.php/Updating_Samba

Andrew

I have another samba server and upgraded it to samba4. testparm returns clean with the old config (ROLE_DOMAIN_PDC) and starts up fine. smbclient seems to work fine.

The next thing now is to try and make it a domain member so it can auth against AD.

Thanks, Andrew, I appreciate the pointers.

You might want to take a look at "Integrating Red Hat Enterprise Linux 6 with Active Directory". It's the best document I've seen on this topic. I found that Samba/Kerberos/Winbind is the most complete solution for attaching a Samba fileserver in my AD environment. https://access.redhat.com/sites/default/files/attachments/rhel-ad-integratio...

SSSD is really the way to go if you're running Centos 7, take a look at "Red Hat Enterprise Linux 7 Windows Integration Guide": https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pdf...

Below is my documentation on how to attach a RHEL/CentOS system to an Active Directory Domain using Samba/Kerberos/Winbind. This configuration will allow you to provide SMB file sharing and SSH logins for users in your AD domain. Note this works in my AD domain but there might be some additional settings required for your AD domain. Work closely with your AD domain administrator.

The name of the example server in this document is server.example.com, substitute all values specific to your environment. Sample configuration files are included following these directions. The following packages should be installed: samba4, samba4-common, samba4-client, samba4-winbind, samba4-winbind-clients, krb5-workstation, openldap-clients

1. Set NTP to use the correct server for your Active Directory domain: system-config-time Set the primary NTP server to be your domain/forest NTP server NTP_IP_address 2. Make backups of and edit the following system configuration files: a. cp -p /etc/resolv.conf{,.bak} b. vi /etc/resolv.conf c. cp -p /etc/hosts{,.bak} d. vi /etc/hosts e. cp -p /etc/nsswitch.conf{,.bak} f. vi /etc/nsswitch.conf g. cp -p /etc/samba/smb.conf{,.bak} h. vi /etc/samba/smb.conf If you are editing a smb.conf file of a previously existing Samba fileserver, do not change the range value in the "idmap config * : range =" parameter i. cp -p /etc/krb5.conf{,.bak} j. vi /etc/krb5.conf 3. Start the smb and winbind services: a. /etc/init.d/smb start b. /etc/init.d/winbindd start Note that smb and winbind daemons need to be set to start up on boot. In addition, the appropriate TCP ports will need to open on the system firewall if you are deploying a SMB/CIFS fileserver. 4. Create a computer record in your Active Directory OU Computers container: For server.example.com create a computer record called server 5. Initialize Kerberos and attach it to the Active Directory domain: a. kinit username b. net ads join -w EXAMPLE.COM -U username 6. Verify the bind to AD is valid: a. net ads info b. net ads testjoin 7. Create a Kerberos /etc/krb5.keytab file: net ads keytab create -U username 8. Verify the contents of the Kerberos keytab file: klist -ke 9. Add a share that has access restricted to an Active Directory group: a. mkdir /data b. vi /etc/samba/smb.conf After the [homes}, section add the following text: [data] comment = Data Directory path = /data valid users = @"DOMAIN\AD_Group" writable = yes browseable = yes Substitute DOMAIN\AD_Group with an AD group that will be accessing this share. c. /etc/init.d/smb restart 10. Enable home directory creation a. system-config-authentication b. In the Advance Options tab, check the "Create home directories on the first login" checkbox. 11. Restrict SSH logins to a specific local and Active Directory groups Add this line to /etc/ssh/sshd_config: a. AllowGroups group_name Replace group_name with your local and AD group names. Note that the group names cannot have a space in the group name. Also make sure that at least one local group is added, otherwise you will not be able to SSH into your own server with a local account. 12. Restart your server

Sample files:

/etc/resolv.conf search example.com nameserver IP_address

/etc/hosts 127.0.0.1 localhost.localdomain localhost IP_address server.example.com server

/etc/nsswitch.conf passwd: files winbind shadow: files winbind group: files winbind hosts: files dns wins bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files netgroup: files publickey: nisplus automount: files aliases: files nisplus

/etc/samba/smb.conf workgroup = example realm = EXAMPLE.COM server string = %h password server = * security = ads client use spnego principal = yes client use spnego = yes kerberos method = secrets and keytab server max protocol = SMB3 client signing = auto server signing = auto machine password timeout = 0 template shell = /bin/bash winbind use default domain = true winbind offline logon = false winbind refresh tickets = true idmap config * : range = 16777216-33554431

/etc/krb5.conf [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = EXAMPLE.COM default_keytab_name = /etc/krb5.keytab dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h forwardable = yes [realms] EXAMPLE.COM = { kdc = kdc.example.com.:88 kdc = IP_address admin_server = kdc.example.com kdc = IP_address } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM [kdc] profile = /var/kerberos/krb5kdc/kdc.conf [appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false }

Andrew

...

net ads keytab create -U username 8. Verify the contents of the Kerberos keytab file: klist -ke

This is a step I was missing. What is the purpose of the keytab? Can it help with the default ticket FILE:/tmp/krb5cc_0 expiration?

A Kerberos keytab contains Kerberos principals and encrypted keys which can be used to authenticate without entering a password. That should address your ticket expiration issue.

I'm also facing this problem, although everything seems to work fine. I've tested with smbclient and a Windows client.

# net ads testjoin gss_init_sec_context failed with [Unspecified GSS failure. Minor code may provide more information: No credentials cache found] Join is OK #

Not sure what would cause that error message, nor have I experienced it. Looks like other people have seen it: https://www.google.com/?gws_rd=ssl#q=gss_init_sec_context+failed+with+%5BUns...

Am 14.09.2016 um 17:50 schrieb isdtor isdtor@gmail.com:

...

Not sure what would cause that error message, nor have I experienced it. Looks like other people have seen it: https://www.google.com/?gws_rd=ssl#q=gss_init_sec_context+failed+with+%5BUns...

I found no way to get rid of this, although everything seems to work fine.

Red Hat need to push out an update to samba4 and fix bug 10604. It's highly irritating, and the workaround https://bugzilla.samba.org/show_bug.cgi?id=10604#c30 doesn't. The patch from https://bugzilla.samba.org/show_bug.cgi?id=10604#c17 does.

If you have not done so already, I would definitely report this to upstream (bugzilla.redhat.com).

-- LF

On 05/20/2017 06:10 PM, Adam Tauno Williams wrote:

Six months later, now on CentOS6.9, we still see the same issue - constantly logging this message. Server packages are all up-to-date.

I find multiple reports on the Internet - but no solutions.

The bug report mentioned in the message you replied to indicates that the problem was fixed in samba's master branch with this commit:

https://git.samba.org/?p=samba.git;a=commit;h=4d5680e9ae531c6dc4d0a6687abe62...

That change isn't included in samba 4.4, distributed in RHEL 7 (nor 4.2 in RHEL 6), so you'll probably need to patch the software yourself, or wait for a 4.5 or newer package (which won't happen before the next point release, which is probably ~6 months away). If you're a customer, you can also file a bug report and request that specific patch be reviewed as an enhancement for a future release.