On 07/11/15 23:28, Michael Adam wrote:> Ok, why do you strictly need it? > I understand that it gives you a better feeling, > and it may be convenient but which scenario really > requires it? Most important is the central auth db. > If the IDs on the various DCs and members in the > domain do not have the same sets of unix IDs, then > nevertheless > - local login will work. > - ssh login will work. > - rsync will work if not using --numeric-ids. > - cifs mount will work. >Hi Michael, as I am mid setup of a new test domain, I thought I would try it as you seemed to be suggesting i.e. without using rfc2307 attributes. I have come to the conclusion that by using the latest Samba on the DC with winbindd, you are using something that is very very similar to a samba domain member that uses the 'rid' backend. You can connect a domain member using the 'rid' backend to the DC. You can login to the DC as a domain member You can login to the DC via ssh rsync seems to work. you can mount a share from the DC on a domain member, but unless you explicitly set the users local uid & gid in the mount command, the mount ends up belonging to the uid of the user on the DC. the [homes] share appears to be working again. Using the 'rid' backend, you get a user local group. So, even though what you say is mostly true, I still hold to my belief, the best option would be if all Samba machines could use the full set of RFC2307 attributes. Rowland
On 10/11/15 13:38, Rowland Penny wrote:> On 07/11/15 23:28, Michael Adam wrote: >> Ok, why do you strictly need it? >> I understand that it gives you a better feeling, >> and it may be convenient but which scenario really >> requires it? Most important is the central auth db. >> If the IDs on the various DCs and members in the >> domain do not have the same sets of unix IDs, then >> nevertheless >> - local login will work. >> - ssh login will work. >> - rsync will work if not using --numeric-ids. >> - cifs mount will work. >> > > Hi Michael, as I am mid setup of a new test domain, I thought I would > try it as you seemed to be suggesting i.e. without using rfc2307 > attributes. > I have come to the conclusion that by using the latest Samba on the DC > with winbindd, you are using something that is very very similar to a > samba domain member that uses the 'rid' backend. > > You can connect a domain member using the 'rid' backend to the DC. > You can login to the DC as a domain member > You can login to the DC via ssh > rsync seems to work. > you can mount a share from the DC on a domain member, but unless you > explicitly set the users local uid & gid in the mount command, the > mount ends up belonging to the uid of the user on the DC. > the [homes] share appears to be working again. > Using the 'rid' backend, you get a user local group. > > So, even though what you say is mostly true, I still hold to my > belief, the best option would be if all Samba machines could use the > full set of RFC2307 attributes. > > Rowland >OK Michael, I have now given a user a uidNumber and Domain Users a gidNumber, I have also changed the domain member to use the 'ad' backend. So what's changed? You no longer need the local uid & gid in the mount command. The local user group has gone. Something it didn't mention before, with the rid backend, if you opened the mounted share in Caja (gui file browser), you didn't have full control i.e. you couldn't right click and create an empty file. This now works with the ad backend. So in my opinion, as long as you use the 'ad' backend on domain members, you can use the DC as a fileserver, provided you use a Samba version that uses the separate winbindd deamon. I still wouldn't let users login to the DC and I also don't see any reason to use sssd or nlscd any more. Rowland
On 2015-11-10 at 15:31 +0000, Rowland Penny wrote:> On 10/11/15 13:38, Rowland Penny wrote: > >On 07/11/15 23:28, Michael Adam wrote: > >>Ok, why do you strictly need it? > >>I understand that it gives you a better feeling, > >>and it may be convenient but which scenario really > >>requires it? Most important is the central auth db. > >>If the IDs on the various DCs and members in the > >>domain do not have the same sets of unix IDs, then > >>nevertheless > >>- local login will work. > >>- ssh login will work. > >>- rsync will work if not using --numeric-ids. > >>- cifs mount will work. > >> > > > >Hi Michael, as I am mid setup of a new test domain, I thought I would try > >it as you seemed to be suggesting i.e. without using rfc2307 attributes.Don't get me wrong, I think it would be great to be able to use the rfc2307 attributes on the DC. I just see a bunch of problems at least in environments where much has to be automated. In a smaller setup where everything is pretty much under manual control, this can very well work already today.> >I have come to the conclusion that by using the latest Samba on the DC > >with winbindd, you are using something that is very very similar to a > >samba domain member that uses the 'rid' backend.Well, if you do the default idmap.ldb style (non-rfc2307) mappings in the DC, it is more like the winbindd's tdb idmap backend in nature. (The main similarity to the rid backend lies in the fact that idmap.ldp does 'BOTH' type mappings, but I planned to introduce that for the tdb backend as well (at least optionally for a start).)> >You can connect a domain member using the 'rid' backend to the DC. > >You can login to the DC as a domain member > >You can login to the DC via ssh > >rsync seems to work. > >you can mount a share from the DC on a domain member, but unless you > >explicitly set the users local uid & gid in the mount command, the mount > >ends up belonging to the uid of the user on the DC. > >the [homes] share appears to be working again. > >Using the 'rid' backend, you get a user local group. > > > >So, even though what you say is mostly true, I still hold to my belief, > >the best option would be if all Samba machines could use the full set of > >RFC2307 attributes.> OK Michael, I have now given a user a uidNumber and Domain Users a > gidNumber, I have also changed the domain member to use the 'ad' backend. > So what's changed? > You no longer need the local uid & gid in the mount command. > The local user group has gone. > Something it didn't mention before, with the rid backend, if you opened the > mounted share in Caja (gui file browser), you didn't have full control i.e. > you couldn't right click and create an empty file. This now works with the > ad backend. > > So in my opinion, as long as you use the 'ad' backend on domain members, you > can use the DC as a fileserver, provided you use a Samba version that uses > the separate winbindd deamon. I still wouldn't let users login to the DC and > I also don't see any reason to use sssd or nlscd any more.Thank you very much, Rowland, for sharing this information and status with us! It looks very reassuring. Let's work further to get the remaining rough edges smoothened. It might be interesting for many other users if you could share configuration details of your setup, e.g. on the samba wiki if you like. I'd appreciate that. This could turn into some kind of reference setup. Cheers - Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://lists.samba.org/pipermail/samba/attachments/20151110/055d51d9/signature.sig>