February 2022 - FreeIPA-users - Fedora Mailing-Lists

Inconsistent LDAP data for one of my IPA replicas

by William Faulk

I've got a bunch of replication errors that I'm trying to resolve with a re-initialization, but the biggest one right now is that one of my IPA replicas has inconsistent LDAP attributes and I'm not sure of the best way to proceed. The inconsistent attributes are: * ipaUniqueID * krbPrincipalKey * krbExtraData * krbLastPwdChange Certainly at least the first two seem really significant. I'm hesitant to re-initialize and overwrite data about one of the IPA servers itself. Should I try to delete it as a replica? Try to manually update the data on the replicas with bad data? Just re-initialize from a replica with good data? For the latter two options, how can I determine which data is the correct data?

2 years, 3 months

2
1
0 / 0

gssproxy kerberos cache with no tickets

by Brian J. Murrell

I am still trying to debug why the webUI on my new replica is not authenticating me. One difference I have noticed between my two replicas, one working and one not is: working replica: # KRB5RCACHEDIR=/var/lib/gssproxy/rcache klist Ticket cache: KCM:0 Default principal: admin(a)EXAMPLE.COM Valid starting Expires Service principal 2022-02-04 08:58:59 2022-02-05 08:58:56 krbtgt/EXAMPLE.COM(a)EXAMPLE.COM 2022-02-04 08:59:03 2022-02-05 08:58:56 HTTP/server-staging.example.com(a)EXAMPLE.COM Non-working replica: # KRB5RCACHEDIR=/var/lib/gssproxy/rcache klist Ticket cache: KEYRING:persistent:0:krb_ccache_AunlIbq Default principal: host/server.example.com(a)EXAMPLE.COM Valid starting Expires Service principal 1969-12-31 19:00:00 1969-12-31 19:00:00 Encrypted/Credentials/v1@X-GSSPROXY: What could cause the latter to not be getting any tickets like the former is? FWIW, the difference in ticket cache type appears to be due to: # cat /etc/krb5.conf.d/kcm_default_ccache # This file should normally be installed by your distribution into a # directory that is included from the Kerberos configuration file (/etc/krb5.conf) # On Fedora/RHEL/CentOS, this is /etc/krb5.conf.d/ # # To enable the KCM credential cache enable the KCM socket and the service: # systemctl enable sssd-secrets.socket sssd-kcm.socket # systemctl start sssd-kcm.socket # # To disable the KCM credential cache, comment out the following lines. [libdefaults] default_ccache_name = KCM: which is due to sssd-kcm-2.4.0-9.el8_4.2.x86_64 being installed on the working replica and not on the non-working replica. Maybe this is a big red herring though? Ultimately gssproxy is reporting the following when I try to log on to the webUI: [2022/02/05 16:08:51]: Debug Enabled (level: 3) [2022/02/05 16:08:51]: Service: ipa-httpd, Keytab: /var/lib/ipa/gssproxy/http.keytab, Enctype: 18 [2022/02/05 16:08:51]: Service: ipa-api, Keytab: /var/lib/ipa/gssproxy/http.keytab, Enctype: 18 [2022/02/05 16:08:51]: Service: ipa-sweeper, Keytab: /var/lib/ipa/gssproxy/http.keytab, Enctype: 18 [2022/02/05 16:08:51]: Service: nfs-server, Keytab: /etc/krb5.keytab, Enctype: 18 [2022/02/05 16:08:51]: Service: nfs-client, Keytab: /etc/krb5.keytab, Enctype: 18 [2022/02/05 16:08:51]: Client [2022/02/05 16:08:51]: (/usr/sbin/gssproxy) [2022/02/05 16:08:51]: connected (fd = 14)[2022/02/05 16:08:51]: (pid = 8306) (uid = 0) (gid = 0)[2022/02/05 16:08:51]: (context = system_u:system_r:kernel_t:s0)[2022/02/05 16:08:51]: [2022/02/05 16:08:59]: Client [2022/02/05 16:08:59]: (/usr/sbin/httpd) [2022/02/05 16:08:59]: connected (fd = 15)[2022/02/05 16:08:59]: (pid = 4266) (uid = 977) (gid = 973)[2022/02/05 16:08:59]: (context = system_u:system_r:httpd_t:s0)[2022/02/05 16:08:59]: [CID 15][2022/02/05 16:08:59]: [status] Handling query input: 0x55f111269810 (176) [CID 15][2022/02/05 16:08:59]: Connection matched service ipa-api [CID 15][2022/02/05 16:08:59]: [status] Processing request [0x55f111269810 (176)] [CID 15][2022/02/05 16:08:59]: [status] Executing request 6 (GSSX_ACQUIRE_CRED) from [0x55f111269810 (176)] [CID 15][2022/02/05 16:08:59]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "ipa-api", euid: 977,socket: (null) GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" [ ] } input_cred_handle: <Null> add_cred: 0 desired_name: { "brian(a)EXAMPLE.COM" { 1 2 840 113554 1 2 2 1 } [ ] [ ] [ ] } time_req: 4294967295 desired_mechs: { { 1 2 840 113554 1 2 2 } } cred_usage: INITIATE initiator_time_req: 0 acceptor_time_req: 0 ) GSSX_RES_ACQUIRE_CRED( status: { 851968 { 1 2 840 113554 1 2 2 } 2529639107 "Unspecified GSS failure. Minor code may provide more information" "No credentials cache found" [ ] } output_cred_handle: <Null> ) [CID 15][2022/02/05 16:08:59]: [status] Returned buffer 6 (GSSX_ACQUIRE_CRED) from [0x55f111269810 (176)]: [0x7fdf7c08a880 (176)] [CID 15][2022/02/05 16:08:59]: [status] Handling query output: 0x7fdf7c08a880 (176) [2022/02/05 16:08:59]: [status] Handling query reply: 0x7fdf7c08a880 (176) [2022/02/05 16:08:59]: [status] Sending data: 0x7fdf7c08a880 (176) [2022/02/05 16:08:59]: [status] Sending data [0x7fdf7c08a880 (176)]: successful write of 176 [CID 15][2022/02/05 16:08:59]: [status] Handling query input: 0x7fdf7c08a880 (176) [CID 15][2022/02/05 16:08:59]: Connection matched service ipa-api [CID 15][2022/02/05 16:08:59]: [status] Processing request [0x7fdf7c08a880 (176)] [CID 15][2022/02/05 16:08:59]: [status] Executing request 6 (GSSX_ACQUIRE_CRED) from [0x7fdf7c08a880 (176)] [CID 15][2022/02/05 16:08:59]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "ipa-api", euid: 977,socket: (null) GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" [ ] } input_cred_handle: <Null> add_cred: 0 desired_name: { "brian(a)EXAMPLE.COM" { 1 2 840 113554 1 2 2 1 } [ ] [ ] [ ] } time_req: 4294967295 desired_mechs: { { 1 2 840 113554 1 2 2 } } cred_usage: INITIATE initiator_time_req: 0 acceptor_time_req: 0 ) GSSX_RES_ACQUIRE_CRED( status: { 851968 { 1 2 840 113554 1 2 2 } 2529639107 "Unspecified GSS failure. Minor code may provide more information" "No credentials cache found" [ ] } output_cred_handle: <Null> ) [CID 15][2022/02/05 16:08:59]: [status] Returned buffer 6 (GSSX_ACQUIRE_CRED) from [0x7fdf7c08a880 (176)]: [0x7fdf7c066260 (176)] [CID 15][2022/02/05 16:08:59]: [status] Handling query output: 0x7fdf7c066260 (176) [2022/02/05 16:08:59]: [status] Handling query reply: 0x7fdf7c066260 (176) [2022/02/05 16:08:59]: [status] Sending data: 0x7fdf7c066260 (176) [2022/02/05 16:08:59]: [status] Sending data [0x7fdf7c066260 (176)]: successful write of 176 [2022/02/05 16:08:59]: Client [2022/02/05 16:08:59]: (/usr/sbin/httpd) [2022/02/05 16:08:59]: connected (fd = 16)[2022/02/05 16:08:59]: (pid = 4268) (uid = 977) (gid = 973)[2022/02/05 16:08:59]: (context = system_u:system_r:httpd_t:s0)[2022/02/05 16:08:59]: [CID 16][2022/02/05 16:08:59]: [status] Handling query input: 0x7fdf7c066260 (176) [CID 16][2022/02/05 16:08:59]: Connection matched service ipa-api [CID 16][2022/02/05 16:08:59]: [status] Processing request [0x7fdf7c066260 (176)] [CID 16][2022/02/05 16:08:59]: [status] Executing request 6 (GSSX_ACQUIRE_CRED) from [0x7fdf7c066260 (176)] [CID 16][2022/02/05 16:08:59]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "ipa-api", euid: 977,socket: (null) GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" [ ] } input_cred_handle: <Null> add_cred: 0 desired_name: { "brian(a)EXAMPLE.COM" { 1 2 840 113554 1 2 2 1 } [ ] [ ] [ ] } time_req: 4294967295 desired_mechs: { { 1 2 840 113554 1 2 2 } } cred_usage: INITIATE initiator_time_req: 0 acceptor_time_req: 0 ) GSSX_RES_ACQUIRE_CRED( status: { 851968 { 1 2 840 113554 1 2 2 } 2529639107 "Unspecified GSS failure. Minor code may provide more information" "No credentials cache found" [ ] } output_cred_handle: <Null> ) [CID 16][2022/02/05 16:08:59]: [status] Returned buffer 6 (GSSX_ACQUIRE_CRED) from [0x7fdf7c066260 (176)]: [0x7fdf7c05c9e0 (176)] [CID 16][2022/02/05 16:08:59]: [status] Handling query output: 0x7fdf7c05c9e0 (176) [2022/02/05 16:08:59]: [status] Handling query reply: 0x7fdf7c05c9e0 (176) [2022/02/05 16:08:59]: [status] Sending data: 0x7fdf7c05c9e0 (176) [2022/02/05 16:08:59]: [status] Sending data [0x7fdf7c05c9e0 (176)]: successful write of 176 [CID 16][2022/02/05 16:08:59]: [status] Handling query input: 0x7fdf7c05c9e0 (176) [CID 16][2022/02/05 16:08:59]: Connection matched service ipa-api [CID 16][2022/02/05 16:08:59]: [status] Processing request [0x7fdf7c05c9e0 (176)] [CID 16][2022/02/05 16:08:59]: [status] Executing request 6 (GSSX_ACQUIRE_CRED) from [0x7fdf7c05c9e0 (176)] [CID 16][2022/02/05 16:08:59]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "ipa-api", euid: 977,socket: (null) GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" [ ] } input_cred_handle: <Null> add_cred: 0 desired_name: { "brian(a)EXAMPLE.COM" { 1 2 840 113554 1 2 2 1 } [ ] [ ] [ ] } time_req: 4294967295 desired_mechs: { { 1 2 840 113554 1 2 2 } } cred_usage: INITIATE initiator_time_req: 0 acceptor_time_req: 0 ) GSSX_RES_ACQUIRE_CRED( status: { 851968 { 1 2 840 113554 1 2 2 } 2529639107 "Unspecified GSS failure. Minor code may provide more information" "No credentials cache found" [ ] } output_cred_handle: <Null> ) [CID 16][2022/02/05 16:08:59]: [status] Returned buffer 6 (GSSX_ACQUIRE_CRED) from [0x7fdf7c05c9e0 (176)]: [0x7fdf7c03f690 (176)] [CID 16][2022/02/05 16:08:59]: [status] Handling query output: 0x7fdf7c03f690 (176) [2022/02/05 16:08:59]: [status] Handling query reply: 0x7fdf7c03f690 (176) [2022/02/05 16:08:59]: [status] Sending data: 0x7fdf7c03f690 (176) [2022/02/05 16:08:59]: [status] Sending data [0x7fdf7c03f690 (176)]: successful write of 176 Cheers, b.

2 years, 3 months

2
8
0 / 0

"getent group -s sss" behaves differently on centos 7 vs centos 8. Why?

by Russell Jones

Hi all, I am very confused on why I am not able to enumerate the group members on a centos 8 machine with the above command, but I can on a centos 7 machine. [root@centos8-1 log]# getent group -s sss video video:x:39: [root@centos7-n11 log]# getent group -s sss video video:*:39:<lots of users> Both are configured with the same sssd.conf file, and both have "enumerate = True" in the domain section. In addition, if I just do "getent group" without the "-s sss" the group and all of its members show up properly on both machines. Super confused here. Thanks in advance for the help!

2 years, 3 months

2
3
0 / 0

Odd hostgroup behavior

by Stephen Berg (Code 7309)

I can't get a "getent netgroup ipaservers" to return the list of servers. Looking on the web UI my replica servers all show up in the ipaservers group. Using ipa hostgroup-show command line works. I set duplicate the group as "ipa" and getent can see that hostgroup like expected. Other hostgroups are working normally. Near as I can tell nsswitch.conf is good. Is there something about the ipaservers group that make it different from other groups? -- Stephen Berg, IT Specialist, Ocean Sciences Division, Code 7309 Naval Research Laboratory stephen.berg(a)nrlssc.navy.mil <- (Preferred contact) W: (228) 688-5738 DSN: (312) 823-5738 C: (228) 365-0162

2 years, 3 months

2
1
0 / 0

Freeipa Client fails with "CERTIFICATE_VERIFY_FAILED" when FreeIPA is behind a reverse proxy.

by Scion

I have recently been looking to authenticate Linux hosts with our FreeIPA server. I use a containerized FreeIPA server behind a Nginx Proxy Manager reverse proxy. I disable anonymous binding and forward all the LDAP and kerberos ports freeipa uses over streams through NPM. This has worked well for general usage and LDAP binding so far, but when I try to install the client with ipa-client-install I get the following error: Configured sudoers in /etc/nsswitch.conf Configured /etc/sssd/sssd.conf Configured /etc/krb5.conf for IPA realm MYREALM.NET cannot connect to 'https://freeipa.myrealm.net/ipa/json': [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1123) I do not get the same issue connecting directly to a fresh docker instance that is not behind Nginx Proxy Manager, but it occurs again when I try to put a reverse proxy in front of the server. The realm gets created, but the final configuration fails. What I assume is happening is that there is a mismatch between the SSL certificate used by LDAP/Kerberos and the one used over https, but I'm not totally sure. The debug information is sparse. The debug logs say the following: failed to find session_cookie in persistent storage for principal 'host/client.myrealm.net(a)MYREALM.NET' trying https://freeipa.myrealm.net/ipa/json Created connection context.rpcclient_140023518613568 [try 1]: Forwarding 'schema' to json server 'https://freeipa.myrealm.net/ipa/json' HTTP connection destroyed (freeipa.myrealm.net) I tried the --ca-cert-file flag, passing in the server's self-signed certificate, but that did not work either. Neither did installing it in the ca-certificates directory. Is there a way for me either pre-emptively install the certificate? Or am I going to need to definitely use the same non-self-signed certificate for the reverse proxy and the actual IPA server? Some additional things I've tried: - Updating & Upgrading - Using the server's self-signed certificate in NPM (gives a self-signed cert error) - Using no certificate in NPM (gives the sam self-signed error) - Using the name of the Freeipa host machine (connects, but a cert for the hostname isn't found)

2 years, 3 months

1
1
0 / 0

Case sensitivity?

by Simon Matthews

Why does ipa-client install require that the hostname be lower case? Hostnames are case-insensitive. Shouldn't IPA follow this and be case-insensitive?

2 years, 3 months

2
1
0 / 0

IPA DNS listing

by Stephen Berg, Code 7309

Running ipa-4.9.6 on rocky linux 8.5. I'm currently setting up the DNS stuff and don't see a way to list DNS records in IP address order. The web UI doesn't feature a sorting option and from the command line I haven't found any option to sort the output. Is this not possible right now or am I missing a command or option somewhere? -- Stephen Berg, IT Specialist, Ocean Sciences Division, Code 7309 Naval Research Laboratory W: (228) 688-5738 DSN: (312) 823-5738 C: (228) 365-0162 Email: stephen.berg(a)nrlssc.navy.mil <- (Preferred contact) Flank Speed: stephen.p.berg.civ(a)us.navy.mil

2 years, 3 months

2
1
0 / 0

SPNEGO cannot find mechanisms to negotiate

by Brian J. Murrell

On my fairly recently created replica, trying to sign on to the webUI fails both with a ticket and with username/password. The httpd error log reports: [Thu Feb 03 09:43:20.551081 2022] [wsgi:error] [pid 332932:tid 140681111185152] [remote 2001:123:aa:123:0:90cc:a629:cf42:5877:50870] ipa: INFO: [jsonserver_i18n_messages] UNKNOWN: i18n_messages(version='2.237'): SUCCESS [Thu Feb 03 09:43:21.096431 2022] [auth_gssapi:error] [pid 332935:tid 140680940726016] [client 2001:123:aa:123:0:90cc:a629:cf42:5877:50870] Failed to unseal session data!, referer: https://server.example.com/ipa/ui/ [Thu Feb 03 09:43:21.146884 2022] [auth_gssapi:error] [pid 332935:tid 140681090156288] [client 2001:123:aa:123:0:90cc:a629:cf42:5877:50870] Failed to unseal session data!, referer: https://server.example.com/ipa/ui/ [Thu Feb 03 09:43:21.605055 2022] [auth_gssapi:error] [pid 332935:tid 140681090156288] [client 2001:123:aa:123:0:90cc:a629:cf42:5877:50870] GSS ERROR gss_acquire_cred[_from]() failed to get server creds: [Unspecified GSS failure. Minor code may provide more information ( SPNEGO cannot find mechanisms to negotiate)], referer: https://server.example.com/ipa/ui/ [Thu Feb 03 09:43:21.621376 2022] [auth_gssapi:error] [pid 332935:tid 140680923940608] [client 2001:123:aa:123:0:90cc:a629:cf42:5877:50870] Failed to unseal session data!, referer: https://server.example.com/ipa/ui/ [Thu Feb 03 09:43:21.672265 2022] [auth_gssapi:error] [pid 332935:tid 140680907155200] [client 2001:123:aa:123:0:90cc:a629:cf42:5877:50870] Failed to unseal session data!, referer: https://server.example.com/ipa/ui/ [Thu Feb 03 09:43:22.019527 2022] [auth_gssapi:error] [pid 332935:tid 140680907155200] [client 2001:123:aa:123:0:90cc:a629:cf42:5877:50870] GSS ERROR gss_acquire_cred[_from]() failed to get server creds: [Unspecified GSS failure. Minor code may provide more information ( SPNEGO cannot find mechanisms to negotiate)], referer: https://server.example.com/ipa/ui/ I found some google hits on gssproxy being the culprit but I can't seem to find anything wrong with it. It's not logging any errors or such. Any ideas on what the problem could be here? Cheers, b.

2 years, 3 months

1
1
0 / 0

IPA WebUI login fails

by iulian roman

Hello everybody, If I try to login via WebUI with an AD account , i get the following error: 'Your session has expired. Please log in again.' in the WebUI interface. I the http access logs i have the following entry: user(a)EXAMPLE.LOCAL [03/Feb/2022:14:54:13 +0100] "POST /ipa/session/json HTTP/1.1" 401 176 user(a)EXAMPLE.LOCAL [03/Feb/2022:14:54:13 +0100] "GET /ipa/session/login_kerberos?_=1643896292999 HTTP/1.1" 401 262 On the http error_log: [Thu Feb 03 14:54:13.466436 2022] [wsgi:error] [pid 1835110:tid 140666734245632] [remote 10.8.137.41:58079] ipa: INFO: 401 Unauthorized: Insufficient access: Invalid credentials [Thu Feb 03 14:54:13.472887 2022] [:warn] [pid 1837963:tid 140666084521728] [client 10.8.137.41:58079] failed to set perms (3140) on file (/run/ipa/ccaches/user(a)EXAMPLE.LOCAL)!, referer: https://xxx.ipa.example.local/ipa/ui/ [Thu Feb 03 14:54:13.477997 2022] [wsgi:error] [pid 1835109:tid 140666733983488] [remote 10.8.137.41:58079] ipa: INFO: 401 Unauthorized: Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (108962060): Credential cache is empty In the krb5kdc.log : Feb 03 14:54:13 xxxipaprd04.ipa.example.local krb5kdc[3151688](info): AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19), ca mellia128-cts-cmac(25)}) 10.30.200.220: REFERRAL: user\@EXAMPLE.local(a)IPA.EXAMPLE.LOCAL for krbtgt/IPA.EXAMPLE.LOCAL(a)IPA.EXAMPLE.LOCAL, Realm not local to KDC Feb 03 14:54:13 xxxipaprd04.ipa.example.local krb5kdc[3151688](info): closing down fd 12 Feb 03 14:54:13 xxxipaprd04.ipa.example.local krb5kdc[3151688](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19), c amellia128-cts-cmac(25)}) 10.30.200.220: ISSUE: authtime 1643896453, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, user(a)EXAMPLE.LOCAL for HTTP/xxxipaprd04.ipa.example.local@IPA. EXAMPLE.LOCAL Feb 03 14:54:13 xxxipaprd04.ipa.example.local krb5kdc[3151688](info): closing down fd 12 Feb 03 14:54:13 xxxipaprd04.ipa.example.local krb5kdc[3151688](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19), c amellia128-cts-cmac(25)}) 10.30.200.220: ISSUE: authtime 1643896453, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, HTTP/xxxipaprd04.ipa.example.local(a)IPA.EXAMPLE.LOCAL for ldap/c xxxipaprd04.ipa.example.local(a)IPA.EXAMPLE.LOCAL Feb 03 14:54:13 xxxipaprd04.ipa.example.local krb5kdc[3151688](info): ... CONSTRAINED-DELEGATION s4u-client=user(a)EXAMPLE.LOCAL Any help would be really appreciated. Regards, iulian roman

2 years, 3 months

3
4
0 / 0

Re: Unable to use externa groups or users, truster domain object not found

by Mike Moser

Ran into the same issue, sharing this as it solved the issue for me: https://access.redhat.com/solutions/3656641 [Logo Description automatically generated] Michael S. Moser Sr. Linux Administrator, Aires Office 1.412.677.1851 ● Mobile 412.719.7765 [cid:image002.png@01D81830.EDD86BB0]<https://www.aires.com/> [cid:image003.png@01D81830.EDD86BB0]<https://www.linkedin.com/in/michaelsmoser/> [cid:image004.png@01D81830.EDD86BB0]<mailto:mmoser@aires.com> CONFIDENTIALITY NOTICE -- This email produced by Aires, including any accompanying attachment(s), is intended only for the person(s) designated above. Unless otherwise indicated, it contains information that is confidential, privileged and/or exempt from disclosure under applicable law. If you have received this message in error, please notify the sender and delete the message. If the reader of this message is not the intended recipient, you are hereby notified that any use of this communication is strictly prohibited.

2 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users February 2022