On Пят, 22 сак 2024, Natxo Asenjo via FreeIPA-users wrote:
hi,at work we are having *interesting* problems with our migration from idm servers running rhel 7 to new rhel 8 idm servers. We have a AD -> idm trust in place, this is working properly. AD is domain.local IDM is idm.domain.local We add replicas to the set, and this runs properly. No replication errors. Basically the problem is we cannot log in to newly joined systems running rhel 8 as trusted users from AD. We have a new rhel 8 idm server which has also the trust agent and trust controller role installed. We want to login as a trusted AD user to a rhel 8 host which has this new rhel 8 idm server as its ipa host, we have forced it using this sssd.conf: [domain/idm.domain.local] id_provider = ipa ipa_server = ds.idm.domain.local ipa_domain = idm.domain.local ipa_hostname = host.idm.domain.local auth_provider = ipa chpass_provider = ipa access_provider = ipa cache_credentials = True ldap_tls_cacert = /etc/ipa/ca.crt dyndns_update = True dyndns_iface = ens192 krb5_store_password_if_offline = True [sssd] services = nss, pam, ssh, sudo domains = idm.domain.local full_name_format = %1$s debug = 9 [nss] homedir_substring = /home override_homedir = /home/%u [pam] [sudo] [autofs] [ssh] [pac] [ifp] [session_recording] We also modified krb5.conf on the client to find the IDM realm only on the rhel 8 idm server, not the rhel 7. So we disabled srv dns autodiscovery for the IDM.DOMAIN.LOCAL realm: # cat /etc/krb5.conf #File modified by ipa-client-install includedir /etc/krb5.conf.d/ [libdefaults] default_realm = IDM.DOMAIN.LOCAL dns_lookup_realm = true rdns = false dns_canonicalize_hostname = false dns_lookup_kdc = true ticket_lifetime = 24h forwardable = true udp_preference_limit = 0 default_ccache_name = KEYRING:persistent:%{uid} [realms] IDM.DOMAIN.LOCAL = { kdc = ds.idm.domain.local:88 master_kdc = ds.idm.domain.local:88 admin_server = ds.idm.domain.local:749 kpasswd_server = ds.idm.domain.local:464 default_domain = idm.domain.local pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem } [domain_realm] .idm.domain.local = IDM.DOMAIN.LOCAL idm.domain.local = IDM.DOMAIN.LOCAL host.idm.domain.local = IDM.DOMAIN.LOCAL On the rhel 8 client, I can kinit with the host keytab, this work, I get a ticket with the host principal. I can also kinit using a trusted AD user, this works, I get a ticket of the AD domain. But as soon as I try logging in from ssh, it does not work. It does not recognize the user. Running id trusteduser@ad does not wok either (no such user) I have run out of ideas, to be honest. I do not know how to troubleshoot this anymore. The rhel8 idm server finds the users, I can log in there without any problem too thanks to the rbac rules, but this rhel8 client simpley will not see the users.
This all sounds like you see SPAKE vs non-SPAKE behavior by the clients. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/migrating_to_identity_management_on_rhel_8/migrate-7-to-8_migrating covers this in a yellow warning box: ------------------------------------- Important RHEL 8 supports SPAKE and IdP pre-authentication, but RHEL 7 does not. Having RHEL 8 servers with SPAKE or IdP enabled in a RHEL 7 IdM deployment may lead to problems such as users not being able to log in. Red Hat strongly recommends that all servers in an IdM deployment are migrated as quickly as possible and that older systems should not be left in operation for extended periods of time. For more information, see: https://access.redhat.com/solutions/7053377 https://access.redhat.com/solutions/3529911 ------------------------------------- Specifically, https://access.redhat.com/solutions/7053377 should have enough technical details to confirm it is the case. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland -- _______________________________________________ FreeIPA-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] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
