I have tested. This seems to work:
[commands] sssd-enable-logins = /usr/bin/sh -c "/usr/bin/systemctl enable oddjobd.service && /usr/bin/systemctl start oddjobd.service" sssd-disable-logins = /bin/true In /etc/realmd.conf. Apparently, it's a distro-specific RHEL8 thing -- I was not aware of this /usr/lib/realmd/realmd-distro.conf file for RHEL8, but now I am. If that hadn't worked, I would have run "authselect set custom/profile" after the "realm join". Per the other suggestion. There's only one miniscule downside -- and it's really just a quibble. I now have to install in my @Minimal install authselect & authselect-libs RPM, just to satisfy realmd RPM dependency. That means that those two RPMs will get patched monthly as new versions come out. But that's a very small price to pay for this functionality. Thanks, all! Spike On Mon, Apr 29, 2019 at 5:38 AM Sumit Bose <[email protected]> wrote: > On Mon, Apr 29, 2019 at 08:59:32AM +0200, Pavel Březina wrote: > > On 4/28/19 7:04 PM, Spike White wrote: > > > BTW, > > > > > > Even if beforehand in authselect I create a custom profile and set > > > /etc/authselect/authselect.conf to this custom/profile. > > > > > > When I run 'realm join', it still invokes: > > > > > > * /usr/bin/sh -c /usr/bin/authselect select sssd with-mkhomedir > > > --force && /usr/bin/systemctl enable oddjobd.service && > > > /usr/bin/systemctl start oddjobd.service > > > > Hi, > > > > AFAIK there is no way to tell realm not to call authselect. But realm is > > usually run only once so you can always call authselect select > > custom/profile after you call realm join. > > > > If this is not enough for some reason, you need to file RFE against > realmd. > > Hi, > > there is no command line option, but in > /usr/lib/realmd/realmd-distro.conf it is defined how authselect is > called by realmd. > > I think if you add > > [commands] > sssd-enable-logins = /usr/bin/sh -c "/usr/bin/systemctl enable > oddjobd.service && /usr/bin/systemctl start oddjobd.service" > > sssd-disable-logins = /bin/true > > to /etc/realmd.conf authselect will not be called anymore. Or you can > use something like > > sssd-enable-logins = /usr/bin/sh -c "/usr/bin/authselect select > your-custom-profike with-your-options --force && /usr/bin/systemctl enable > oddjobd.service && /usr/bin/systemctl start oddjobd.service" > > to tell realmd to use you profile. > > HTH > > bye, > Sumit > > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > That is, it overwrites my already-set up > /etc/authselect/authselect.conf > > > > > > custom/profile > > > > > > with this content: > > > > > > [root@rhel8test01 authselect]# cat authselect.conf > > > sssd > > > with-mkhomedir > > > > > > Spike > > > > > > On Sun, Apr 28, 2019 at 11:46 AM Spike White <[email protected] > > > <mailto:[email protected]>> wrote: > > > > > > All, > > > > > > Basically here is the realm command we use to join the appropriate > > > regional AD domain: > > > > > > realm join -v --automatic-id-mapping=no > > > > --computer-ou="OU=Servers,OU=UNIX,DC=$SUPPORTREGION,DC=COMPANY,DC=COM" > > > --user-principal="host/`hostname --fqdn`@$JOINDOMAIN" $JOINDOMAIN > > > > > > As part of this, realm join internally runs the following command: > > > > > > * /usr/bin/sh -c /usr/bin/authselect select sssd with-mkhomedir > > > --force && /usr/bin/systemctl enable oddjobd.service && > > > /usr/bin/systemctl start oddjobd.service > > > > > > But that sets /etc/pam.d/password-auth and /etc/pam.d/system-auth > to > > > a sub-optimal PAM stack. I.e., not what we desire. > > > > > > For example, 99.9% of our users are in AD. So we want to run > > > pam_sssd *before* pam_unix. > > > > > > We are very comfortable with testing and debugging PAM stacks. We > > > have a stable, tested PAM stack that works great -- ever since > RHEL7. > > > > > > Basically, after the 'realm join' above is done, we have to > > > overwrite /etc/pam.d/{system-auth,password-auth,postlogin} with > what > > > we desire. > > > > > > If 'realm join' can't be convinced to not run authselect, we're ok > > > with creating a custom/profile authselect profile with what we > > > want. And then convince realm join to run: > > > > > > authselect select custom/profile > > > > > > Instead of the above authselect select sssd > > > > > > Prior to running 'realm join', I have to drop down a > > > /etc/realmd.conf file so that the 'realm join' behaves as I want it > > > to. Is there any option in realmd.conf to not run authselect or > > > tailor the authselect command? Or may a flag on the 'realm > > > discover' command line? > > > > > > I don't remember any of these problems with realm join on RHEL7. > > > Maybe it was running authconfig inappropriately as well -- and I > > > just never noticed, because I over-wrote with desired PAM stack? > > > > > > Spike > > > > > > > > > _______________________________________________ > > > sssd-users mailing list -- [email protected] > > > To unsubscribe send an email to > [email protected] > > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: > https://lists.fedorahosted.org/archives/list/[email protected] > > > > > _______________________________________________ > > sssd-users mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedorahosted.org/archives/list/[email protected] > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/[email protected] >
_______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
