Am 2017-10-09 um 21:57 schrieb Rowland Penny via samba:> On Mon, 9 Oct 2017 21:35:39 +0200 > "Stefan G. Weichinger via samba" <samba at lists.samba.org> wrote: > >> Am 2017-10-09 um 21:04 schrieb Rowland Penny via samba: >> >>> It isn't supposed to work like this and it didn't used to work like >>> this. >> >> Then the software shouldn't allow me to do so and/or give useful >> feedback, don't you agree? > > I don't see how you could be stopped from doing this, when a user or > group first contacts a DC, it is given an 'xidNumber' attribute in > idmap.ldb, containing the next available number in the 3000000' range. > If you decide to give this user or group a uidNumber or gidNumber > attribute, this should be used instead, which is what happens when you > run 'net cache flush'. The problem is, you shouldn't have to run the > 'net' command at all and you didn't used to have to. If we could narrow > it down to when it started not working correctly, it might help.The admin there created a group via RSAT. And that group was not visible/usable on the DM server. Only after that I tried to figure out things on the shell, digging for the group on both servers via getent and wbinfo. Until here there was no decision for a uidNumber or gidNumber. He did not set one via RSAT. Does he have to do that? I then deleted the group via samba-tool and created it again: samba-tool group create gfass --nis-domain=arbeitsgruppe --gid-number=10580 If this is wrong, I am happy to learn how to do that correctly. I understand that running wbinfo --group-info="gfass" is problematic as long as the reported bug isn't fixed, correct? thanks, Stefan
On Tue, 10 Oct 2017 09:19:11 +0200 "Stefan G. Weichinger via samba" <samba at lists.samba.org> wrote:> Am 2017-10-09 um 21:57 schrieb Rowland Penny via samba: > > On Mon, 9 Oct 2017 21:35:39 +0200 > > "Stefan G. Weichinger via samba" <samba at lists.samba.org> wrote: > > > >> Am 2017-10-09 um 21:04 schrieb Rowland Penny via samba: > >> > >>> It isn't supposed to work like this and it didn't used to work > >>> like this. > >> > >> Then the software shouldn't allow me to do so and/or give useful > >> feedback, don't you agree? > > > > I don't see how you could be stopped from doing this, when a user or > > group first contacts a DC, it is given an 'xidNumber' attribute in > > idmap.ldb, containing the next available number in the 3000000' > > range. If you decide to give this user or group a uidNumber or > > gidNumber attribute, this should be used instead, which is what > > happens when you run 'net cache flush'. The problem is, you > > shouldn't have to run the 'net' command at all and you didn't used > > to have to. If we could narrow it down to when it started not > > working correctly, it might help. > > The admin there created a group via RSAT. > And that group was not visible/usable on the DM server.It wouldn't be if the group was created as just a windows group.> > Only after that I tried to figure out things on the shell, digging for > the group on both servers via getent and wbinfo.This would have been futile if the group was just a windows group.> > Until here there was no decision for a uidNumber or gidNumber. > He did not set one via RSAT. Does he have to do that?On a DC, group will be given an xidNumber and if the libnss_winbind links are set up, this will be used, but only on that DC On a Unix domain member, it is different, the xidNumber will not be used, because it isn't available. You have two main options, use the winbind 'rid' backend, with this, provided you use the same smb.conf on all Unix domain members, you will get the required UIDs & GIDs without adding anything to AD. There is a 'gotcha' though, you will have to use the template lines in smb.conf for user shell & home dirs. Your users and groups would also have different IDs on the DC. If you want to have the same IDs everywhere, you will have to use the winbind 'ad' backend and give your users & groups uidNumber and gidNumber attributes, you will also be able to use the other RFC2307 attributes. Whichever winbind backend you use on the Unix domain members, you will also have to set up the libnss_winbind links.> > > I then deleted the group via samba-tool and created it again: > > samba-tool group create gfass --nis-domain=arbeitsgruppe > --gid-number=10580 > > If this is wrong, I am happy to learn how to do that correctly. > > I understand that running > > wbinfo --group-info="gfass" > > is problematic as long as the reported bug isn't fixed, correct?It seems to be, but only on a DC, unless you can prove otherwise ;-) Rowland
Am 2017-10-10 um 09:57 schrieb Rowland Penny via samba:> On Tue, 10 Oct 2017 09:19:11 +0200 > "Stefan G. Weichinger via samba" <samba at lists.samba.org> wrote: >> >> The admin there created a group via RSAT. >> And that group was not visible/usable on the DM server. > > It wouldn't be if the group was created as just a windows group.How to create the group as unix group via RSAT? By adding the gidNumber, right? As asked before: do I have to keep track of the next free gidNumber myself? I assume there is some cool grep to read the highest used xid from LDAP or so ... ?>> Until here there was no decision for a uidNumber or gidNumber. >> He did not set one via RSAT. Does he have to do that? > > On a DC, group will be given an xidNumber and if the libnss_winbind > links are set up, this will be used, but only on that DC > > On a Unix domain member, it is different, the xidNumber will not be > used, because it isn't available. > You have two main options, use the winbind 'rid' backend, with this, > provided you use the same smb.conf on all Unix domain members, you will > get the required UIDs & GIDs without adding anything to AD. > There is a 'gotcha' though, you will have to use the template lines in > smb.conf for user shell & home dirs. Your users and groups would also > have different IDs on the DC. > If you want to have the same IDs everywhere, you will have to use the > winbind 'ad' backend and give your users & groups uidNumber and > gidNumber attributes, you will also be able to use the other RFC2307 > attributes. > > Whichever winbind backend you use on the Unix domain members, you will > also have to set up the libnss_winbind links.OK, I think I understand. We use backend "ad" on the DM and the DM has /usr/lib64/libnss_winbind.so* and # grep winbind /etc/nsswitch.conf passwd: compat winbind group: compat winbind This is what you point me at, right?>> wbinfo --group-info="gfass" >> >> is problematic as long as the reported bug isn't fixed, correct? > > It seems to be, but only on a DC, unless you can prove otherwise ;-)I won't touch things for now ;-) thanks, Stefan