My system: CentOS 6.6 w/Samba 3.6, connected to an AD Domain through
Winbind.
When creating a local user, I always first create a Unix user with
passwd and then I use smbpasswd -a <unixuser> to establish the mapping
between the tdbsam database and the local /etc/passwd file.
I wonder if, using the tdbsam in conjunction with winbind, the local
unix user (stored in /etc/passwd) creation can be bypassed. After all,
it's winbind's role to map "virtual" user to real unix ID.
So, my question is: there is a method to create a "virtual" user, only
stored inside the tdbsam database, without touching the real unix local
users (stored inside /etc/passwd).
Thank you all.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.d...@assyoma.it - in...@assyoma.it
GPG public key ID: FF5F32A8
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
A bit lost here, if you are using samba as an AD client, you cannot have
a local user with the same name as an AD user. Users are either 'local'
or 'domain', I do not really understand your concept of a 'virtual' user.
Rowland
Am 09.07.2015 um 10:05 schrieb Gionatan Danti:
> When creating a local user, I always first create a Unix user with
> passwd and then I use smbpasswd -a <unixuser> to establish the mapping
> between the tdbsam database and the local /etc/passwd file.
>
> I wonder if, using the tdbsam in conjunction with winbind, the local
> unix user (stored in /etc/passwd) creation can be bypassed. After all,
> it's winbind's role to map "virtual" user to real unix ID.
>
> So, my question is: there is a method to create a "virtual" user, only
> stored inside the tdbsam database, without touching the real unix local
> users (stored inside /etc/passwd).
If you really want to create a _local_ user on your member server, the
account must exist local. For _domain_ users, you don't need a local
account.
Regards,
Marc
Ok,
so here the "local" word must be taken seriously: it _really_ had to
exists locally.
Thanks for confirmation.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.d...@assyoma.it - in...@assyoma.it
GPG public key ID: FF5F32A8
--
In short: while my samba server is connected to the AD domain, I would
also like to have some local (non domain) user for other tasks.
It is my understanding that for a local samba user I _need_ to create
the relative unix user (using useradd) and then use the samba-provided
tool smbpasswd. I simply wonder if it is possible to create local users
using _only_ smbpasswd (or equivalent), without messing with the real
local unix user table stored in "/etc/passwd" (hence the world "virtual).
Regards.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.d...@assyoma.it - in...@assyoma.it
GPG public key ID: FF5F32A8
--
Hi,
I perfectly understand your reasons.
My question stems from the fact that, while connected to an AD domain,
samba (or better, winbind) is impersonating remote users without
problems. This is done using the "winbind" keyword in /etc/nsswitch.conf
So, I wonder if winbind is capable of doing something similar with
tdbsam users, impersonating them _without_ a local entry in /etc/passwd.
Basically, what I want is to tell samba/winbind "do the same thing you
are doing for AD, but using tdbsam as backend".
While I suspected that it is not possible, I liked a direct confirmation
from the list...
Thanks.
No, with an AD domain, a local user is just that, a local user, you *do
not* add them to AD, so if you require local users, just add them with
'useradd', do nothing else.
There are *no* local samba users with AD.
Rowland
What you have to understand is that, when a machine is part of a domain,
you can have local users that authenticate
via /etc/passwd, but these local users are unknown to the domain. You
also have domain users that can be made known to the local system.
>
> So, I wonder if winbind is capable of doing something similar with
> tdbsam users, impersonating them _without_ a local entry in
> /etc/passwd. Basically, what I want is to tell samba/winbind "do the
> same thing you are doing for AD, but using tdbsam as backend".
You can have users in /etc/passwd or AD, you cannot have the same user
in both, or anywhere else. A local user cannot connect to anything but
local directories and then only if they have the required permissions set.
Rowland
>
>
> While I suspected that it is not possible, I liked a direct
> confirmation from the list...
>
> Thanks.
>
--
Regards
Davor
-- Skickat från mobilusken! --
----- Ursprungligt meddelande -----
Från: "Rowland Penny" <rowlandpe...@gmail.com>
Skickat: 2015-07-09 14:07
Till: "sa...@lists.samba.org" <sa...@lists.samba.org>
Ämne: Re: [Samba] Samba local user without /etc/passwd
Uhm, I think there is an misunderstanding here, possibly due to my bad
english.
1) I 100% agree that local users are, well, local users. So the domain
does not know anything about that users (how it could?)
2) I 100% agree that domain users are _remote_ users, that don't need to
exists on the local machine.
3) What I am wondering is if, domain take aside, I can create a local
user _only inside the tdbsam database_, without touching the /etc/passwd
file at all. Basically, I would like to have "samba-private" users,
without messing with the real Linux users. I understand that this pose a
permission problems - after all, samba runs with user's credential.
However, I wonder if something like windbind can solve these issues.
To tell it with a graph, it would be nice if, issuing a "getent user"
command, the system:
- using the nsswitch, asks winbind (or something similar) to find the
user;
- winbind (or the likes) search the tdbsam database and return a UID/GID
values (similar to how domain users works)
- files/ACL can be then matched against the windbind (or the likes)
assigned UID/GID, even without a real backing Unix user.
Sorry if it seems a strange question, I'm only trying to understand
here.
Regards.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.d...@assyoma.it - in...@assyoma.it
GPG public key ID: FF5F32A8
--
I will say it again but in slightly different words: there are no
'remote' users, there are local Unix users and there are domain users,
local users can only connect to directories and files on the local
computer. Domain users can connect to directories and files on any
domain computer that is set up with the correct permissions.
So:
There are local users
There are active directory domain users
These cannot be the same users
There is no where else to store user info except in either /etc/passwd
(which makes them local users) or in AD (which makes them active
directory domain users).
Rowland
Let's forget about the domain part. I included it trying to better
explain my thought, but let forget about it for the moment.
> So:
> There are local users
OK
> There are active directory domain users
OK
> These cannot be the same users
OK
> There is no where else to store user info except in either /etc/passwd
> (which makes them local users) or in AD (which makes them active
> directory domain users).
This is the one that let me a bit perplexed. The tdbsam-backed accout
can store _any_ required information (eg: username, password, full name,
etc). After all, using pdbedit we can see (and edit) all of them. So I
imagined that perhaps it was possible to store users directly inside the
tdb database, and nothing more.
Well, it seems I was wrong ;)
Thank you all.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.d...@assyoma.it - in...@assyoma.it
GPG public key ID: FF5F32A8
--
You can have user only declared into tdb at least when samba is acting as
domain controller. In that case this user become also a system user as
domain users purpose is to be system users, also used for file sharing.
Now if you have a Samba acting as file server and only file server,
retrieving its system users from winbind and /etc/passwd you can use any of
these users to add them into this samba's tdb as samba users for they can
access to file shared by this samba server.
The point is there are two kind of users: Samba users to access shares and
system users to access files. Samba must be able to to translate its own
users into system users.
Samba users are used to access Samba shares and system users are used to
access files and directory, this because file system are part of system
layer.
What you speak about make me think about pureftpd virtual users. With
pureftpd you can declare a user "toto" as pureftpd user and associate this
"toto" user to any other system user (declared in /etc/passwd, some ldap
tree, AD or anything you can imagine). But the process is the same:
pureftpd authenticate remote user then use system user to access files,
then the system decide if this user can access or not to the files...
Cheers,
mathias
OK, this part was missing from my head ;)
So what I asked is possibile _only_ when Samba _is_ the domain
controller.
Maybe this is obvious, but I was missing it...
>
> Now if you have a Samba acting as file server and only file server,
> retrieving its system users from winbind and /etc/passwd you can use
> any of these users to add them into this samba's tdb as samba users
> for they can access to file shared by this samba server.
>
> The point is there are two kind of users: Samba users to access shares
> and system users to access files. Samba must be able to to translate
> its own users into system users.
> Samba users are used to access Samba shares and system users are used
> to access files and directory, this because file system are part of
> system layer.
>
Sure. What I was asking myself was "does it exists a method/binary which
integrate within nsswitch "a-la-winbind" to provide username enumeration
and translation, only looking inside the tdb files without requiring
/etc/passwd?"
Your comment above basically replied to my question, thanks.
> What you speak about make me think about pureftpd virtual users. With
> pureftpd you can declare a user "toto" as pureftpd user and associate
> this "toto" user to any other system user (declared in /etc/passwd,
> some ldap tree, AD or anything you can imagine). But the process is
> the same: pureftpd authenticate remote user then use system user to
> access files, then the system decide if this user can access or not to
> the files...
>
> Cheers,
>
> mathias
>
Ok, all clear now.
Mathias, Rowland... thanks for your reply... and for your patience :)