NextCloud VM & Samba: Trying to access LDAP/Domain Users & Groups

Nextcloud version: 12.0.4
Operating system and version: Ubuntu 16.04.03 LTS
Apache or nginx version (eg, Apache 2.4.25):
PHP version (eg, 5.6):
Is this the first time you’ve seen this error?:
Can you reliably replicate it?: Yes.

My issue(s):
Using the NextCloud VM (appliance), I am attempting to use Samba to join a domain (currently has a single Windows Server 2003 DC) and I want to use Samba to share a folder (which has been added via the web interface) with domain users over the LAN using CIFS (they are a mix of Windows desktop OS and windows Server 2016 terminal server sessions). NextCloud VM is “fs1” and domain is “example.local”.

I have read lots of walk-through guides and documented which steps appear to work best for me. i have installed the NIS tools on the domain controller and I’ve assigned UID and GID groups to the users and groups we care about (and made sure the users are part of the groups in NIS, not just members of the domain groups). I am able to join the NextCloud VM to the domain with no issues, so all the nameserver and DNS and Kerberos stuff seems like it should be good. Samba is configured. Winbind is configured. Testparm returns good. “wbinfo -u” lists domain users. “wbinfo -g” lists domain groups. BUT… “getent group” lists only local groups, and “getent passwd” lists only local users. AND… “chgrp -R “Domain Users” /var/ncdata/ncadmin/files/kdrive/” returns a message saying Domain Users is invalid. Also, no domain user can access the share (or the server via “\fs1”) because it says invalid login.

Packages installed:
ntp krb5-user samba smbclient winbind (smbfs was removed from the packages that one article recommended because it’s not found in the repo; not sure if this is part of my issue?)

/etc/hosts:

"127.0.1.1 " line removed; (dns returns "fs1" as having the correct LAN IP)

/etc/nsswitch.conf: (tried replacing “compat” with “files”, no luck):

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

/etc/resolvconf/resolv.conf.d/base

nameserver 192.168.88.10 (existing Win2003R2 domain controller)
nameserver 192.168.88.11 (not currently in use; I expect to replace the Win DC with 2 appliances from Turnkeylinux)
nameserver 192.168.88.12 (not currently in use)
nameserver 4.2.2.1
nameserver 4.2.2.2
nameserver 8.8.8.8
nameserver 8.8.4.4
search example.local

/etc/krb5.conf

[libdefaults]
    default_realm = EXAMPLE.LOCAL
    dns_lookup_realm = false
    dns_lookup_kdc = true
    ticket_lifetime = 24h
    forwardable = true
[realms]
    EXAMPLE.LOCAL = {
        kdc = 192.168.88.10
        default_domain = EXAMPLE.LOCAL
    }
[domain_realm]
    .example.local = EXAMPLE.LOCAL
    example.local = EXAMPLE.LOCAL
[kdc]
    profile = /etc/krb5kdc/kdc.conf
[appdefaults]
    pam = {
        debug = false
        ticket_lifetime = 36000
        renew_lifetime = 36000
        forwardable = true
        krb4_convert = false
    }
[logging]
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmin.log
    default = FILE:/var/log/krb5lib.log

/ect/samba/smb.conf:

[global]
    workgroup = EXAMPLE
    security = ads
    realm = EXAMPLE.LOCAL
    domain master = no
    local master = no
    preferred master = no
    # Disable printing error log messages when CUPS is not installed.
    printcap name = /etc/printcap
    load printers = no
    idmap_ldb : use rfc2307 = yes
    # idmap backend = tdb
    # idmap uid = 10000-99999
    # idmap gid = 10000-99999
    idmap config * : backend = tdb
    idmap config * : range = 3000-7999
    idmap config EXAMPLE : backend = ad
    idmap config EXAMPLE : schema_mode = rfc2307
    idmap config EXAMPLE : range = 10000-99999
    idmap config EXAMPLE : unix_nss_info = yes
    winbind enum users = yes
    winbind enum groups = yes
    # This way users log in with username instead of username@example.org
    winbind use default domain = yes
    winbind nested groups = yes
    winbind refresh tickets = yes
    winbind offline logon = true
    #winbind options
    #winbind operator = +
    winbind uid = 10000-25000
    winbind gid = 10000-25000
    winbind cache time = 15
    winbind cache time = 15
    winbind enum users = yes
    winbind enum groups = yes
    template homedir = /home/winnt/%D/%U
    template shell = /bin/shell
    # Becomes /home/example/username
    template homedir = /home/%D/%U
    template shell = /bin/bash
    client use spnego = yes
    client ntlmv2 auth = yes
    encrypt passwords = yes
    restrict anonymous = 2
    log file = /var/log/samba/samba.log
    log level = 2
    map untrusted to domain = yes
[kdrive]
    comment = K Drive
    path = /var/ncdata/ncadmin/files/kdrive/
    valid users = “@EXAMPLE\Domain Admins”
    force group = “Domain Users”
    group = “Domain Users”
    read only = No
    create mask = 0777
    force create mode = 0660
    directory mask = 0777
    directory mode = 0777
    force directory mode = 0770
    hide unreadable = Yes
    access based share enum = Yes

Setting permissions on the folder (which was created in NextCloud as “kdrive” under the user “NCAdmin”)

chmod -R 0770 /var/ncdata/ncadmin/files/kdrive/ (no error)
chgrp -R "Domain Users" /var/ncdata/ncadmin/files/kdrive/ ("chgrp: invalid group: ‘Domain Users’")

So, with all of that copypasted info, (I’m sure I missed some and can add more; just let me know what I’ve missed), does anyone with experience configuring Samba see anything that is preventing me from using the domain users locally in my NextCloud VM? I’ve spent some days trying different combinations of settings, but so far nothing has me able to 1. view domain users in getent, 2. set the permissions for that folder for Domain Users group, 3. access \fs1 via Windows Explorer.

Not an expert on Samba BUT:

If i understand you right, you want the users to mount a folder under ncdata directly in their clients, circumventing the Nextcloud interface?

This will not work since the NC Server is not aware of the changes, and they will not be reflected in the WebGUI or on any sync clients, you would have to rescan the filesystem all the time wich is a bad idea.

What do you want to achieve wich you can not with the integrated LDAP App and their wizard?

My guess is that you are largly overengineering this project, and are missing the simple solution.

Thanks for your reply. The use case is more or less detailed in my post here: Using NextCloud as a LAN file server?

Basically I want to use NextCloud for file versioning, but not require the users to sync individual copies of the data redundantly. The primary access will be over a LAN, mostly from a Windows terminal server, so it wouldn’t make sense to sync the roughly 50GB data store to (starting with) 8 users all on the same server, just so they can access whichever files they need that could otherwise be shared via Samba/CIFS. Per the link above, someone responded saying they had done it this way, and that it has worked better than trying to shoehorn WebDAV into filling the need, (and further indicates that this will work since the NC server is aware of the changes, but I want to test and prove how well this works for myself before I put this into production). That thread was created to ask “how should I accomplish using NC to meet my needs”, where this thread is more for “how do I get Samba on the NC VM working with domain users”.

All that said, you may be right that I’ve “overengineered the project”. Is there a better method for using NC for versioning and letting the users access the files without the need for adding a TB of redundant data to my terminal server? That’s basically what the other thread was created to ask.


Also, after posting this thread yesterday, I was able to find the Samba and LDAP client config pages in Webmin. This all looks like a pretty, webified wrapper to do what I’ve been doing with config files, (which is much nicer to write a guide to managing the setup). This leads me to believe that the things I’m doing were designed to be available from the web GUI with this VM. So as a general update, I haven’t yet found the magic combination that makes this work, but I’ll happily post it for others onceI figure it out, and would be most appreciative if anyone else can point out what I need to improve.

So, here’s the actual technical update. I got into Webmin and under “Un-used Modules” (funny naming since I’ve configured them and they’re more or less usable). I found some nice GUI configurations for “Kerberos5”, “LDAP Client”, “LDAP Users and Groups” and “Samba Windows File Sharing”. I have managed to confirm that I have it configured at least enough to browse the domain and get the list of users and groups (using LDAP Client, LDAP Browser), but only users and groups I’ve moved to the root of the domain and not in subfolders (despite me setting Global search base depth to “Entire subtree” in LDAP Search Bases).

If I go to LDAP Users and Groups I do not see my domain users, but I could “Add a new LDAP user”, and I could potentially add this new user with a UID matching that of the user UID from my domain. Is that then the proper way to make a domain user (or group) available for file/folder permissions for a Windows folder share? Turns out that was not the right way to do this, as it informed me the group existed, although it has been unable to browse and find said group via LDAP Users and Groups. I’m still poking at winbind and samba configs, but nothing else really to report yet.


New day, new opportunity to back the metaphorical truck up and try to ram through the proverbial snowdrift. At some point I found I could no longer even try to log in when opening the folder via Windows Explorer, so I decided that I probably had wrecked the Samba (or other) database; time to blow away the appliance and redeploy from template.

Going through my list of steps, I found that attempting to “bind” via the webui “Samba Windows File Sharing” failed until I modified the entry for fs1 in my DNS server setup, and gave all permissions (but I think I only NEEDED write) to Domain Computers. This resolved an error message that caused bind to fail, despite the domain join being apparently successful using the command “net ads join -U my.username”, although apparently that didn’t affect the “LDAP Users and Groups” telling me that it wasn’t able to bind. Resolved an issue that people might run into there: “cn=administrator,dc=example,dc=local” is NOT the correct syntax; “administrator@example.local” is. Also, WHY is that password field a plain-text entry not secured with asterisks?

So after going through these steps I’m back to what I believe to be my conundrum. On the LDAP Client page, I can click LDAP Browser and I see my test group and my domain account, which I placed into the root of the domain (in Active Directory Users and Groups). I can even browse the ‘folders’ and find other users and groups. But then I click “Validate Configuration” and I get this message (last line happens to be in red):

Finding LDAP base for users ..
.. found base dc=EXAMPLE,dc=LOCAL.
Connecting to LDAP server ..
.. connected to 192.168.88.10

Searching for users ..
.. no users found under base dc=EXAMPLE,dc=LOCAL.

Anyone have any thoughts?

I know this is an old thread but I have a method which has proven to work for authentication to a Samba 4 DC via a Debian 8/9 host to NextCloud.

Basically you need to use the winbind method of joining the host to your domain (haven’t tested with sssd method), and to that regard, this should also work for joining a Debian host to a Windows AD DC.

Steps for joining domain here –
https://www.tecmint.com/join-ubuntu-to-active-directory-domain-member-samba-winbind/

After the host is joined, and you can pull users via “wbinfo -u” and groups via “wbinfo -g”, you need to install the local Unix User backend plug-in.

Unix User Backend–
https://apps.nextcloud.com/apps/user_pwauth

After this, you need to install “pwauth”

sudo apt-get install pwauth

Now you should be able to authenticate through the host’s own bindings to your DC.

A word on Webmin’s Samba package, I would strongly advise to refrain from installing this via the unused modules feature, or all together as I’ve noticed this module causing more harm then helping, however I’ll admit I haven’t tested all the in’s and out’s as to why, but for my experience, upon loading the module, authentication breaks from what worked previous of “pwauth”.

I know the group permissions and other attributes aren’t carried over when integrating via this method vs LDAP/AD, however per having a Linux powered AD DC (samba 4), I’ve had difficulty trying to integrate using LDAP and so I found this method to be a viable alternative.

Hopefully it can be helpful to others.

Edit: per storage methods, when using external storage, I’ve kept it simple by opt’ing for “local” folder mount in Nextcloud, and mounting the actual shares via the system from the fstab with cifs, mounted using the “www-data” uid/gid (33).

example of cifs permissions–
//10.10.0.252/root-folder/sub-folder /mnt/share/ cifs uid=33,gid=33,credentials=/root/.smbcreds,vers=3.0,iocharset=utf8,sec=ntlm 0 0

The above method ensures no permissions conflicts for read/write in Nextcloud, however the end result is having to manage group and share permissions independent of Samba and LDAP.

As of the time of this writing, I can vouch that this works with NextCloud versions 11-15, with Debian 8 and 9 host’s.

  • Cheers

It is an old thread, and I eventually gave up on getting it to work. I went on to find a Univention appliance with NextCloud on it, and it almost works, but not quite, so your information should be helpful. I tried walking through what you described, and I got stuck at installing pwauth (“Unable to locate package pwauth”). I’ll assume it’s just because I’m using a different appliance that’s set up differently.

In my recent experimenting trying to get this to work, I’ve been trying to get Samba to share with local users, although I found that www-data user/group are not an option through the webui. If I read correctly, you are able to manually share with UID/GID 33, and Windows users connecting to CIFS just log in using their NextCloud logins? I was hoping for a way to have users log into NextCloud with their AD/LDAP accounts, but since I’ve gone a year and a half without a full solution, maybe that’s ‘good enough’ for the short term.

Thanks for the info! I’ll hopefully get to poking around with this in my test lab within the next week.