Samba Active Directory or OpenLDAP

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 ->
Nextcloud ->

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:


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.


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:


The share-level password could be a viable solution, but requires some development. I’m not sure it’s worth the effort.

We already have a SMB compliant implementation with user-level authentication based on Active Directory. We provide a Samba Active Directory Domain Controller package. I don’t like to maintain different solutions which address similar requirements… :dizzy_face:


If I may add my $ 0.02…

If you want to offer Microsoft DC like landscape, you can’t escape, Samba 4 is the way to go.
Once this is said, you do have to understand that Samba team, willing to emulate Microsoft domain, is facing exactly same problem (or constraint) that is to rely on “dedicated” LDAP server that can’t be used any more as standard LDAP server.

What do I mean with “std LAP server” ?au

The beauty of LDAP, as a protocol, is also that you can extend and customize LDAP schema depending on your needs. You may decide to use UID as RDN for users entries. You may decide to create different branches for different purposes…
Samba AD-LDAP schema is like AD. Not flexible. But there is no choice.

This means that is you need LDAP for something else that doesn’t natively fits with Windows design, because Samba mimics Windows, it will not fit with Samba neither and solution is to maintain another (standard) LDAP server that can be used, f.i. to deploy you mail service (unless you decide that may is OpenXchange only :stuck_out_tongue_closed_eyes:

Standard LDAP schema can still be update to whatever you want. Of course, if what you want is AD like LDAP, then you are locked again. But if you need Posix (RFC2307) on this LDAP server, then nothing prevent you do to it.
Synchronizing pwd is not easy, inteed, especially if you are in Microsoft world and want to change it from Windows client.
One option is to deploy customized GINA and write in a “Y” mode, or to intercept pwd before it is written on target directory.