And then shared folders stopped working...?

Bug
, ,
1

NethServer Version: NS7rc1
Module: fileserver

Hi all,
me and samba/shared folders, we can’t get along very well…
I had stuff working:
NS7rc1, Samba AD, fileserver.
I manually added NFS, partially serving the same folders as samba.
Then I changed some stuff on my webserver:
Let’s encrypt certificate, for which I added some info in “organization contacts”,
blocked SSLv3 on the main apache-server, changed some cipher-stuff (wrote in this topic).
Rebooted.
And then, samba stopped accepting access from windows hosts:
Nov 9 13:55:32 helium smbd[17482]: pam_unix(samba:session): session closed for user nobody
(from /var/log/secure)

I have to say I don’t use the shared folders on a daily basis; maybe it was broken before. My problem is: where to start troubleshooting? /var/log/secure doesn’t tell me more then the one line above. logs in samba doesn’t give a clue.
nmap to the IP of the LDAP-server:

root@helium:samba> $ nmap 192.168.1.20

Starting Nmap 6.40 ( http://nmap.org ) at 2016-11-09 14:25 CET
Nmap scan report for 192.168.1.20
Host is up (0.0000080s latency).
Not shown: 989 closed ports
PORT STATE SERVICE
53/tcp open domain
88/tcp open kerberos-sec
135/tcp open msrpc
139/tcp open netbios-ssn
389/tcp open ldap
445/tcp open microsoft-ds
464/tcp open kpasswd5
636/tcp open ldapssl
1024/tcp open kdm
3268/tcp open globalcatLDAP
3269/tcp open globalcatLDAPssl
MAC Address: 1A:2B:DB:23:B7:57 (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 0.11 seconds

Looks OK to me.

Info in domain accounts:

NetBIOS domain name: ROLFBAKKER
LDAP server: 192.168.1.20
LDAP server name: nsdc-helium.rolfbakker.nl
Realm: ROLFBAKKER.NL
Bind Path: dc=ROLFBAKKER,dc=NL
LDAP port: 389
Server time: Wed, 09 Nov 2016 14:24:52 CET
KDC server: 192.168.1.20
Server time offset: 0

Join is OK
name: HELIUM
objectSid: S-1-5-21-3159083151-2014931961-3051134071-1103
accountExpires: 9223372036854775807
sAMAccountName: HELIUM$
pwdLastSet: 131219523080000000
dNSHostName: helium.rolfbakker.nl
servicePrincipalName: HOST/HELIUM
servicePrincipalName: HOST/helium.rolfbakker.nl
servicePrincipalName: smtp/helium
servicePrincipalName: smtp/helium.rolfbakker.nl
servicePrincipalName: pop/helium
servicePrincipalName: pop/helium.rolfbakker.nl
servicePrincipalName: imap/helium
servicePrincipalName: imap/helium.rolfbakker.nl
whenChanged: 20161109124622.0Z
lastLogon: 131231714925171150
distinguishedName: CN=HELIUM,CN=Computers,DC=rolfbakker,DC=nl

Can someone help me? Where to start looking? Or is it possible to reset the whole thing? (ok, have to copy 350 GB again, but that can be done…)

2

It seems you’re accessing some share with guest access (or wrong user credentials).

3

yes, that’s where I saw that error before, but know I’m sure it’s right
(copy paste from login to webmail):
ROLFBAKKER\rolf

Also tried to make a new test-user, but that also couldn’t logon to shared folders…
Also tried to make a new shared folder, same story there…

4

[I assume your server has the latest available updates]

Please try to access with the following command

smbclient -d 10 -U 'ROLFBAKKER\rolf' //helium/<sharedfoldername>

It should work from host helium itself and also from another host in the LAN.

5

Thanks for your help!
I’ve installed samba-client.
OK, that’s a lot of output flying over my screen.
When trying from NS (helium) itself, the output from the moment of typing in my password:

Enter ROLFBAKKER\rolf's password:
Opening cache file at /var/lib/samba/gencache.tdb
tdb(/var/lib/samba/gencache.tdb): tdb_open_ex: could not open file /var/lib/samba/gencache.tdb: Permission denied
gencache_init: Opening cache file /var/lib/samba/gencache.tdb read-only.
Opening cache file at /var/lib/samba/gencache_notrans.tdb
sitename_fetch: Returning sitename for ROLFBAKKER.NL: "Default-First-Site-Name"
internal_resolve_name: looking up helium#20 (sitename Default-First-Site-Name)
no entry for helium#20 found.
resolve_lmhosts: Attempting lmhosts lookup for name helium<0x20>
resolve_lmhosts: Attempting lmhosts lookup for name helium<0x20>
getlmhostsent: lmhost entry: 127.0.0.1 localhost
resolve_wins: WINS server resolution selected and no WINS servers listed.
resolve_hosts: Attempting host lookup for name helium<0x20>
remove_duplicate_addrs2: looking for duplicate address/port pairs
namecache_store: storing 1 address for helium#20: 192.168.1.2
Adding cache entry with key=[NBT/HELIUM#20] and timeout=[Wed Nov  9 04:38:40 PM 2016 CET] (660 seconds ahead)
internal_resolve_name: returning 1 addresses: 192.168.1.2:0
Connecting to 192.168.1.2 at port 445
Socket options:
        SO_KEEPALIVE = 0
        SO_REUSEADDR = 0
        SO_BROADCAST = 0
        TCP_NODELAY = 1
        TCP_KEEPCNT = 9
        TCP_KEEPIDLE = 7200
        TCP_KEEPINTVL = 75
        IPTOS_LOWDELAY = 0
        IPTOS_THROUGHPUT = 0
        SO_REUSEPORT = 0
        SO_SNDBUF = 2626560
        SO_RCVBUF = 1061296
        SO_SNDLOWAT = 1
        SO_RCVLOWAT = 1
        SO_SNDTIMEO = 0
        SO_RCVTIMEO = 0
        TCP_QUICKACK = 1
        TCP_DEFER_ACCEPT = 0
 session request ok
Doing spnego session setup (blob length=96)
got OID=1.2.840.48018.1.2.2
got OID=1.2.840.113554.1.2.2
got OID=1.3.6.1.4.1.311.2.2.10
got principal=not_defined_in_RFC4178@please_ignore
GENSEC backend 'gssapi_spnego' registered
GENSEC backend 'gssapi_krb5' registered
GENSEC backend 'gssapi_krb5_sasl' registered
GENSEC backend 'spnego' registered
GENSEC backend 'schannel' registered
GENSEC backend 'naclrpc_as_system' registered
GENSEC backend 'sasl-EXTERNAL' registered
GENSEC backend 'ntlmssp' registered
GENSEC backend 'ntlmssp_resume_ccache' registered
GENSEC backend 'http_basic' registered
GENSEC backend 'http_ntlm' registered
Starting GENSEC mechanism spnego
Starting GENSEC submechanism ntlmssp
     negotiate: struct NEGOTIATE_MESSAGE
        Signature                : 'NTLMSSP'
        MessageType              : NtLmNegotiate (1)
        NegotiateFlags           : 0x62088215 (1644724757)
               1: NTLMSSP_NEGOTIATE_UNICODE
               0: NTLMSSP_NEGOTIATE_OEM
               1: NTLMSSP_REQUEST_TARGET
               1: NTLMSSP_NEGOTIATE_SIGN
               0: NTLMSSP_NEGOTIATE_SEAL
               0: NTLMSSP_NEGOTIATE_DATAGRAM
               0: NTLMSSP_NEGOTIATE_LM_KEY
               0: NTLMSSP_NEGOTIATE_NETWARE
               1: NTLMSSP_NEGOTIATE_NTLM
               0: NTLMSSP_NEGOTIATE_NT_ONLY
               0: NTLMSSP_ANONYMOUS
               0: NTLMSSP_NEGOTIATE_OEM_DOMAIN_SUPPLIED
               0: NTLMSSP_NEGOTIATE_OEM_WORKSTATION_SUPPLIED
               0: NTLMSSP_NEGOTIATE_THIS_IS_LOCAL_CALL
               1: NTLMSSP_NEGOTIATE_ALWAYS_SIGN
               0: NTLMSSP_TARGET_TYPE_DOMAIN
               0: NTLMSSP_TARGET_TYPE_SERVER
               0: NTLMSSP_TARGET_TYPE_SHARE
               1: NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY
               0: NTLMSSP_NEGOTIATE_IDENTIFY
               0: NTLMSSP_REQUEST_NON_NT_SESSION_KEY
               0: NTLMSSP_NEGOTIATE_TARGET_INFO
               1: NTLMSSP_NEGOTIATE_VERSION
               1: NTLMSSP_NEGOTIATE_128
               1: NTLMSSP_NEGOTIATE_KEY_EXCH
               0: NTLMSSP_NEGOTIATE_56
        DomainNameLen            : 0x0000 (0)
        DomainNameMaxLen         : 0x0000 (0)
        DomainName               : *
            DomainName               : ''
        WorkstationLen           : 0x0000 (0)
        WorkstationMaxLen        : 0x0000 (0)
        Workstation              : *
            Workstation              : ''
        Version: struct ntlmssp_VERSION
            ProductMajorVersion      : NTLMSSP_WINDOWS_MAJOR_VERSION_6 (6)
            ProductMinorVersion      : NTLMSSP_WINDOWS_MINOR_VERSION_1 (1)
            ProductBuild             : 0x0000 (0)
            Reserved: ARRAY(3)
                [0]                      : 0x00 (0)
                [1]                      : 0x00 (0)
                [2]                      : 0x00 (0)
            NTLMRevisionCurrent      : NTLMSSP_REVISION_W2K3 (15)
Got challenge flags:
Got NTLMSSP neg_flags=0x62898215
  NTLMSSP_NEGOTIATE_UNICODE
  NTLMSSP_REQUEST_TARGET
  NTLMSSP_NEGOTIATE_SIGN
  NTLMSSP_NEGOTIATE_NTLM
  NTLMSSP_NEGOTIATE_ALWAYS_SIGN
  NTLMSSP_TARGET_TYPE_DOMAIN
  NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY
  NTLMSSP_NEGOTIATE_TARGET_INFO
  NTLMSSP_NEGOTIATE_VERSION
  NTLMSSP_NEGOTIATE_128
  NTLMSSP_NEGOTIATE_KEY_EXCH
NTLMSSP: Set final flags:
Got NTLMSSP neg_flags=0x62088215
  NTLMSSP_NEGOTIATE_UNICODE
  NTLMSSP_REQUEST_TARGET
  NTLMSSP_NEGOTIATE_SIGN
  NTLMSSP_NEGOTIATE_NTLM
  NTLMSSP_NEGOTIATE_ALWAYS_SIGN
  NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY
  NTLMSSP_NEGOTIATE_VERSION
  NTLMSSP_NEGOTIATE_128
  NTLMSSP_NEGOTIATE_KEY_EXCH
NTLMSSP Sign/Seal - Initialising with flags:
Got NTLMSSP neg_flags=0x62088215
  NTLMSSP_NEGOTIATE_UNICODE
  NTLMSSP_REQUEST_TARGET
  NTLMSSP_NEGOTIATE_SIGN
  NTLMSSP_NEGOTIATE_NTLM
  NTLMSSP_NEGOTIATE_ALWAYS_SIGN
  NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY
  NTLMSSP_NEGOTIATE_VERSION
  NTLMSSP_NEGOTIATE_128
  NTLMSSP_NEGOTIATE_KEY_EXCH
SPNEGO login failed: Logon failure
session setup failed: NT_STATUS_LOGON_FAILURE

What questions me is the line:
internal_resolve_name: looking up helium#20 (sitename Default-First-Site-Name)
no entry for helium#20 found.
Further a helium<0x20> is shown.
Isn’t that a hex space? And is that an error?

6

No it’s a NetBIOS lookup, where the last character is the query type:

https://support.microsoft.com/en-us/kb/830578

Could you try with the IP?

smbclient -d 10 -U 'ROLFBAKKER\rolf' //<heliumIP>/<sharedfoldername>

…anyway it does not seem a name resolution problem

internal_resolve_name: returning 1 addresses: 192.168.1.2:0

Please try also with -W

smbclient -d 10 -W ROLFBAKKER -U 'ROLFBAKKER\rolf' //<heliumIP>/<sharedfoldername>
7

unfortunately, it gives the same result…
(should I post the complete output again?)

8

It seems I can reproduce it here :frowning:

Can you post the packages version?

rpm -qa | grep ^nethserver
9

sure:
root@helium:~> $ rpm -qa|grep -i ^nethserver
nethserver-mail-server-1.10.4-1.ns7.noarch
nethserver-httpd-admin-2.0.4-1.ns7.noarch
nethserver-base-3.0.11-1.ns7.noarch
nethserver-dc-1.0.7-1.ns7.x86_64
nethserver-unbound-1.1.0-1.ns7.noarch
nethserver-dnsmasq-1.6.1-1.ns7.noarch
nethserver-nethforge-release-7-0.3.ns7.noarch
nethserver-spamd-1.0.0-1.ns7.noarch
nethserver-mail-filter-1.4.3-1.ns7.noarch
nethserver-restore-data-1.2.1-1.ns7.noarch
nethserver-ibays-3.0.2-1.ns7.noarch
nethserver-release-7-0.5.ns7.noarch
nethserver-lang-en-1.1.5-1.ns7.noarch
nethserver-hosts-1.2.1-1.ns7.noarch
nethserver-backup-config-1.5.1-1.ns7.noarch
nethserver-duc-1.4.0-1.ns7.noarch
nethserver-antivirus-1.2.0-1.ns7.noarch
nethserver-firewall-base-3.1.2-1.ns7.noarch
nethserver-ntp-1.1.0-1.ns7.noarch
nethserver-smartd-1.1.0-1.ns7.noarch
nethserver-virtualhosts-1.0.2-1.ns7.noarch
nethserver-getmail-1.0.0-1.ns7.noarch
nethserver-collectd-3.0.3-1.ns7.noarch
nethserver-cgp-2.1.1-1.ns7.noarch
nethserver-memcached-1.1.0-1.ns7.noarch
nethserver-lib-2.2.1-1.ns7.noarch
nethserver-samba-2.0.2-1.ns7.noarch
nethserver-samba-audit-1.1.1-1.ns7.noarch
nethserver-httpd-3.1.1-1.ns7.noarch
nethserver-mysql-1.1.0-1.ns7.noarch
nethserver-vsftpd-1.1.0-1.ns7.noarch
nethserver-openssh-1.2.0-1.ns7.noarch
nethserver-mail-smarthost-0.1.0-1.ns7.noarch
nethserver-mail-common-1.6.2-1.ns7.noarch
nethserver-roundcubemail-1.2.3-1.ns7.noarch
nethserver-sssd-1.0.8-1.ns7.noarch
nethserver-yum-1.4.1-1.ns7.noarch
nethserver-php-1.2.0-1.ns7.noarch
nethserver-firewall-base-ui-3.1.2-1.ns7.noarch
nethserver-letsencrypt-1.1.2-1.ns7.noarch
nethserver-phonehome-1.2.1-1.ns7.noarch
nethserver-backup-data-1.2.2-1.ns7.noarch
nethserver-lsm-1.2.0-1.ns7.noarch

More info needed?

10

I’m afraid this is a regression due to bugfix #5142.

This statement is a wet blanket:

If you require NTLM authentication or NetBIOS name lookup, use Winbind for accessing a CIFS share instead of SSSD.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/sssd-ad-integration.html#CIFS-SSSD

Same music here:

If confirmed we have some decisions to make.

Can you try to access the share from a domain member workstation with AD SSO?

11

euh, przk, klmn, que?
I know my way around Linux, and have some basic Windows-knowledge. Can you please explain what I have to do exactly?
I have 2 W10 home-edition laptops, with local accounts. I only use samba to serve them some shared folders (family-pics). Does that suit the requirements for your question?

2 Likes
12

cosa? :joy:

Kerberos login

No, I learned here only Professional editions have the Kerberos support.

13

Thank you very much for the report @rolf. It seems you hit a “regression bug” caused by this fix

/cc @saitobenkei @fasttech

Loading the libwbclient library from sssd (instead of the one from Samba) fixes the ACLs management but (as the RHEL7 docs says) breaks the NTLM and NetBIOS support. Only kerberos auth works with it.

The workaround to Rolf’s problem is reverting the bugfix#5142 effects with the following commands:

alternatives --set libwbclient.so.0.12-64 /usr/lib64/samba/wbclient/libwbclient.so.0.12
systemctl restart smb

After these commands, ACLs can’t be set from Windows Pro workstations.

To show the current settings

alternatives --display libwbclient.so.0.12-64

Now that we’re aware of this limitation we must decide what to do. I see the following alternatives

  1. drop sssd libraries for samba and configure winbind
  2. turn this bug into a feature! Implement a switch in server-manager to choose what scenario NethServer must support: a) an AD domain where all clients are Kerberos clients (Win Pro), with full ACLs support, b) an AD domain with mixed clients (Home/Pro, NTLM/Kerberos) with the limitation on ACLs

The solution 1 is a big revolution in our configuration and I’d prefer not considering it.

The solution 2 is actually let the sysadmin to choose between living with the limitation on ACLs to support legacy clients, or support only Win Pro and fully leverage the upstream solution based on sssd.

What do you think? /cc @dev_team @quality_team

4 Likes
14

I vote for a radio button inside the web interface ;D

2 Likes
15

I agree, we could resume the “Windows network” page with that radio button and the input field for the workgroup name, requested by @flatspin here.

2 Likes
16

Thank you very much for the investigation and this workaround! Is that workaround ‘upgrade-proof’? Or should I monitor if there’s an upgrade to this file and the re-apply?

As for the choice of structural solution: I have no clue :wink:
What I can say, is that to my opinion the windows-integration is hard to understand, and not always well-documented. If a new radio-button is introduces, please make sure the online-help is clear to all win-no’s as me.

2 Likes
17

Windows network page would be stringent, I think. And for a “simple” workgroup setup it’s an acceptable limitation.

Otpion 1 is maybe a thought worth for V8?

1 Like
18

As usual I’d prefer following the upstream guidelines. Let’s wait for RHEL8! I hope in the meantime they’ll develop the NTLM support…

19

Yes it’s the alternatives mission. It sets symbolic links in a way consistent with RPMs. Once an alternative is set by the admin, it is not changed by the system, AFAIK.

I’d go with legacy support enabled by default. It seems the safest default, and would work in your case. If NTLM is not necessary and full ACLs control from windows clients is wanted, it can be enabled from the UI.

I want to point out that ACLs in “legacy” mode can be set from the Shared folder > ACL tab. I checked them out, they work.

2 Likes
20

Great, thanks for the effort and quick responses!
When I understand correctly, none of the actions performed by me (as described in the first post of this threat) was the trigger for not-functioning? Yet the upgrade of some packages was?