[Freeipa-users] stop lookups to trusted AD domain for certain accounts
I'm looking for advice on the best way to tackle a problem I'm encountering. I have a box which uses IPA/AD for authentication. SSH is running and open and all users should be able to log in. The box sees quite a bit of malicious access attempts - each of these attempts is having its (false) credentials sent to AD for verification. This has resulted in some AD service accounts being locked out due to too many failed login attempts. How can I configure this box so that no lookups are performed on AD for a list of accounts that I specify? ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/KOUGQ3PDCQMJF2HQDPUELYMCCPMLQ47O/
[Freeipa-users] Re: stop lookups to trusted AD domain for certain accounts
I was able to accomplish this using the filter_users option in /etc/sssd/sssd.conf. Thanks! ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/5RZM3Y4WOTEPV3XSSTNGE3CVKM4MRK5T/
[Freeipa-users] Client authentication against trusted AD broken
I've seen similar situations in other threads, but searching for a solution hasn't proven fruitful so far; please point me in the right direction! I've configured an ipa server with a trusted AD domain and both lookups and authentication are working on the server (I can getent and id AD users, and can ssh to the server as an AD user.) On the client side, however, only lookups are working. I can getent and id AD users, but can't authenticate as one. Here's a section of the sssd_cs.domain.dom.log from an authentication attempt. The obvious red flag is: (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [sss_domain_get_state] (0x1000): Domain cs.domain.dom is Active (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [sss_domain_get_state] (0x1000): Domain domain.dom is Inactive But I'm unsure how to troubleshoot. LOG: (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [sbus_dispatch] (0x4000): dbus conn: 0x55911dd26920 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [sbus_dispatch] (0x4000): Dispatching. (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.dataprovider.pamHandler on path /org/freedesktop/sssd/dataprovider (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [dp_pam_handler] (0x0100): Got request with the following data (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [pam_print_data] (0x0100): domain: domain.dom (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [pam_print_data] (0x0100): user: usern...@domain.dom (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [pam_print_data] (0x0100): service: sshd (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [pam_print_data] (0x0100): tty: ssh (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [pam_print_data] (0x0100): ruser: (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [pam_print_data] (0x0100): rhost: IP.ADDR (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [pam_print_data] (0x0100): authtok type: 1 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [pam_print_data] (0x0100): priv: 1 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [pam_print_data] (0x0100): cli_pid: 1096 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [pam_print_data] (0x0100): logon name: not set (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [dp_attach_req] (0x0400): DP Request [PAM Authenticate #4]: New request. Flags []. (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [dp_attach_req] (0x0400): Number of active DP request: 1 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [sss_domain_get_state] (0x1000): Domain cs.domain.dom is Active (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [sss_domain_get_state] (0x1000): Domain domain.dom is Inactive (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [krb5_auth_queue_send] (0x1000): Wait queue of user [usern...@domain.dom] is empty, running request [0x55911dd133f0] immediately. (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [sss_domain_get_state] (0x1000): Domain cs.domain.dom is Active (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [sss_domain_get_state] (0x1000): Domain domain.dom is Inactive (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [krb5_setup] (0x4000): No mapping for: usern...@domain.dom (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55911dd31600 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55911dd316c0 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Running timer event 0x55911dd31600 "ltdb_callback" (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Destroying timer event 0x55911dd316c0 "ltdb_timeout" (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Ending timer event 0x55911dd31600 "ltdb_callback" (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55911dd2da90 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55911dd2db50 (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Running timer event 0x55911dd2da90 "ltdb_callback" (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Destroying timer event 0x55911dd2db50 "ltdb_timeout" (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [ldb] (0x4000): Ending timer event 0x55911dd2da90 "ltdb_callback" (Thu Jul 5 11:31:44 2018) [sssd[be[cs.domain.dom]]] [fo_resolve_service_send] (0x0100): Trying to resolve service
[Freeipa-users] Re: Client authentication against trusted AD broken
This is now working after adding a stanza for the AD realm in /etc/krb5.conf file. Should that be necessary? ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/LSODDVTTUAOIZESHL7QONXF4TLXJ4JJU/
[Freeipa-users] Re: Client authentication against trusted AD broken
Also seems to be set: freeipaclient$ dig +short -t SRV _kerberos._udp.cs.domain.dom 0 100 88 ipa.cs.domain.com. freeipaclients$ dig +short -t SRV _kerberos._udp.domain.com 0 100 88 kdc1.domain.com. 0 100 88 kdc2.domain.com. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/Q6GDX25PV3N3CNSU2JB3OAF4D3ZYUSTI/
[Freeipa-users] Re: Only some AD users returned from lookups
No, the lookups fail on both the server and the client. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/NNJC45H5ADRP4E537FMQPS4LDVWOERPD/
[Freeipa-users] Re: Client authentication against trusted AD broken
To the /etc/krb5.conf file on the client, I changed from this:
[realms]
CS.GRINNELL.EDU = {
kdc = ipa.cs.grinnell.edu:88
master_kdc = ipa.cs.grinnell.edu:88
admin_server = ipa.cs.grinnell.edu:749
kpasswd_server = ipa.cs.grinnell.edu:464
default_domain = cs.grinnell.edu
pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
}
To this:
[realms]
CS.DOMAIN.DOM = {
kdc = ipa.cs.domain.dom:88
master_kdc = ipa.cs.domain.dom:88
admin_server = ipa.cs.domain.dom:749
kpasswd_server = ipa.cs.domain.dom:464
default_domain = cs.domain.dom
pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
}
DOMAIN.DOM = {
kdc = kdc1.domain.dom
admin_server = kdc1.domain.dom
}
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/T3QKRMOJM45R2NZ44ECZC3RQACVJODG7/
[Freeipa-users] Re: Client authentication against trusted AD broken
So you're saying the client is probably not finding the AD KDC through DNS SRV calls? I think that I've tested all the DNS configs that are called for in the documentation. What could I do to test whether the AD realm's KDC is being discovered? Here's what I've tried to see if the dns is correctly configured: [root@freeipaclient ~]# dig +short -t SRV _kerberos._tcp.dc._msdcs.cs.domain.dom 0 100 88 ipa.cs.domain.dom. [root@freeipaclient ~]# dig +short -t SRV _kerberos._tcp.dc._msdcs.domain.dom 0 100 88 kdc1.domain.dom. 0 100 88 kdc2.domain.dom. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/AW2TLNXLWYGEESKU22FSBOM3Q6BP3U47/
[Freeipa-users] Re: Only some AD users returned from lookups
sssd_nss.log during attempted lookup of slyme...@grinnell.edu account: https://pastebin.com/gLFnhZ9s ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/G3WQX5GSMLBT53Z4YVX5FRUYYV2CFL6E/
[Freeipa-users] Re: Only some AD users returned from lookups
Aha! This (from the domain log) shed some light: (Thu Jul 12 08:13:33 2018) [sssd[be[cs.grinnell.edu]]] [sdap_save_user] (0x0400): Processing user slyme...@grinnell.edu (Thu Jul 12 08:13:33 2018) [sssd[be[cs.grinnell.edu]]] [sdap_save_user] (0x1000): Mapping user [slyme...@grinnell.edu] objectSID [S-1-5-21-71189414-1642862984-1097818727-518801] to unix ID (Thu Jul 12 08:13:33 2018) [sssd[be[cs.grinnell.edu]]] [sdap_idmap_sid_to_unix] (0x0040): Object SID [S-1-5-21-71189414-1642862984-1097818727-518801] has a RID that is larger than the ldap_idmap_range_size. See the "ID MAPPING" section of sssd-ad(5) for an explanation of how to resolve this issue. (Thu Jul 12 08:13:33 2018) [sssd[be[cs.grinnell.edu]]] [sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID [S-1-5-21-71189414-1642862984-1097818727-518801] to a UNIX ID (Thu Jul 12 08:13:33 2018) [sssd[be[cs.grinnell.edu]]] [sdap_save_user] (0x0020): Failed to save user [slyme...@grinnell.edu] (Thu Jul 12 08:13:33 2018) [sssd[be[cs.grinnell.edu]]] [sdap_save_users] (0x0040): Failed to store user 0. Ignoring. So it looks as though I have an incorrect ID Range for these AD accounts. I increased the number of IDs in the range for the AD domain and - low and behold, the accounts are now resolving. Thank you for your help! ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/YJEB7EDCT64LSCDZJJQKS3EHHAEBJ6QL/
[Freeipa-users] Only some AD users returned from lookups
I have an issue where i've established the AD trust and am able to lookup my own account and about 30 others, but all others fail. I've compared AD attributes across accounts and can't find anything that is notably different. I've seen messages about making sure that groups can resolve, but I don't think that's what's happening. I have a user account that only has one group membership and that group resolves, but the account still is not returned on a lookup. The only common thread I can find with the accounts that succeed is that they are older accounts - they were created a long time ago - more recently created accounts fail. Where can I look to see what might be happening? ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/ONKMM7PEFEPDH43LB5I5KYQ4GZH4UW5B/
[Freeipa-users] Diagnose cause of Directory Services failure
I've configured FreeIPA with an AD trust that is handling workstation logins at my organization. Things have been going well, but I've noticed a couple of times that the Directory Services process is consuming a lot of CPU. This morning, after receiving reports of users not being able to log in, I ran `ipactl status` which reported Directory Services as STOPPED. I'm looking for help on where to begin with a root cause analysis. Here is a snippet from /var/log/dirsrv/error that seems to me to indicate a critical error; I just can't decipher what is happening. * [16/Oct/2018:22:25:43.562185858 -0500] - ERR - accept_and_configure - PR_Accept() failed, Netscape Portable Runtime error -5971 (Process open FD table is full.) [16/Oct/2018:22:25:43.563825169 -0500] - ERR - ns_handle_new_connection - PR_PROC_DESC_TABLE_FULL_ERROR: File Descriptor exhaustion has occured! Connections will be silently dropped! [16/Oct/2018:22:25:43.565434972 -0500] - ERR - accept_and_configure - PR_Accept() failed, Netscape Portable Runtime error -5971 (Process open FD table is full.) [16/Oct/2018:22:25:43.567125116 -0500] - ERR - ns_handle_new_connection - PR_PROC_DESC_TABLE_FULL_ERROR: File Descriptor exhaustion has occured! Connections will be silently dropped! [16/Oct/2018:22:25:43.568974177 -0500] - ERR - libdb - BDB0060 PANIC: fatal region error detected; run recovery [16/Oct/2018:22:25:43.580095520 -0500] - CRIT - deadlock_threadmain - Serious Error---Failed in deadlock detect (aborted at 0x0), err=-30973 (BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery) * Thanks! ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 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/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: Diagnose cause of Directory Services failure
Thank you! The descriptions of the issue that I found do reflect what I experienced: https://pagure.io/389-ds-base/issue/49815 https://bugzilla.redhat.com/show_bug.cgi?id=1605554 DS Version: 389-ds-base-1.3.7.5-24.el7_5.x86_64 I've applied your recommended solution and will report back if the issue resurfaces. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 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/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: kadmin service fails to start
The most useful bit of information I've found so far is this from the kadmind log: kadmind[14297](Error): Failed setting up a RPC socket (for 0.0.0.0.749) kadmind: Address already in use - Error setting up network I read that this can be caused by the rpcbind service taking over the port (https://bugzilla.redhat.com/show_bug.cgi?id=1592883) I've restarted the rpcbind service, but still cannot start the kadmin service. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 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/freeipa-users@lists.fedorahosted.org
[Freeipa-users] kadmin service fails to start
I've had a FreeIPA installation running without issues until today directory services went down and when I attempt to restart services using `ipactl restart` the kadmin service fails to start. I've been digging through logs and searching for answers but haven't found anything that makes sense to me. The only change I introduced (that I'm aware of) was that I upgraded ipa-server on the replica a week or two ago. Master is running IPA 4.5 and replica is running IPA 4.6. Any help with troubleshooting would be greatly appreciated. -Mike ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 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/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: kadmin service fails to start
I decided to reboot the master and the services came back up without a problem. Is it likely I was experiencing the bug that I linked earlier, and that just restarting the rpcbind service isn't enough to free the port for kadmin to use? ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 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/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: kadmin service fails to start
Thanks for the reply. I ran `nestat -tulpn` after restarting the rpcbind service and did not see anything listening on 749. Unfortunately, I didn't think to run it before I restarted the rpcbind service. Is it possible kadmin think the port is in use even after rpcbind has moved off it? ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 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/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Please help me find what broke down with my AD authentications
I have a one-way trust configured to AD. It has been working for a long time but has stopped and I can't track down what has happened. `getent passwd user` works on users in IPA, but fails (nothing returned) on AD users. Contents of sssd.conf on client: [domain/ipa.domain.edu] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = ipa.domain.edu id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = test.ipa.domain.edu chpass_provider = ipa ipa_server = _srv_,ipa.ipa.grinnell.edu ipa_server_mode = true ldap_tls_cacert = /etc/ipa/ca.crt krb5_validate = False debug_level=8 [sssd] services = nss, sudo, pam, ssh domains = ipa.domain.edu [nss] homedir_substring = /home `ipa trustdomain-find` returns the trusted AD domain I haven't found anything I can make sense of in the logs, but this might be a clue to someone else: From the sssd_ipa.domain.edu.log (Thu Feb 11 12:07:19 2021) [sssd[be[ipa.domain.edu]]] [sss_domain_get_state] (0x1000): Domain ipa.domain.edu is Active (Thu Feb 11 12:07:19 2021) [sssd[be[ipa.domain.edu]]] [sss_domain_get_state] (0x1000): Domain domain.edu is Active (Thu Feb 11 12:07:19 2021) [sssd[be[ipa.domain.edu]]] [ipa_srv_ad_acct_lookup_step] (0x0400): Looking up AD account (Thu Feb 11 12:07:19 2021) [sssd[be[ipa.domain.edu]]] [sss_domain_get_state] (0x1000): Domain ipa.domain.edu is Active (Thu Feb 11 12:07:19 2021) [sssd[be[ipa.domain.edu]]] [sss_domain_get_state] (0x1000): Domain domain.edu is Active (Thu Feb 11 12:07:19 2021) [sssd[be[ipa.domain.edu]]] [be_mark_dom_offline] (0x1000): Marking subdomain domain.edu offline (Thu Feb 11 12:07:19 2021) [sssd[be[ipa.domain.edu]]] [be_mark_subdom_offline] (0x1000): Marking subdomain domain.edu as inactive (Thu Feb 11 12:07:19 2021) [sssd[be[ipa.domain.edu]]] [ipa_srv_ad_acct_lookup_done] (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument. (Thu Feb 11 12:07:19 2021) [sssd[be[ipa.domain.edu]]] [ipa_subdomain_account_done] (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument. (Thu Feb 11 12:07:19 2021) [sssd[be[ipa.domain.edu]]] [dp_req_done] (0x0400): DP Request [Account #20]: Request handler finished [0]: Success (Thu Feb 11 12:07:19 2021) [sssd[be[ipa.domain.edu]]] [_dp_req_recv] (0x0400): DP Request [Account #20]: Receiving request data. (Thu Feb 11 12:07:19 2021) [sssd[be[ipa.domain.edu]]] [dp_req_reply_list_success] (0x0400): DP Request [Account #20]: Finished. Success. (Thu Feb 11 12:07:19 2021) [sssd[be[ipa.domain.edu]]] [dp_req_reply_std] (0x1000): DP Request [Account #20]: Returning [Internal Error]: 3,22,Invalid argument (Thu Feb 11 12:07:19 2021) [sssd[be[ipa.domain.edu]]] [dp_table_value_destructor] (0x0400): Removing [0:1:0x0001:1::domain.edu:name=conne...@domain.edu] from reply table ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 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/freeipa-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: Please help me find what broke down with my AD authentications
I'm afraid I don't know how to construct the right ipa-getkeytab command to test. Do I run ipa-getkeytab on the client or on the ipa server? For the IPA$@DOMAIN.EDU principal? I thought about STARTTLS pointing to a certificate issue. The certs on the ipa server are not expired: getcert list | grep expires expires: 2022-06-18 21:28:39 UTC expires: 2022-05-24 03:14:46 UTC expires: 2022-05-24 03:15:16 UTC expires: 2022-05-24 03:14:56 UTC expires: 2038-07-11 18:11:01 UTC expires: 2022-05-24 03:14:38 UTC expires: 2022-08-01 03:40:17 UTC expires: 2022-06-15 03:14:35 UTC expires: 2022-06-15 03:14:50 UTC Could it be an issue with an expired certificate on the AD end? Thank you! ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 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/freeipa-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: Please help me find what broke down with my AD authentications
The certificate for the AD secure ldap server is also current (ad.domain.edu:636). ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 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/freeipa-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: Please help me find what broke down with my AD authentications
Thank you. I've run the following command on the broken client. In this instance 'ipa.ipa.domain.edu' is the IPA server. 'IPA$@DOMAIN.EDU' was used simply because it's what I saw in the logs. KRB5CCNAME=/var/lib/sss/db/ccache_IPA.DOMAIN.EDU /usr/sbin/ipa-getkeytab -r -s ipa.ipa.domain.edu -p 'IPA$@DOMAIN.EDU' -k /var/lib/sss/keytabs/domain.edu.keytab-test The result is: `Failed to load translations Failed to parse result: Insufficient access rights Failed to get keytab` ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 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/freeipa-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: Please help me find what broke down with my AD authentications
The following is a portion of the sssd log on the client reflecting the same inability to retrieve keytab: *** (Fri Feb 12 10:11:54 2021) [sssd[be[ipa.domain.edu]]] [sss_domain_get_state] (0x1000): Domain domain.edu is Active (Fri Feb 12 10:11:54 2021) [sssd[be[ipa.domain.edu]]] [ipa_server_trusted_dom_setup_send] (0x1000): Trust direction of subdom domain.edu from forest domain.edu is: one-way inbound: local domain trusts the remote domain (Fri Feb 12 10:11:54 2021) [sssd[be[ipa.domain.edu]]] [ipa_server_trusted_dom_setup_1way] (0x0400): Will re-fetch keytab for domain.edu (Fri Feb 12 10:11:54 2021) [sssd[be[ipa.domain.edu]]] [ipa_getkeytab_send] (0x0400): Retrieving keytab for IPA$@domain.EDU from test.ipa.domain.edu into /var/lib/sss/keytabs/domain.edu.keytabENwf67 using ccache /var/lib/sss/db/ccache_IPA.DOMAIN.EDU (Fri Feb 12 10:11:54 2021) [sssd[be[ipa.domain.edu]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [88300] (Fri Feb 12 10:11:54 2021) [sssd[be[ipa.domain.edu]]] [child_handler_setup] (0x2000): Signal handler set up for pid [88300] (Fri Feb 12 10:11:54 2021) [sssd[be[ipa.domain.edu]]] [sbus_dispatch] (0x4000): dbus conn: 0x5578611b8b00 (Fri Feb 12 10:11:54 2021) [sssd[be[ipa.domain.edu]]] [sbus_dispatch] (0x4000): dbus conn: 0x5578611b8b00 (Fri Feb 12 10:11:54 2021) [sssd[be[ipa.domain.edu]]] [sbus_toggle_watch] (0x4000): 0x55786117b780/0x5578611b8700 (14), R/- (disabled) (Fri Feb 12 10:11:54 2021) [sssd[be[ipa.domain.edu]]] [sbus_toggle_watch] (0x4000): 0x55786117b780/0x5578611b86b0 (14), -/W (enabled) *** At the same time, the errors log on the IPA server (/var/log/dirsrv/slapd_IPA-DOMAIN-EDU/errors) does not log any errors (TLS or otherwise): *** [12/Feb/2021:10:08:10.990268019 -0600] - INFO - slapd_daemon - slapd started. Listening on All Interfaces port 389 for LDAP requests [12/Feb/2021:10:08:10.992126928 -0600] - INFO - slapd_daemon - Listening on All Interfaces port 636 for LDAPS requests [12/Feb/2021:10:08:10.993036367 -0600] - INFO - slapd_daemon - Listening on /var/run/slapd-IPA-DOMAIN-EDU.socket for LDAPI requests [12/Feb/2021:10:08:11.058722880 -0600] - ERR - schema-compat-plugin - schema-compat-plugin tree scan will start in about 5 seconds! [12/Feb/2021:10:08:16.148838179 -0600] - ERR - schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=ipa,dc=domain,dc=edu [12/Feb/2021:10:08:16.150531968 -0600] - ERR - schema-compat-plugin - Finished plugin initialization. *** Thanks! ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 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/freeipa-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: Please help me find what broke down with my AD authentications
This may be useful information: Clients are still able to lookup and authenticate AD users as long as they have an in-tact cache. If I empty the sssd cache, that client will no longer be able to perform AD lookups or authentications. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 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/freeipa-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: Please help me find what broke down with my AD authentications
Thank you for the clarification. I ran in on the IPA server and the keytab was successfully retrieved. `Keytab successfully retrieved and stored in: /var/lib/sss/keytabs/domain.edu.keytab-test` -Mike ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 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/freeipa-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: Please help me find what broke down with my AD authentications
More logs. This is from another broken client during an attempt to login as an AD user: (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [sss_domain_get_state] (0x1000): Domain domain.edu is Active (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [ipa_s2n_get_acct_info_send] (0x0400): Sending request_type: [REQ_FULL_WITH_MEMBERS] for trust user [S-1-5-21-71189414-1642862984-1097818727-22197] to IPA server (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 16 (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [sdap_op_add] (0x2000): New operation 16 timeout 6 (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [sdap_process_result] (0x2000): Trace: sh[0x55eb482586a0], connected[1], ops[0x55eb482c6f10], ldap[0x55eb48274a50] (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [sdap_process_result] (0x2000): Trace: sh[0x55eb482586a0], connected[1], ops[0x55eb482c6f10], ldap[0x55eb48274a50] (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_EXTENDED] (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [ipa_s2n_exop_done] (0x0040): ldap_extended_operation result: Operations error(1), Failed to split fully qualified name. (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [ipa_s2n_exop_done] (0x0040): ldap_extended_operation failed, server logs might contain more details. (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [sdap_op_destructor] (0x2000): Operation 16 finished (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [sdap_id_op_done] (0x4000): releasing operation connection (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [ipa_subdomain_account_done] (0x0040): ipa_get_*_acct request failed: [1432158229]: Network I/O Error. (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [dp_req_done] (0x0400): DP Request [Account #1]: Request handler finished [0]: Success (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [_dp_req_recv] (0x0400): DP Request [Account #1]: Receiving request data. (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [dp_req_reply_list_success] (0x0400): DP Request [Account #1]: Finished. Success. (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [dp_req_reply_std] (0x1000): DP Request [Account #1]: Returning [Internal Error]: 3,1432158229,Network I/O Error (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [dp_table_value_destructor] (0x0400): Removing [0:1:0x0001:1:V:domain.edu:name=conne...@domain.edu] from reply table (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [dp_req_destructor] (0x0400): DP Request [Account #1]: Request removed. (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [dp_req_destructor] (0x0400): Number of active DP request: 0 (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [sdap_process_result] (0x2000): Trace: sh[0x55eb482586a0], connected[1], ops[(nil)], ldap[0x55eb48274a50] (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [sbus_dispatch] (0x4000): dbus conn: 0x55eb482d0940 (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [sbus_dispatch] (0x4000): Dispatching. (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.dataprovider.getAccountInfo on path /org/freedesktop/sssd/dataprovider The `Returning [Internal Error]: 3,1432158229,Network I/O Error` part sticks out. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 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/freeipa-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: Please help me find what broke down with my AD authentications
Yes. I had modified sssd.conf on the server in pursuit of the solution to proposed change and that is what caused this issue. I reverted the config and authentication/lookups are now working as expected. I'd forgotten that I made that change and since clients with in-tact caches were still working the impact wasn't evident until I configured a new client and enough time had passed that I didn't make the connection. Lesson learned. Revisiting the logs, I see it was the "Failed to split fully qualified name." that led you to this conclusion. I'm tremendously grateful for your help! ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 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/freeipa-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: Please help me find what broke down with my AD authentications
This additional bit from the logs indicates a failure to retireve a keytab: (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [main] (0x0400): Backend provider (ipa.domain.edu) started! (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sss_domain_get_state] (0x1000): Domain domain.edu is Active (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [ipa_server_trusted_dom_setup_send] (0x1000): Trust direction of subdom domain.edu from forest domain.edu is: one-way inbound: local domain trusts the remote domain (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [ipa_server_trusted_dom_setup_1way] (0x0400): Will re-fetch keytab for domain.edu (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [ipa_getkeytab_send] (0x0400): Retrieving keytab for IPA$@DOMAIN.EDU from test.ipa.domain.edu into /var/lib/sss/keytabs/domain.edu.keytabDHvyo4 using ccache /var/lib/sss/db/ccache_ipa.domain.edu (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [80814] (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [child_handler_setup] (0x2000): Signal handler set up for pid [80814] (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_dispatch] (0x4000): dbus conn: 0x556b59a5db00 (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_dispatch] (0x4000): dbus conn: 0x556b59a5db00 (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_toggle_watch] (0x4000): 0x556b59a20780/0x556b59a5d700 (14), R/- (disabled) (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_toggle_watch] (0x4000): 0x556b59a20780/0x556b59a5d6b0 (14), -/W (enabled) (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_toggle_watch] (0x4000): 0x556b59a20780/0x556b59a5d700 (14), R/- (enabled) (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_toggle_watch] (0x4000): 0x556b59a20780/0x556b59a5d6b0 (14), -/W (disabled) (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_toggle_watch] (0x4000): 0x556b59a20780/0x556b59a5d700 (14), R/- (disabled) (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_toggle_watch] (0x4000): 0x556b59a20780/0x556b59a5d6b0 (14), -/W (enabled) (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_toggle_watch] (0x4000): 0x556b59a20780/0x556b59a5d700 (14), R/- (enabled) (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_toggle_watch] (0x4000): 0x556b59a20780/0x556b59a5d6b0 (14), -/W (disabled) (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_remove_timeout] (0x2000): 0x556b59a5e9c0 (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_dispatch] (0x4000): dbus conn: 0x556b59a5db00 (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_dispatch] (0x4000): Dispatching. (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [id_callback] (0x0100): Got id ack and version (1) from Monitor (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_server_init_new_connection] (0x0200): Entering. (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_server_init_new_connection] (0x0200): Adding connection 0x556b59a85950. (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_init_connection] (0x0400): Adding connection 0x556b59a85950 (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_add_watch] (0x2000): 0x556b59a8f920/0x556b59a80e30 (18), -/W (disabled) (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_toggle_watch] (0x4000): 0x556b59a8f920/0x556b59a7e380 (18), R/- (enabled) (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_server_init_new_connection] (0x0200): Got a connection (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [dp_client_init] (0x0100): Set-up Backend ID timeout [0x556b59a8ec30] (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.sssd.DataProvider.Client with path /org/freedesktop/sssd/dataprovider (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_conn_register_path] (0x0400): Registering object path /org/freedesktop/sssd/dataprovider with D-Bus connection (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.DBus.Properties with path /org/freedesktop/sssd/dataprovider (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.DBus.Introspectable with path /org/freedesktop/sssd/dataprovider (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.sssd.dataprovider with path /org/freedesktop/sssd/dataprovider (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.sssd.DataProvider.Backend with path /org/freedesktop/sssd/dataprovider (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]]
