[Samba] Multiple Standalone Servers With Single LDAP Server

[Danilo Mussolini]

Hi guys,

Well, despite the fact I work with Samba for years, I'm not that expert
when talking about AD/DC. But, I would like to share my experience as I
have exactly the same environment as Gordan would like to have.

In this facility, I have a mixed SO environment, involving Mac, Windows and
Linux (about 100 workstations in total). These clients need to access files
from 5 fileservers. So, as Gordon, I had no reasons to have a domain
controller, the only thing I needed was a centralised authentication system
so I could create a user in one location (database) and this user would be
capable of authenticate to any of those servers (if allowed).

So then, I built a LDAP server and filled the database creating users and
groups using GOsa (web interface frontend), and got the standalone Samba
servers authenticating users from this databases. After this setup
everything was working fine until I had some group issues that made me ask
some questions in this list, and here I was noticed that this is not a
recommended setup for Samba servers and this would cause me some problems.
The fact is,  I solved the group issue recreating this specific group and
nowadays, I use this LDAP database not only to authenticate Samba users,
but also for a webserver and those standalone servers are AFP servers
(Netatalk) as well which also uses the LDAP users to authenticate.

In resume, I have 5 standalone Samba/AFP servers using a centralised LDAP
database to authenticate users. When I have to create/modify a user, I just
go to the LDAP GOsa frontend and make the modifications easily so then the
user can or can't access determining files and folders in the servers. The
reason I also use AFP is that Mac clients are incredibly faster using this
protocol than Samba.


I hope this can help someone and sorry if wasn't clear in some point. Any
thoughts are welcome.


Best,





On Thu, Aug 7, 2014 at 9:46 AM, Gaiseric Vandal <gaiseric.vandal at gmail.com>
wrote:

> On 08/06/14 18:09, Gordan Bobic wrote:
>
>> On 08/06/2014 10:54 AM, Rowland Penny wrote:
>>
>>> On 06/08/14 10:31, Gordan Bobic wrote:
>>>
>>>> On 2014-08-06 10:05, Rowland Penny wrote:
>>>>
>>>>> On 04/08/14 16:45, Gordan Bobic wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm trying to set up multiple standalone Samba servers that use the
>>>>>> same OpenLDAP back-end database for authentication, but on any
>>>>>> servers beyond the first one I cannot seem to get past the error
>>>>>> like the following:
>>>>>>
>>>>>> "The primary group domain sid($SecondaryServerSID) does not match
>>>>>> the domain sid($PrimaryServerSID) for $UserName($UserSID)"
>>>>>>
>>>>>> It seems nuts to have to set up a domain controller just to have
>>>>>> multiple standalone servers within the same workgroup.
>>>>>>
>>>>>> If I configure the secondary server to use a local user password
>>>>>> database for authentication, everything works fine, but that means
>>>>>> having to maintain the database in multiple locations.
>>>>>>
>>>>>> Is there a way to completely neuter all the domain functionality and
>>>>>> use LDAP _only_ for username/password authentication from multiple
>>>>>> standalone servers within the same workgroup?
>>>>>>
>>>>>> Gordan
>>>>>>
>>>>>
>>>>> Short answer, NO
>>>>>
>>>>> Long answer, in this instance, samba is working just like a windows
>>>>> workgroup, you can have lots of windows machines in the same
>>>>> workgroup, but you have to create any users & groups that you want to
>>>>> connect to a machine on that machine AND any others that you want the
>>>>> users or groups to connect to. Once you get past 10 or 12 machines
>>>>> this gets complicated and hard to keep track of, this is why domains
>>>>> were created. Now that you know this, can you see why what you are
>>>>> trying to do with samba will not work.
>>>>>
>>>>
>>>> Now that I know this I still absolutely DO NOT see why what I am
>>>> trying to do with samba will not work. If it is capable of using
>>>> a local user authentication database, I see no reason why the
>>>> authentication mechanism cannot use some kind of a centralised
>>>> username/password verification database.
>>>>
>>>> Setting up a domain on top seems like an entirely needless complication.
>>>>
>>>> If LDAP can be used to authenticate to a single Samba server
>>>> in a workgroup, I see no reason at all why this would necessitate
>>>> existence of a domain to perform the same authentication to additional
>>>> Samba servers in the same workgroup.
>>>>
>>>> Gordan
>>>>
>>> when you set up each 'standalone' server (I would have thought the name
>>> would have given you a hint) it gets its own SID, this is just like a
>>> standalone windows machine. Your machines need to have the same SID,
>>> this is what happens in a domain i.e. SID
>>> S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxx is not the same as
>>> S-1-5-21-yyyyyyyyyy-yyyyyyyyyy-yyyyyyyy. A user created on one machine
>>> cannot connect to another machine unless the user also exists on that
>>> machine. If you want to use a central database, you are going to have to
>>>
>>> use a domain, if microsoft could have got it working your way, they
>>> would have and not spent all the money on creating domains!
>>>
>>
>> Right, OK. So is there a reason why I cannot do one of the following:
>>
>> 1) Make both servers have the same SID without a PDC
>>
>> 2) Have two sambaSID entries for the user in LDAP, each with a different
>> machine SID part, but the same UID suffix and only one password entry
>>
>> ?
>>
>> Gordan
>>
>
> You should be able to run "net getlocalsid" on the first machine, then run
> "net setlocalsid /sidfrom1stmachine/"  on the other machines.       But how
> do you machine accounts on any Windows computers and will be clients of
> these machines?
>
> I am pretty sure you can not have 2 sambaSID entries per user-  how would
> each server know which entry to use?
>
>
> I don't understand the your goal in not using a domain model.
>
>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>