Samba 4: domain joined, but all users are mapped to nobody, and shares are inaccessible from Windows clients

Question

I've got a Debian/Jessie Samba 4.2.14 running as an AD member. ADC is a Windows2008R2 server. Join worked without problem.

# net ads testjoin
Join is OK

wbinfo -u and wbinfo -g work perfectly and provides a list of users and groups from the AD as expected. wbinfo -i <user> works too:

# wbinfo -i TESTAD\\testuser
TESTAD\testuser:*:4294967295:4294967295:testuser:/home/TESTAD/testuser:/bin/false

Edit: something's wrong here, because wbinfo -i maps all users and groups to the id 4294967295 which is, as @TheSkunk remarked, 2^32 -1.

Edit 2: wbinfo --sid-to-uid TESTAD\\testuser fails. Surely I must set up explicitely some idmap parameters (the defaults apparently don't work at all) but how?

Edit 3: I've added these 2 lines to smb.conf:

idmap config * : backend = tdb
idmap config * : range = 10000-30000

And now ẁbinfo -i TESTDOMAIN\testuserreports a valid id, and a different one for each and every user. However I still have the same problems (all users mapping to nobody,idandgetent` not knowing of AD users, etc).

However getent passwd TESTAD\\testuser fails:

# getent passwd TESTAD\\testuser
# echo $? 
2

I can connect to the server with any AD account using smbclient:

# smbclient //srv1/data -U TESTAD\\testuser
Enter TESTAD\testuser's password: 
Domain=[TESTAD] OS=[Windows 6.1] Server=[Samba 4.2.14-Debian]
smb: \> ls
  .                                   D        0  Fri Feb 17 16:23:04 2017
  ..                                  D        0  Wed Feb  1 16:47:02 2017
  test.txt                            N        5  Fri Feb 17 14:38:21 2017
  popo                                D        0  Fri Feb 17 16:23:04 2017

                117125466112 blocks of size 1024. 117052392484 blocks available
smb: \> 

However the connection is mapped to nobody/nogroup, and created files are owned by nobody too. Windows machines fail to connect using any AD account. However if I create a local account with smbpasswd -a <user>, they can connect using it. However, their connection parameters, files, etc. are all mapped to nobody though the account exists locally too.

Here's the current smb.conf (as close to default as possible):

[global]
        workgroup = TESTAD
        realm = TESTAD.lan
        server role = member server
        security = ADS
        map to guest = Bad User
        obey pam restrictions = Yes
        pam password change = Yes
        passwd program = /usr/bin/passwd %u
        passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
        unix password sync = Yes
        syslog = 0
        log file = /var/log/samba/log.%m
        max log size = 1000
        dns proxy = No
        usershare allow guests = Yes
        panic action = /usr/share/samba/panic-action %d
        idmap config * : backend = tdb
        inherit permissions = Yes
        inherit acls = Yes


[DATA]
        path = /mnt/raid/
        read only = No
        guest ok = Yes

here is /etc/nsswitch.conf (I've tried adding and removing 'winbindd from shadow, no change at all):

# cat /etc/nsswitch.conf 
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat winbind
group:          compat winbind
shadow:         compat winbind
gshadow:        files

hosts:          files mdns4_minimal [NOTFOUND=return] dns wins
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

I don't understand why authentication never seems to go through winbind. I'm getting desperate, any ideas?

Answer 1

I've found the core problem: a missing package. Unfortunately it's not easy to get right: here is the final, working configuration (thanks to Rowland Penny from samba.org):

get sure you installed all the necessary packages (the missing one was libnss-winbind):

apt-get install samba acl attr quota fam winbind libpam-winbind \
libpam-krb5 libnss-winbind krb5-config krb5-user ntp dnsutils ldb-tools

stop the services

service smbd stop
service nmbd stop
service winbind stop

set up a proper smb.conf (particularly the idmap parameters):

[global]
    workgroup = TESTAD
    security = ADS
    realm = TESTAD.LAN

    dedicated keytab file = /etc/krb5.keytab
    kerberos method = secrets and keytab
    server string = Data %h

    winbind use default domain = yes
    winbind expand groups = 4
    winbind nss info = rfc2307
    winbind refresh tickets = Yes
    winbind offline logon = yes
    winbind normalize names = Yes

    ## map ids outside of domain to tdb files.
    idmap config *:backend = tdb
    idmap config *:range = 2000-9999
    ## map ids from the domain  the ranges may not overlap !
    idmap config TESTAD : backend = rid
    idmap config TESTAD : range = 10000-999999
    template shell = /bin/bash
    template homedir = /home/TESTAD/%U

    domain master = no
    local master = no
    preferred master = no
    os level = 20
    map to guest = bad user
    host msdfs = no

    # user Administrator workaround, without it you are unable to set privileges
    username map = /etc/samba/user.map

    # For ACL support on domain member
    vfs objects = acl_xattr
    map acl inherit = Yes
    store dos attributes = Yes

    # Share Setting Globally
    unix extensions = no
    reset on zero vc = yes
    veto files = /.bash_logout/.bash_profile/.bash_history/.bashrc/
    hide unreadable = yes

    # disable printing completely
    load printers = no
    printing = bsd
    printcap name = /dev/null
    disable spoolss = yes

In that configuration, there is a required additional /etc/samba/user.map file containing the following line:

!root = TESTAD\Administrator TESTAD\administrator Administrator administrator

Don't forget to properly fill in /etc/krb5.conf:

[libdefaults]
    default_realm = TESTAD.LAN
    dns_lookup_realm = false
    dns_lookup_kdc = true

Be careful, krb5.conf must be owned by root and readable by everyone (644 rights).

Edit /etc/nsswitch.conf and add winbind to the passwd and group lines:

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat files winbind
group:          compat files winbind
shadow:         compat files 

hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Now join the domain:

# net ads join -U Administrator
Using short domain name -- TESTAD
Joined 'DEBMEMBER' to dns domain 'TESTAD.example.com'

Finally start the services:

service smbd start
service nmbd start
service winbind start

getent passwd should work with AD users now:

# getent passwd testuser
testuser:*:11107:10513:testuser:/home/TESTAD/testuser:/bin/bash

CAVEAT As I had previously joined the AD without having installed the necessary libraries, I had to reboot the system to get the system after this setup to properly authenticate users!

Answer 2

4294967295 means 2^32 - this is an overflow of counter for GID or UID produced by the winbind deamon to translate xids from AD. That has nothing todo with guest mapping... If you use idmap config YOUR_DOMAIN : backend = ad , the ad means, that the information is not only stored localy, more else it is replicated during runtime to all clients and also stored on them (but where this is, thats currently my task for finding out). ad means, if a client gets lost, you've stored all uid/gid mapping information on the other ones. If you restore your client, all mapping will be the same again. The problem is, if you have this overflow once, you can't get rid of it easyli, because all clients ar replicating it (running windbind) and, perhaps (I'm currently trying to find it out) also the DC.

Here the part I'm using for that (works fine, but I have an other issue on idmaps via ad):

winbind nss info = rfc2307
idmap config * : backend = tbd
idmap config * : range = 1000-2999

idmap config MY_DOMAIN : backend =  ad
idmap config MY_DOMAIN : schema_mode = rfc2307
idmap config MY_DOMAIN : range = 3000-30000
idmap_ldb:use rfc2307 = yes

winbind refresh tickets = yes
winbind use default domain = yes
winbind enum users  = yes
winbind enum groups = yes

winbind cache time = 60  #higher might make you wait long for updates 

Answer 3

Having landed here myself, while looking for some good instructions, thought I should add an update to this post...

Going forward, we are aiming to use sssd instead of winbind for Active Directory integration on Linux. Although sssd doesn't offer all the features of winbind, it uses Kerberos authentication instead of NT Lan Manager (NTLM) authentication. Ref: Red Hat Windows Integration Guide, Chapter 4.2

We are trying to reduce the usage of NTLM authentication in favour of Kerberos, as the latter is considered a more secure protocol.

With that said, we've configured our SAMBA file share as follows:-

1. Install realmd, samba, sssd and all dependencies. Maybe more?

2. Join realm: realm join <domain name>

   This command will use domain credentials to join the machine to the domain. This will then automatically configure nsswitch.conf, /etc/sssd/sssd.conf and /etc/krb5.conf, and also obtain a machine keytab, in /etc/krb5.keytab.

3. Make sure the file system is mounted with the acl option in /etc/fstab, e.g.

   UUID=foo-bar-baz /mnt/share ext4 defaults,acl 0 0

4. Configure samba correctly. There are so many options, that this is a bit of a dark art. YMMV, but what works for me is as follows. Anything withing < and > needs to be configured for your own network.

#/etc/samba/smb.conf
[global]
    # SMB settings
    security = ads
    workgroup = <workgroup>
    netbios name = <server name>
    server string = Samba %v on %L (%h)

    # NMB settings
    local master = no
    dns proxy = no

    # Authentication / Kerberos settings
    realm = <realm / domain name>
    password server = *
    kerberos method = secrets and keytab
    dedicated keytab file = /etc/krb5.keytab
    encrypt passwords = yes
    client use spnego = yes
    client signing = yes

    # ID mapping
    idmap config * : backend = autorid
    idmap config * : range = 1000000-1999999

    # Windows Extended ACLs
    vfs objects = acl_xattr
    map acl inherit = yes
    nt acl support = yes
    # This next one apparently incurs a significant performance hit without
    # additional functionality, but can help compatibility.
    # It adds the DOS Read-only, Archive and Hidden bits to file attributes.
    # store dos attributes = yes

[share]
    comment = <My Share>
    path = </mnt/share>
    valid users = @"<Domain Group>", <domain_user>
    # ... Other share-specific options

5. Set a Domain User or Group as group on the Unix file object. Remove everyone access.

> chown root:"Domain Users" /mnt/share
> chmod 770 /mnt/share

6. Now, hopefully, you should be able to access the file share from a domain-joined Windows PC, and set the permissions on it using the Windows Folder properties.

If somehow you locked yourself out of the share (as I did myself), Windows permissions can be viewed and changed using the following Linux commands:-

# get ACL permissions
> getfacl /mnt/share
# Set This Folder Only access on a share.
> setfacl -m group:"<domain>\<group>":rwx /mnt/share
# Set This Folder, Subdirectories and Files permissions on a folder
> set facl -m default:group:"<domain>\<group>":rwx /mnt/share

Answer 4

I had the error "client_input_channel_req: channel 0 rtype exit-status reply 0" on a new server02, on server01 no. The solution in my case was to add two lines that by mistake I did not add to /etc/samba/smb.conf:

template shell = /bin/bash

template home dir = /home/%D/%u

Now the domain users are logged in server02.

Best Regards.