On Fri, Jul 03, 2020 at 12:38:54PM -0700, Techie wrote: > Main goal is to authenticate against multiple Kerberos Realms, AD domains > without joining the Linux box to AD. > > We have an AD forest with 2 trusted domains and as a result 2 kerberos > realms, 1 per domain. On RHEL5,6,7 I used pam_krb5 for authentication and > passwd/group files for the user store. This allowed me to authenticate > against AD for users in the passwd file that match the KBR5 principal. In > system-auth/password-auth I would stack pam entries for each KRB5 REALM > > > Parent: EXAMPLE.COM > Domain1: ADA.EXAMPLE.COM > Domain2:ADB.EXAMPLE.COM > > passwd user: joe_doe > krb5 principal: [email protected] > > passwd user: joe_blow > krb5 principal: [email protected] > > system-auth > auth sufficient pam_krb5.so realm=ADA.EXAMPLE.COM use_first_pass > auth sufficient pam_krb5.so realm=ADB.EXAMPLE.COM use_first_pass > > In this case either joe_doe or joe_blow can log in via AD credentials and > pam would iterate through the stacked pam_krb5 entries to locate the > matching krb5 principal > > I am trying to replicate this on redhat enterprise linux 8. I am aware > pam_krb5 is not an option and that sssd is the default for this use case. > What I cannot figure out is how to authenticate against multiple Domains in > SSSD. If I define 1 domain in sssd.conf with id_provider = files. I can > authenticate fine against the single domain/kerberos5 realm. > > If I add multiple domains, sssd does not iterate through them, it fails if > it does not find the user in the first domain.
Hi, it is the other way round, SSSD finds the user already in the first domain because both domains have the same source for users and groups 'id_provider = files' and it tries to authenticate the use in the first domain as well and this fails. Since SSSD does not do try and error by default this error is treated as final and no other domains are looked at. pam_sss.so has an option 'domains' which in theory can be used to create a similar PAM configuration as you are using with pam_krb5 but currently this would fails as well, because the allowed domains are evaluated too late and with the same source for users and groups it still won't be possible to authenticate users from the second domain. As a workaround you can try to use fully-qualified names and split the source into two and use the passwd_files option of the files provider, see man sssd-files for details. Since this is not the first time we were asked how to migrate this kind of pam_krb5 setup I created https://github.com/SSSD/sssd/pull/5234 which should allow to use multiple pam_sss.so lines with domains option in the PAM configuration to work without additional changes. HTH bye, Sumit > > [sssd] > config_file_version = 2 > reconnection_retries = 3 > sbus_timeout = 30 > services = nss, pam > domains = ADA.EXAMPLE.COM,ADB.EXAMPLE.COM > > [pam] > #pam_local_domains = all > > [domain/ADA.EXAMPLE.COM] > id_provider = files > auth_provider=krb5 > krb5_server = adadc.ada.example.com > krb5_kpasswd = adadc.ada.example.com > krb5_realm = ADA.EXAMPLE.COM > dns_discovery_domain =ADA.EXAMPLE.COM > krb5_validate = false > > [domain/ADB.EXAMPLE.COM > id_provider = files > auth_provider=krb5 > krb5_server = adbdc.adb.example.com > krb5_kpasswd = adbdc.adb.example.com > krb5_realm =ADB.EXAMPLE.COM > dns_discovery_domain = ADB.EXAMPLE.COM > krb5_validate = false > > > Is what I am attempting possible without joining AD and using the provider > of AD? I would like to avoid this at all costs. > > Thanks > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
