Samba Active Directory or OpenLDAP

Hi Guys!

Now a quite naive question, do not laugh …

I use the NS as a home server with the following options:
A) File server
B) eMail server (Sogo with CalDAV and CardDav)
C) virtual web server
D) VPN
E) nextcloud

As a client are used tablet with Android, Smartphone, Netbook and Linux computer.

I use no Windows computer, what makes more sense then:

Samba Active Directory or OpenLDAP

What would be the advantages / disadvantages for me?

I would be grateful for simple understandable meaningful help.

Many greetings from the rainy Hallertau - the heart of Bavaria!
Gerald

1 Like

This is the game changer feature:

  • if you need authenticated access to shared folder, you must go with Active Directory
  • if guest access without password is enough, go with OpenLdap
4 Likes

Okay, thats a pity

I already need a dedicated access to individual directories.

Thank you!

Running Samba with an external LDAP backend will not be possible?
Or too much effort, since you have to maintain two user backends …

Sorry but it’s not possible: LDAP doesn’t have samba schema anymore :frowning:

OK, then not - a pity

What is your concern with using Samba for user authentication? Are you afraid for needed resources?

1 Like

The resources are relatively unimportant for my servers, but I find the configuration with openldap more pleasant, or partially easier to understand.

You can say that samba is the same, but not quite the same.

This the point! Things evolved since Samba version 4. They developed their native LDAP backend. We just follow their rules.

Maybe there’s no need for the File server module at all. Just install NextCloud for your smart devices. None of them uses the SMB protocol natively!

1 Like

The troubles are more on the developer side, than in the user’s one…I hope :slight_smile:

In fact now If I want to authenticate an app from ldap, whatever ldap or samba4, I need to test it and following what is installed, propose the good schema.

if ($sssd->isLdap()) {
...
} elsif ($sssd->isAD()) {

for example :
SOGo → nethserver-sogo/root/etc/e-smith/templates/etc/sogo/sogo.conf/45user_source at master · NethServer/nethserver-sogo · GitHub
Nextcloud → nethserver-nextcloud/root/etc/e-smith/events/actions/nethserver-nextcloud-occ-conf at master · NethServer/nethserver-nextcloud · GitHub

After this, I don’t know so much more, never tested yet.

Whoah, I haven’t tested the ldap module, I had no idea this was the case, good to know because I have no use case for the ldap auth module then.

If you have a mail server, or a firewall, without file server, openldap is much simpler and it’s the way to go! :smiley:

2 Likes

IIUC, every app usually ldap based must/could be rebased on AD ldap, right? is it something directly supported by S4 Ldap?

No, I think. The LDAP schema are very different!

so, having AD and ldap both on the same machine is a must? what about account syncing?

Nope, you can install either AD or OpenLDAP!

See above:

I do not know if it creates problems.

In my test server with OpenLDAP I bypassed the problem by creating specific users for samba shares

From linux shell:

useradd user_name
passwd user_name
smbpasswd -a user_name

where “user_name” is the user (and password) to use for samba shares

I created a shared folder “myfolder” from the web interface

From Linux shell I assigned the rights to the user user_name:

cd /var/lib/nethserver/ibay/
chown user_name: user_name myfolder -R

From the web interface I restarted Samba service

And now in myfolder folder only accesses the user samba “user_name”

It is a test server.
This can create problems?

1 Like

well, you’re going totally off of NS’ usual path :slight_smile:

Surely :joy: !! And do not recommend to do that than on test servers

I’v been tinkering with this and more to understand why it’s not possible added the samba schema anyway. Could not get it to work, I think hit this brick wall:

network (windows) username= user1
ldap (uid) username = user1 with uidnumber = 1000
(posix)usernumber 1000 > through SSSD/nsswitch = user1@domain

Stopped tinkering after reading this, however

Making local accounts outside Ldap does not appeal to me. But i’ll consider (mis)using this suggestion by creating “password protected” shares by introducing a (local) account (username = sharename) for each protected share.

2 Likes

The problem is not really adding back the Samba schema, but maintaining all the code needed to synchronize Samba and standard LDAP attributes (we deleted almost 2K lines of code!).
One of the main problems is to have password in sync, since Samba requires a different hash format.

Also, we need Samba fully integrated with AD, and this the only available path.
The solution suggested by @enzoturri works indeed, but it’s hard to maintain and normally admins want only one list of users :slight_smile:

2 Likes