On 10/06/2019 16:04, vincent at cojot.name wrote:> > There is probably some amount of redtape on this but AFAIK it works > fine for me: My RHEL7.6 hypervisors are joined to my AD DC 4.10.4 VMs > through use of realm '(and thus sssd): > > Here's a RHEL7.6 client: > # realm list > ad.lasthome.solace.krynn > ? type: kerberos > ? realm-name: AD.LASTHOME.SOLACE.KRYNN > ? domain-name: ad.lasthome.solace.krynn > ? configured: kerberos-member > ? server-software: active-directory > ? client-software: sssd > ? required-package: oddjob > ? required-package: oddjob-mkhomedir > ? required-package: sssd > ? required-package: adcli > ? required-package: samba-common-tools > ? login-formats: %U > ? login-policy: allow-realm-logins > > The AD domain above is two RHEL7.6 VMs with samba 4.10.4 and the rpms > from there: http://nova.polymtl.ca/~coyote/dist/samba/samba-4.10.4/RHEL7Hi Vincent, I have never said that you cannot use sssd with Samba, I just said that Samba doesn't support sssd. I have now found (whilst searching for something else) the red-hat webpage I posted the link to earlier, this unequivocally says that red-hat does not support the use of sssd with Samba. This (to myself) means that Samba cannot support the use of sssd, because we do not produce it and red-hat (who do produce it) do not support its use with Samba, so it looks like you are on your own if something goes wrong. Moral of the story, stick to using winbindd instead ;-) Rowland
On Wed, Jun 12, 2019 at 4:38 AM Rowland penny via samba <samba at lists.samba.org> wrote:> > On 10/06/2019 16:04, vincent at cojot.name wrote: > > > > There is probably some amount of redtape on this but AFAIK it works > > fine for me: My RHEL7.6 hypervisors are joined to my AD DC 4.10.4 VMs > > through use of realm '(and thus sssd): > > > > Here's a RHEL7.6 client: > > # realm list > > ad.lasthome.solace.krynn > > type: kerberos > > realm-name: AD.LASTHOME.SOLACE.KRYNN > > domain-name: ad.lasthome.solace.krynn > > configured: kerberos-member > > server-software: active-directory > > client-software: sssd > > required-package: oddjob > > required-package: oddjob-mkhomedir > > required-package: sssd > > required-package: adcli > > required-package: samba-common-tools > > login-formats: %U > > login-policy: allow-realm-logins > > > > The AD domain above is two RHEL7.6 VMs with samba 4.10.4 and the rpms > > from there: http://nova.polymtl.ca/~coyote/dist/samba/samba-4.10.4/RHEL7 > > > Hi Vincent, I have never said that you cannot use sssd with Samba, I > just said that Samba doesn't support sssd. > > I have now found (whilst searching for something else) the red-hat > webpage I posted the link to earlier, this unequivocally says that > red-hat does not support the use of sssd with Samba. > > This (to myself) means that Samba cannot support the use of sssd, > because we do not produce it and red-hat (who do produce it) do not > support its use with Samba, so it looks like you are on your own if > something goes wrong. > > Moral of the story, stick to using winbindd instead ;-) > > Rowlandsssd has other problems. I've worked with it in the last year. It has a variety of under-documented, complexly interwoven subdaemons whose configurations are centalized, erratically and often require hand-tuning, in the sssd.conf settings. It also has a *nasty* behavior with AD or SSSD: it pre-caches *everything* from the LDAP directories it is pointed to, and I mean *everything*. Its configuration supports structures that only search "onelevel" in an LDAP directory, but when designating this it precaches the entire LDAP directory containing the "onelevel" objects at startup time, with no way I ever found to turn off this misfeature. Hilarity ensues if if your LDAP server, whether Samba or AD, are not close enough to the clien thost. And if your LDAP is big, that local cache gets *bulky*, even if the "onelevel" published objects only contain one element Now, some of that may be an organizatonal issue, but it surprised the heck out of me. The result is that sssd daemons start up, you can log in with the credentials for the first few minutes, but then they fail and take down *all* the sssd subdaemons, and you LDAP based access. While they may be easy to initially activate and configure, realmd and sssd have profound limitations with all domain controllers. The merging of all of the subcomponents into one suite is, in fact, a problem.
On 12/06/2019 10:44, Nico Kadel-Garcia wrote:> On Wed, Jun 12, 2019 at 4:38 AM Rowland penny via samba > <samba at lists.samba.org> wrote: >> On 10/06/2019 16:04, vincent at cojot.name wrote: >>> There is probably some amount of redtape on this but AFAIK it works >>> fine for me: My RHEL7.6 hypervisors are joined to my AD DC 4.10.4 VMs >>> through use of realm '(and thus sssd): >>> >>> Here's a RHEL7.6 client: >>> # realm list >>> ad.lasthome.solace.krynn >>> type: kerberos >>> realm-name: AD.LASTHOME.SOLACE.KRYNN >>> domain-name: ad.lasthome.solace.krynn >>> configured: kerberos-member >>> server-software: active-directory >>> client-software: sssd >>> required-package: oddjob >>> required-package: oddjob-mkhomedir >>> required-package: sssd >>> required-package: adcli >>> required-package: samba-common-tools >>> login-formats: %U >>> login-policy: allow-realm-logins >>> >>> The AD domain above is two RHEL7.6 VMs with samba 4.10.4 and the rpms >>> from there: http://nova.polymtl.ca/~coyote/dist/samba/samba-4.10.4/RHEL7 >> >> Hi Vincent, I have never said that you cannot use sssd with Samba, I >> just said that Samba doesn't support sssd. >> >> I have now found (whilst searching for something else) the red-hat >> webpage I posted the link to earlier, this unequivocally says that >> red-hat does not support the use of sssd with Samba. >> >> This (to myself) means that Samba cannot support the use of sssd, >> because we do not produce it and red-hat (who do produce it) do not >> support its use with Samba, so it looks like you are on your own if >> something goes wrong. >> >> Moral of the story, stick to using winbindd instead ;-) >> >> Rowland > sssd has other problems. I've worked with it in the last year. It has > a variety of under-documented, complexly interwoven subdaemons whose > configurations are centalized, erratically and often require > hand-tuning, in the sssd.conf settings. It also has a *nasty* behavior > with AD or SSSD: it pre-caches *everything* from the LDAP directories > it is pointed to, and I mean *everything*. Its configuration supports > structures that only search "onelevel" in an LDAP directory, but when > designating this it precaches the entire LDAP directory containing the > "onelevel" objects at startup time, with no way I ever found to turn > off this misfeature. Hilarity ensues if if your LDAP server, whether > Samba or AD, are not close enough to the clien thost. And if your LDAP > is big, that local cache gets *bulky*, even if the "onelevel" > published objects only contain one element Now, some of that may be an > organizatonal issue, but it surprised the heck out of me. The result > is that sssd daemons start up, you can log in with the credentials for > the first few minutes, but then they fail and take down *all* the sssd > subdaemons, and you LDAP based access. > > While they may be easy to initially activate and configure, realmd and > sssd have profound limitations with all domain controllers. The > merging of all of the subcomponents into one suite is, in fact, a > problem.This is interesting to know and something I wasn't aware of, my objection to sssd is simply that it isn't a Samba product, so we cannot support it. This doesn't mean you cannot use it with Samba, you just cannot ask here for help with its use, we know nothing about it. Rowland
On 6/12/19 4:44 AM, Nico Kadel-Garcia via samba wrote:> > sssd has other problems. I've worked with it in the last year. It has > a variety of under-documented, complexly interwoven subdaemons whose > configurations are centalized, erratically and often require > hand-tuning, in the sssd.conf settings. It also has a *nasty* behavior > with AD or SSSD: it pre-caches *everything* from the LDAP directories > it is pointed to, and I mean *everything*. Its configuration supports > structures that only search "onelevel" in an LDAP directory, but when > designating this it precaches the entire LDAP directory containing the > "onelevel" objects at startup time, with no way I ever found to turn > off this misfeature. Hilarity ensues if if your LDAP server, whether > Samba or AD, are not close enough to the clien thost. And if your LDAP > is big, that local cache gets *bulky*, even if the "onelevel" > published objects only contain one element Now, some of that may be an > organizatonal issue, but it surprised the heck out of me. The result > is that sssd daemons start up, you can log in with the credentials for > the first few minutes, but then they fail and take down *all* the sssd > subdaemons, and you LDAP based access. >What version of sssd are you using? The evolution of sssd has been pretty dramatic. In particular, I haven't seen any of this, and our AD domain almost certainly includes a million user accounts, at this point (not sure what constitutes "big" in this context. Regarding under documentation of the subdaemons, I'm not following. man sssd-ldap sssd-ad etc. provide a fairly substantial amount of information.