hi,
thanks for replying. Yes, we had seen this already, that is also why I was
pointing to the rhel 8 idm server in krb5.conf en sssd.conf
I missed the dns_lookup_kdc = false directive though, in krb5.conf
[libdefaults] section, I modified it, tried but still not working.
The rest points to the one host.
#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 = false
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
}
and this:
# grep ipa_server /etc/sssd/sssd.conf
ipa_server = ds.idm.domain.local
When I try ssh from a remote host, I see that sssd tries getting info for a
trusted user:
(2024-03-22 16:42:35): [be[idm.domain.local]] [dp_get_account_info_send]
(0x0200): Got request for [0x1][BE_REQ_USER][name=user@ad]
(2024-03-22 16:42:35): [be[idm.domain.local]] [dp_attach_req] (0x0400):
[RID#8] DP Request [Account #8]: REQ_TRACE: New request. [sssd.nss CID #4]
Flags [0x0001].
(2024-03-22 16:42:35): [be[idm.domain.local]] [dp_attach_req] (0x0400):
[RID#8] Number of active DP request: 1
(2024-03-22 16:42:35): [be[idm.domain.local]] [sss_domain_get_state]
(0x1000): [RID#8] Domain idm.domain.local is Active
(2024-03-22 16:42:35): [be[idm.domain.local]] [sss_domain_get_state]
(0x1000): [RID#8] Domain domain.local is Active
(2024-03-22 16:42:35): [be[idm.domain.local]] [sss_domain_get_state]
(0x1000): [RID#8] Domain idm.domain.local is Active
(2024-03-22 16:42:35): [be[idm.domain.local]] [sss_domain_get_state]
(0x1000): [RID#8] Domain domain.local is Active
(2024-03-22 16:42:35): [be[idm.domain.local]] [sss_domain_get_state]
(0x1000): [RID#8] Domain idm.domain.local is Active
(2024-03-22 16:42:35): [be[idm.domain.local]] [sss_domain_get_state]
(0x1000): [RID#8] Domain domain.local is Active
(2024-03-22 16:42:35): [be[idm.domain.local]] [sdap_id_op_connect_step]
(0x4000): [RID#8] reusing cached connection
(2024-03-22 16:42:35): [be[idm.domain.local]] [sdap_id_conn_data_not_idle]
(0x4000): [RID#8] Marking connection as not idle
(2024-03-22 16:42:35): [be[idm.domain.local]] [ipa_s2n_get_acct_info_send]
(0x0400): [RID#8] Sending request_type: [REQ_FULL_WITH_MEMBERS] for trust
user [user@ad] to IPA server
(2024-03-22 16:42:35): [be[idm.domain.local]] [ipa_s2n_exop_send] (0x0400):
[RID#8] Executing extended operation
(2024-03-22 16:42:35): [be[idm.domain.local]] [ipa_s2n_exop_send] (0x2000):
[RID#8] ldap_extended_operation sent, msgid = 22
(2024-03-22 16:42:35): [be[idm.domain.local]] [sdap_op_add] (0x2000):
[RID#8] New operation 22 timeout 6
(2024-03-22 16:42:35): [be[idm.domain.local]] [sdap_process_result]
(0x2000): Trace: sh[0x55bcce14e400], connected[1], ops[0x55bcce119870],
ldap[0x55bcce14c1c0]
(2024-03-22 16:42:35): [be[idm.domain.local]] [sdap_process_message]
(0x4000): [RID#8] Message type: [LDAP_RES_EXTENDED]
(2024-03-22 16:42:35): [be[idm.domain.local]] [sdap_call_op_callback]
(0x20000): [RID#8] Handling LDAP operation [22][server: [xxx:389] IPA EXOP]
took [0.752] milliseconds.
(2024-03-22 16:42:35): [be[idm.domain.local]] [ipa_s2n_exop_done] (0x0400):
[RID#8] ldap_extended_operation result: No such object(32), (null).
but it finds nothing it seems.
on the idm host everything seems to be running:
# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
smb Service: RUNNING
winbind Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful
And now I don't know what else to try. It seems that the trust agent is not
answering properly, but how do I check this?
On Fri, Mar 22, 2024 at 4:12 PM Alexander Bokovoy <[email protected]>
wrote:
> 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
>
>
--
--
Groeten,
natxo
--
_______________________________________________
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
