Il 09-07-2015 22:01 Rowland Penny ha scritto:> 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.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 usersOK> There are active directory domain usersOK> These cannot be the same usersOK> 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.danti at assyoma.it - info at assyoma.it GPG public key ID: FF5F32A8
Hi Gionatan, 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 2015-07-09 22:25 GMT+02:00 Gionatan Danti <g.danti at assyoma.it>:> Il 09-07-2015 22:01 Rowland Penny ha scritto: > >> 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. >> > > 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.danti at assyoma.it - info at 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 >
Il 10-07-2015 09:48 mathias dufresne ha scritto:> Hi Gionatan, > > 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. >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 :) -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti at assyoma.it - info at assyoma.it GPG public key ID: FF5F32A8