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]

Reply via email to