2015-06-30 12:42 GMT+02:00 Rowland Penny <rowlandpenny241155 at gmail.com>:> On 30/06/15 11:17, mathias dufresne wrote: > >> @Andrew: I expect these lines came from RDP issue workaround which should >> be happening with previous Samba version. I removed all these lines as >> now, >> with 4.2.2 Samba version RDP and RSAT are working well without them. >> >> I removed also each and every idmap lines, commented most of winbind lines >> too and now my smb.conf is: >> ------------------------------------------------------------ >> [global] >> workgroup = AD.DOMAIN >> realm = ad.domain.tld >> netbios name = DC01 >> server role = active directory domain controller >> >> dns forwarder = 10.0.0.240 >> >> wins support = yes >> winbind nss info = rfc2307 >> > > The 'winbind nss info = rfc2307' line should be 'idmap_ldb:use rfc2307 > yes' on a DC >I checked on some other DC and even using 'idmap_ldb:use rfc2307 = yes' behaviour of wbinfo and getent are the same.> > >> [netlogon] >> path = /var/lib/samba/sysvol/ad.domain.tld/scripts >> read only = No >> >> [sysvol] >> path = /var/lib/samba/sysvol >> read only = No >> ------------------------------------------------------------ >> >> There is still something I don't understand: >> "wbinfo -i some.user" does not show configured homeDirectory nor >> loginShell >> nor for gidNumber >> For loginShell it displays "/bin/false" rather than configured "/bin/bash" >> For homeDirectory it displays "/home/AD.DOMAIN/some.user" rather >> configured >> "/home/some.user" >> For gidNumber it displays "100" rather than content of "gidNumber". >> > > This is one of the reasons why it is not recommended to use a DC as a > fileserver, whilst from version 4.2.0, samba uses the same 'winbindd' > daemon as on a member server, it still doesn't use all its capabilities. > You can set 'template homedir' and 'template shell' in smb.conf, see 'man > smb.conf, but note these will affect *all* users, you cannot set individual > user homedir paths and shells. > To get the users 'gidNumber' attribute shown by 'getent' etc , you need to > ensure that 'Domain Users' has a 'gidNumber' attribute. >I discovered these option this weekend but as you say, all users are impacted. As users are a bit numerous (120 000) and I'm only there to design the solution, I have no real idea about how they would use this AD, meaning I can't push to use them as they would lose configuration granularity.> > >> SSSD can easily be configured on non-DC to replace winbind and it gives >> possibility to configure which LDB attributes are retrieved. >> On DC I'm still facing incompatibility between Sernet's Samba and SSSD >> package (on Centos 6 & 7 and Debian 8) so initially I planned to use >> winbind in nsswitch.conf and pam.d/* on DC to be able to check ACLs on >> sysvol folder but the fact using winbind all users have "Domain users" as >> primary group seems to me an issue to agree with that solution... >> > > This is yet another reason not to use a DC as a fileserver. The 'Domain > users' problem can be fixed, but it can cause more problems than what it > fixes, because to change the users primaryGroupID attribute means removing > the user from the 'Domain Users' group and windows expects all users to be > a member of 'Domain Users'. > > As far I understand wbinfo fill user's primary group according to >> "primaryGroup" value. >> >> Is there a way to configure winbind to fill user's primary group using >> "gidNumber" rather than "primaryGroup"? >> > > On a DC, no. On a member server this is not a problem. >No issue on system using SSSD as it comes with options to force usage of specific LDB attributes to fill getent answers (using sssd-ldap options as "ldap_user_shell = loginShell" even when using sssd-ad as SSSD engine, how long this would be possible, no idea). Why not insert into winbindd client such options? (ok the answer could be: because there is other work to be done first :) Best regards, mathias> Rowland > > Cheers, >> >> mathias >> >> >> 2015-06-29 11:18 GMT+02:00 Andrew Bartlett <abartlet at samba.org>: >> >> On Thu, 2015-06-25 at 16:27 +0200, mathias dufresne wrote: >>> >>>> Hi all, >>>> >>>> I'm wondering about winbind[d] behaviour. >>>> I tried the following with: >>>> auth methods = sam winbindd >>>> and the same with only one d: >>>> auth methods = sam winbind >>>> >>> Please never set these manually. >>> >>> There are almost no situations where these need to be manually managed, >>> the defaults based on the server role will behave correctly and as >>> expected. >>> >>> Thanks, >>> >>> Andrew Bartlett >>> >>> -- >>> Andrew Bartlett http://samba.org/~abartlet/ >>> Authentication Developer, Samba Team http://samba.org >>> Samba Developer, Catalyst IT >>> http://catalyst.net.nz/services/samba >>> >>> >>> >>> > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >
On 30/06/15 12:51, mathias dufresne wrote:> 2015-06-30 12:42 GMT+02:00 Rowland Penny <rowlandpenny241155 at gmail.com>: > >> On 30/06/15 11:17, mathias dufresne wrote: >> >>> @Andrew: I expect these lines came from RDP issue workaround which should >>> be happening with previous Samba version. I removed all these lines as >>> now, >>> with 4.2.2 Samba version RDP and RSAT are working well without them. >>> >>> I removed also each and every idmap lines, commented most of winbind lines >>> too and now my smb.conf is: >>> ------------------------------------------------------------ >>> [global] >>> workgroup = AD.DOMAIN >>> realm = ad.domain.tld >>> netbios name = DC01 >>> server role = active directory domain controller >>> >>> dns forwarder = 10.0.0.240 >>> >>> wins support = yes >>> winbind nss info = rfc2307 >>> >> The 'winbind nss info = rfc2307' line should be 'idmap_ldb:use rfc2307 >> yes' on a DC >> > I checked on some other DC and even using 'idmap_ldb:use rfc2307 = yes' > behaviour of wbinfo and getent are the same. > > >> >>> [netlogon] >>> path = /var/lib/samba/sysvol/ad.domain.tld/scripts >>> read only = No >>> >>> [sysvol] >>> path = /var/lib/samba/sysvol >>> read only = No >>> ------------------------------------------------------------ >>> >>> There is still something I don't understand: >>> "wbinfo -i some.user" does not show configured homeDirectory nor >>> loginShell >>> nor for gidNumber >>> For loginShell it displays "/bin/false" rather than configured "/bin/bash" >>> For homeDirectory it displays "/home/AD.DOMAIN/some.user" rather >>> configured >>> "/home/some.user" >>> For gidNumber it displays "100" rather than content of "gidNumber". >>> >> This is one of the reasons why it is not recommended to use a DC as a >> fileserver, whilst from version 4.2.0, samba uses the same 'winbindd' >> daemon as on a member server, it still doesn't use all its capabilities. >> You can set 'template homedir' and 'template shell' in smb.conf, see 'man >> smb.conf, but note these will affect *all* users, you cannot set individual >> user homedir paths and shells. >> To get the users 'gidNumber' attribute shown by 'getent' etc , you need to >> ensure that 'Domain Users' has a 'gidNumber' attribute. >> > I discovered these option this weekend but as you say, all users are > impacted. As users are a bit numerous (120 000) and I'm only there to > design the solution, I have no real idea about how they would use this AD, > meaning I can't push to use them as they would lose configuration > granularity. > > >> >>> SSSD can easily be configured on non-DC to replace winbind and it gives >>> possibility to configure which LDB attributes are retrieved. >>> On DC I'm still facing incompatibility between Sernet's Samba and SSSD >>> package (on Centos 6 & 7 and Debian 8) so initially I planned to use >>> winbind in nsswitch.conf and pam.d/* on DC to be able to check ACLs on >>> sysvol folder but the fact using winbind all users have "Domain users" as >>> primary group seems to me an issue to agree with that solution... >>> >> This is yet another reason not to use a DC as a fileserver. The 'Domain >> users' problem can be fixed, but it can cause more problems than what it >> fixes, because to change the users primaryGroupID attribute means removing >> the user from the 'Domain Users' group and windows expects all users to be >> a member of 'Domain Users'. >> >> As far I understand wbinfo fill user's primary group according to >>> "primaryGroup" value. >>> >>> Is there a way to configure winbind to fill user's primary group using >>> "gidNumber" rather than "primaryGroup"? >>> >> On a DC, no. On a member server this is not a problem. >> > No issue on system using SSSD as it comes with options to force usage of > specific LDB attributes to fill getent answers (using sssd-ldap options as > "ldap_user_shell = loginShell" even when using sssd-ad as SSSD engine, how > long this would be possible, no idea).This is doing the same as 'template shell = loginShell'> > Why not insert into winbindd client such options? (ok the answer could be: > because there is other work to be done first :)You got it in one :-) Are there any Unix clients, or are they all windows clients, if the latter then it shouldn't be a problem, only Unix clients need the RFC2307 attributes. Rowland> Best regards, > > mathias > > >> Rowland >> >> Cheers, >>> mathias >>> >>> >>> 2015-06-29 11:18 GMT+02:00 Andrew Bartlett <abartlet at samba.org>: >>> >>> On Thu, 2015-06-25 at 16:27 +0200, mathias dufresne wrote: >>>>> Hi all, >>>>> >>>>> I'm wondering about winbind[d] behaviour. >>>>> I tried the following with: >>>>> auth methods = sam winbindd >>>>> and the same with only one d: >>>>> auth methods = sam winbind >>>>> >>>> Please never set these manually. >>>> >>>> There are almost no situations where these need to be manually managed, >>>> the defaults based on the server role will behave correctly and as >>>> expected. >>>> >>>> Thanks, >>>> >>>> Andrew Bartlett >>>> >>>> -- >>>> Andrew Bartlett http://samba.org/~abartlet/ >>>> Authentication Developer, Samba Team http://samba.org >>>> Samba Developer, Catalyst IT >>>> http://catalyst.net.nz/services/samba >>>> >>>> >>>> >>>> >> -- >> To unsubscribe from this list go to the following URL and read the >> instructions: https://lists.samba.org/mailman/options/samba >>
If there was no UNIX/Linux client, it would have been too easy, not fun enough :) File servers will be Linux clients using SSSD for users only, groups will local to these file servers, to limit database usage (because of 4GB limit). Some Linux workstation should be added at some point into this AD, they will also use SSSD to retrieve users and groups. No idea yet about how much of these they expect to deploy (once more, with information, no fun :p) Something else about winbind: Winbind build uid (and perhaps gid) using "objectSid" at some point, I don't what was my configuration at that moment but I remember users displayed using some digit string (between 3 to 6 digits) then the last part of objectSid. ex: from objectSid: S-1-5-21-0123456789-0123456789-0123456789-12345 last 12345 was extracted. This sounds good, unfortunately added digits make, from my non-samba-dev point of view, this forged uid not reliable as I don't know how - nor why - these digits are added. They did not match any part of domain's SID. As this last part of objectSid must be unique in AD database using this number as is rather than adding some digits to it would be reliable. The bad point of this is [I think] AD keep traces of already used objectSid, meaning if you delete a user to recreate it you won't be able to set same objectSid (except removing deleted objects perhaps or changing "searchFlags" to really delete them when using ldbdel). This implies a deleted then recreated user can't be the same user, all file rights and ACLs set using this account must be rebuilt. Using objectSid as uid and primaryGroup as gid means this rights and ACLs issue would happen on both world (UNIX and Windows)... Anyway, there is workaround (SSSD for clients, a non-DC member server with SSSD to check ACLs, etc...), there are lot of more urgent stuffs to do, not a real issue :) 2015-06-30 14:00 GMT+02:00 Rowland Penny <rowlandpenny241155 at gmail.com>:> On 30/06/15 12:51, mathias dufresne wrote: > >> 2015-06-30 12:42 GMT+02:00 Rowland Penny <rowlandpenny241155 at gmail.com>: >> >> On 30/06/15 11:17, mathias dufresne wrote: >>> >>> @Andrew: I expect these lines came from RDP issue workaround which >>>> should >>>> be happening with previous Samba version. I removed all these lines as >>>> now, >>>> with 4.2.2 Samba version RDP and RSAT are working well without them. >>>> >>>> I removed also each and every idmap lines, commented most of winbind >>>> lines >>>> too and now my smb.conf is: >>>> ------------------------------------------------------------ >>>> [global] >>>> workgroup = AD.DOMAIN >>>> realm = ad.domain.tld >>>> netbios name = DC01 >>>> server role = active directory domain controller >>>> >>>> dns forwarder = 10.0.0.240 >>>> >>>> wins support = yes >>>> winbind nss info = rfc2307 >>>> >>>> The 'winbind nss info = rfc2307' line should be 'idmap_ldb:use rfc2307 >>> >>> yes' on a DC >>> >>> I checked on some other DC and even using 'idmap_ldb:use rfc2307 = yes' >> behaviour of wbinfo and getent are the same. >> >> >> >>> [netlogon] >>>> path = /var/lib/samba/sysvol/ad.domain.tld/scripts >>>> read only = No >>>> >>>> [sysvol] >>>> path = /var/lib/samba/sysvol >>>> read only = No >>>> ------------------------------------------------------------ >>>> >>>> There is still something I don't understand: >>>> "wbinfo -i some.user" does not show configured homeDirectory nor >>>> loginShell >>>> nor for gidNumber >>>> For loginShell it displays "/bin/false" rather than configured >>>> "/bin/bash" >>>> For homeDirectory it displays "/home/AD.DOMAIN/some.user" rather >>>> configured >>>> "/home/some.user" >>>> For gidNumber it displays "100" rather than content of "gidNumber". >>>> >>>> This is one of the reasons why it is not recommended to use a DC as a >>> fileserver, whilst from version 4.2.0, samba uses the same 'winbindd' >>> daemon as on a member server, it still doesn't use all its capabilities. >>> You can set 'template homedir' and 'template shell' in smb.conf, see 'man >>> smb.conf, but note these will affect *all* users, you cannot set >>> individual >>> user homedir paths and shells. >>> To get the users 'gidNumber' attribute shown by 'getent' etc , you need >>> to >>> ensure that 'Domain Users' has a 'gidNumber' attribute. >>> >>> I discovered these option this weekend but as you say, all users are >> impacted. As users are a bit numerous (120 000) and I'm only there to >> design the solution, I have no real idea about how they would use this AD, >> meaning I can't push to use them as they would lose configuration >> granularity. >> >> >> >>> SSSD can easily be configured on non-DC to replace winbind and it gives >>>> possibility to configure which LDB attributes are retrieved. >>>> On DC I'm still facing incompatibility between Sernet's Samba and SSSD >>>> package (on Centos 6 & 7 and Debian 8) so initially I planned to use >>>> winbind in nsswitch.conf and pam.d/* on DC to be able to check ACLs on >>>> sysvol folder but the fact using winbind all users have "Domain users" >>>> as >>>> primary group seems to me an issue to agree with that solution... >>>> >>>> This is yet another reason not to use a DC as a fileserver. The 'Domain >>> users' problem can be fixed, but it can cause more problems than what it >>> fixes, because to change the users primaryGroupID attribute means >>> removing >>> the user from the 'Domain Users' group and windows expects all users to >>> be >>> a member of 'Domain Users'. >>> >>> As far I understand wbinfo fill user's primary group according to >>> >>>> "primaryGroup" value. >>>> >>>> Is there a way to configure winbind to fill user's primary group using >>>> "gidNumber" rather than "primaryGroup"? >>>> >>>> On a DC, no. On a member server this is not a problem. >>> >>> No issue on system using SSSD as it comes with options to force usage of >> specific LDB attributes to fill getent answers (using sssd-ldap options as >> "ldap_user_shell = loginShell" even when using sssd-ad as SSSD engine, how >> long this would be possible, no idea). >> > > This is doing the same as 'template shell = loginShell' > > >> Why not insert into winbindd client such options? (ok the answer could be: >> because there is other work to be done first :) >> > > You got it in one :-) > > Are there any Unix clients, or are they all windows clients, if the latter > then it shouldn't be a problem, only Unix clients need the RFC2307 > attributes. > > Rowland > > > Best regards, >> >> mathias >> >> >> Rowland >>> >>> Cheers, >>> >>>> mathias >>>> >>>> >>>> 2015-06-29 11:18 GMT+02:00 Andrew Bartlett <abartlet at samba.org>: >>>> >>>> On Thu, 2015-06-25 at 16:27 +0200, mathias dufresne wrote: >>>> >>>>> Hi all, >>>>>> >>>>>> I'm wondering about winbind[d] behaviour. >>>>>> I tried the following with: >>>>>> auth methods = sam winbindd >>>>>> and the same with only one d: >>>>>> auth methods = sam winbind >>>>>> >>>>>> Please never set these manually. >>>>> >>>>> There are almost no situations where these need to be manually managed, >>>>> the defaults based on the server role will behave correctly and as >>>>> expected. >>>>> >>>>> Thanks, >>>>> >>>>> Andrew Bartlett >>>>> >>>>> -- >>>>> Andrew Bartlett http://samba.org/~abartlet/ >>>>> Authentication Developer, Samba Team http://samba.org >>>>> Samba Developer, Catalyst IT >>>>> http://catalyst.net.nz/services/samba >>>>> >>>>> >>>>> >>>>> >>>>> -- >>> To unsubscribe from this list go to the following URL and read the >>> instructions: https://lists.samba.org/mailman/options/samba >>> >>> > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >