Matthias Leopold
2025-Sep-02 09:57 UTC
[Samba] [EXTERN] Re: Multiple concurrent user databases?
Am 02.09.25 um 10:50 schrieb Rowland Penny via samba:> On Tue, 2 Sep 2025 10:12:27 +0200 > Matthias Leopold via samba <samba at lists.samba.org> wrote: > >> Hi, >> >> I joined a Samba server to an AD domain that was previously used with >> local user database (passdb backend = tdbsam). >> To my surprise I saw that "old" local users can still login alongside >> the new domain users. My firm conviction was that this behaviour is >> impossible, that only one user database could be used at a time. >> Apparently I never tested this. Is this standard behaviour? Can I >> explicitly disable the local user database? >> >> thanks >> Matthias >> > > It depends on what you mean by local users. If you were running Samba > as a standalone server, then the 'Samba' users required a 'local' Unix > user in /etc/passwd and they will still exist after you joined the > client to the domain and they will still be able to login locally. Any > username that is in /etc/passwd will normally take local precedence > over the same username in AD. > > The fix ? Remove any users in /etc/passwd that should only be in AD. > > Rowland > >Thank you. In a similar discussion we had in 2018 I asked about "concurrent" use of tdbsam and ldapsam which is not possible. With this in mind I was surprised by what I found now with AD members. https://lists.samba.org/archive/samba/2018-August/217726.html Matthias
Ralph Boehme
2025-Sep-02 10:05 UTC
[Samba] [EXTERN] Re: Multiple concurrent user databases?
On 9/2/25 11:57 AM, Matthias Leopold via samba wrote:> Thank you. In a similar discussion we had in 2018 I asked about > "concurrent" use of tdbsam and ldapsam which is not possible. With this > in mind I was surprised by what I found now with AD members.both tdbsam and ldapsam are a *SAM*, the local user database and you can only have a single local SAM hence you can't have both tdbsam and ldapsam at the same time. Whilst ldapsam stores the database on a possibly remote LDAP server, it is still the local SAM. ldapsam was typcially used on an NT4 DC to *export* the *local* SAM in a sense, that other servers could query it for users and use it for authentication. Every Windows system and also Samba *always* has a local SAM, it is just likely not used much when connected to an external SAM, NT4 or AD. Makes sense? :) Cheers! -slow -- SerNet Samba Team Lead https://sernet.de/ Samba Team Member https://samba.org/ Samba Support and Dev https://samba.plus/services/ SAMBA+ packages https://samba.plus/products/samba -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20250902/56384aaf/OpenPGP_signature.sig>
Rowland Penny
2025-Sep-02 10:38 UTC
[Samba] [EXTERN] Re: Multiple concurrent user databases?
On Tue, 2 Sep 2025 11:57:45 +0200 Matthias Leopold via samba <samba at lists.samba.org> wrote:> > > Am 02.09.25 um 10:50 schrieb Rowland Penny via samba: > > On Tue, 2 Sep 2025 10:12:27 +0200 > > Matthias Leopold via samba <samba at lists.samba.org> wrote: > > > >> Hi, > >> > >> I joined a Samba server to an AD domain that was previously used > >> with local user database (passdb backend = tdbsam). > >> To my surprise I saw that "old" local users can still login > >> alongside the new domain users. My firm conviction was that this > >> behaviour is impossible, that only one user database could be used > >> at a time. Apparently I never tested this. Is this standard > >> behaviour? Can I explicitly disable the local user database? > >> > >> thanks > >> Matthias > >> > > > > It depends on what you mean by local users. If you were running > > Samba as a standalone server, then the 'Samba' users required a > > 'local' Unix user in /etc/passwd and they will still exist after > > you joined the client to the domain and they will still be able to > > login locally. Any username that is in /etc/passwd will normally > > take local precedence over the same username in AD. > > > > The fix ? Remove any users in /etc/passwd that should only be in AD. > > > > Rowland > > > > > > Thank you. In a similar discussion we had in 2018 I asked about > "concurrent" use of tdbsam and ldapsam which is not possible. With > this in mind I was surprised by what I found now with AD members. > > https://lists.samba.org/archive/samba/2018-August/217726.html > > Matthias >That was from seven years ago, your memory is better than mine ;-) Lets take a user called 'fred', if this user is a Unix user, then they will appear in /etc/passwd, with a line similar to this: fred:x:1001:100::/home/fred:/bin/sh If you then bring Samba into the mix, then on a standalone server, the smbd deamon maps the user to a Samba user, but only if you have run (as root): smbpasswd -a fred Samba at this point stores the Samba user in the tdbsam database. Nowadays, you only need to run the smbd deamon on a standalone server, nmbd isn't required (no NetBIOS) and winbind is only required for a domain joined machine The user 'fred' connects to a share on the Samba machine, smbd authenticates the user and allows access, at which point it is the Unix permissions that decides what the user can and cannot do. If the user logs in locally (Samba is not involved), then it is as the local Unix user. Now if the machine is joined to an AD domain, then it changes, you need a different smb.conf and you also need to run the winbindd deamon, still no need for the nmbd deamon. At this point, you need to ensure that all users you need to connect to Samba are in AD and AD only, if you leave them in /etc/passwd , strange things will happen. If you examine /etc/nsswitch.conf , you will find a line similar to this: passwd: files winbind NOTE: It may be different on your machine 'files' may be 'compat', but it means the same thing, when looking for a user, look in /etc/passwd first and then (if the user is not found) look in AD. So, if you leave fred in /etc/passwd and there is an AD user also called fred in AD, that AD user will never be used locally, it will always be the local Unix user 'fred' that is used. If you remove 'fred' from /etc/passwd, then, provided the smb.conf is setup correctly, winbind will map the AD user 'fred' to a local Unix user. For instance, I use the 'rid' idmap config backend and I am not in /etc/passwd: rowland at devstation:~$ grep 'rowland' /etc/passwd rowland at devstation:~$ As you can see, nothing is returned by grep, but, I am a local Unix user rowland at devstation:~$ getent passwd rowland rowland:*:11104:10513:Rowland Penny:/home/rowland:/bin/bash Hopes this helps. Rowland Lets take a user called 'fred', if this user is a Unix user, then they will appear in /etc/passwd, with a line similar to this: fred:x:1001:100::/home/fred:/bin/sh If you then bring Samba into the mix, then on a standalone server, the smbd deamon maps the user to a Samba user, but only if you have run (as root): smbpasswd -a fred Samba at this point stores the Samba user in the tdbsam database. Nowadays, you only need to run the smbd deamon on a standalone server, nmbd isn't required (no NetBIOS) and winbind is only required for a domain joined machine The user 'fred' connects to a share on the Samba machine, smbd authenticates the user and allows access, at which point it is the Unix permissions that decides what the user can and cannot do. If the user logs in locally (Samba is not involved), then it is as the local Unix user. Now if the machine is joined to an AD domain, then it changes, you need a different smb.conf and you also need to run the winbindd deamon, still no need for the nmbd deamon. At this point, you need to ensure that all users you need to connect to Samba are in AD and AD only, if you leave them in /etc/passwd , strange things will happen. If you examine /etc/nsswitch.conf , you will find a line similar to this: passwd: files winbind NOTE: It may be different on your machine 'files' may be 'compat', but it means the same thing, when looking for a user, look in /etc/passwd first and then (if the user is not found) look in AD. So, if you leave fred in /etc/passwd and there is an AD user also called fred in AD, that AD user will never be used locally, it will always be the local Unix user 'fred' that is used. If you remove 'fred' from /etc/passwd, then, provided the smb.conf is setup correctly, winbind will map the AD user 'fred' to a local Unix user. For instance, I use the 'rid' idmap config backend and I am not in /etc/passwd: rowland at devstation:~$ grep 'rowland' /etc/passwd rowland at devstation:~$ As you can see, nothing is returned by grep, but, I am a local Unix user rowland at devstation:~$ getent passwd rowland rowland:*:11104:10513:Rowland Penny:/home/rowland:/bin/bash