AllowUsers/Groups on ipa clients
by Sam Morris
On non-IPA clients I'm using AllowUsers/AllowGroups to restrict which
local users are able to SSH into a system.
On IPA clients I am using HBAC to control the same for IPA users. But
what's the best way to control which local users can SSH in to an IPA
client?
It looks like I could modify the ipausers group to be a POSIX group, and
then put 'AllowGroups ipausers' into sshd_config. That way all local
users would be denied, and all IPA suers would be allowed, with
pam_sss.so later controlling access based on HBAC.
Alternatively modifying PAM services to use pam_access.so and/or to
remove pam_localuser.so could work, but that seems a lot more
complicated, since the system-auth PAM config is managed by authselect,
and is included by all sorts of other services...
Are there any better alternatives?
Hm, now that I think about it, I'd like to be doing this for cockpit as
well. I suppose pam_wheel or pam_succeed_if can be used in
/etc/pam.d/cockpit, together with a POSIX ipausers group for this purpose.
--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
3 weeks, 6 days
How to use ipa-dsu
by Duarte Petiz
Hello freeipa users!
I'm trying to follow the guide that is available here: https://freeipa.readthedocs.io/en/latest/designs/disable-stale-users.html about ipa-dsu.
I was trying to do a dry-run in order to check what it really does on my env but the package seems to not be present.
I'm using the freeipa-server:rocky-9 docker image.
root@prod-us-freeipa:~# docker exec -ti ipa_freeipa_1 bash
[root@prod-us-freeipa /]# ipa-dsu --dry-run
bash: ipa-dsu: command not found
What could I do?
Regards
3 weeks, 6 days
EL9.4, 2FA and sudo
by Sigbjorn Lie-Soland
Hi,
All 2FA enabled users are now required to use 2FA after our EL9 clients we’re updated to EL 9.4.
Downgrading sssd from sssd-2.9.4-6.el9_4.x86_64 to sssd-2.9.4-2.el9.x86_64 fixes the issue, so the error happened between there two releases somehow.
No "Authentication indicators” has been configured for the hosts in question. It is reproducable across all our EL9 machines.
In the krb5_child.log the following backtrace is logged when a 2FA enabled user tries to use sudo. This backtrace does not happen on EL9 client where sssd has been downgraded.
==> krb5_child.log <==
(2024-05-27 20:07:57): [krb5_child[478251]] [unpack_buffer] (0x0100): [RID#1047] cmd [241 (auth)] uid [693200437] gid [693200437] validate [true] enterprise principal [true] offline [false] UPN [ipausername(a)IPADOMAIN.NET]
(2024-05-27 20:07:57): [krb5_child[478251]] [unpack_buffer] (0x0100): [RID#1047] ccname: [KCM:] old_ccname: [KCM:] keytab: [/etc/krb5.keytab]
(2024-05-27 20:07:57): [krb5_child[478251]] [switch_creds] (0x0200): [RID#1047] Switch user to [693200437][693200437].
(2024-05-27 20:07:57): [krb5_child[478251]] [switch_creds] (0x0200): [RID#1047] Switch user to [0][0].
(2024-05-27 20:07:57): [krb5_child[478251]] [k5c_setup_fast] (0x0100): [RID#1047] Fast principal is set to [host/host.domain.net(a)IPADOMAIN.NET]
(2024-05-27 20:07:57): [krb5_child[478251]] [check_fast_ccache] (0x0200): [RID#1047] FAST TGT is still valid.
(2024-05-27 20:07:57): [krb5_child[478251]] [become_user] (0x0200): [RID#1047] Trying to become user [693200437][693200437].
(2024-05-27 20:07:57): [krb5_child[478251]] [set_lifetime_options] (0x0100): [RID#1047] No specific renewable lifetime requested.
(2024-05-27 20:07:57): [krb5_child[478251]] [set_lifetime_options] (0x0100): [RID#1047] No specific lifetime requested.
(2024-05-27 20:07:57): [krb5_child[478251]] [set_canonicalize_option] (0x0100): [RID#1047] Canonicalization is set to [true]
(2024-05-27 20:07:57): [krb5_child[478251]] [get_and_save_tgt] (0x0020): [RID#1047] 2350: [-1765328360][Preauthentication failed]
********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE:
* (2024-05-27 20:07:57): [krb5_child[478251]] [main] (0x0400): [RID#1047] krb5_child started.
* (2024-05-27 20:07:57): [krb5_child[478251]] [unpack_buffer] (0x1000): [RID#1047] total buffer size: [115]
* (2024-05-27 20:07:57): [krb5_child[478251]] [unpack_buffer] (0x0100): [RID#1047] cmd [241 (auth)] uid [693200437] gid [693200437] validate [true] enterprise principal [true] offline [false] UPN [ipausername(a)IPADOMAIN.NET]
* (2024-05-27 20:07:57): [krb5_child[478251]] [unpack_buffer] (0x0100): [RID#1047] ccname: [KCM:] old_ccname: [KCM:] keytab: [/etc/krb5.keytab]
* (2024-05-27 20:07:57): [krb5_child[478251]] [switch_creds] (0x0200): [RID#1047] Switch user to [693200437][693200437].
* (2024-05-27 20:07:57): [krb5_child[478251]] [switch_creds] (0x0200): [RID#1047] Switch user to [0][0].
* (2024-05-27 20:07:57): [krb5_child[478251]] [k5c_check_old_ccache] (0x4000): [RID#1047] Ccache_file is [KCM:] and is active and TGT is valid.
* (2024-05-27 20:07:57): [krb5_child[478251]] [k5c_setup_fast] (0x0100): [RID#1047] Fast principal is set to [host/host.domain.net(a)IPADOMAIN.NET]
* (2024-05-27 20:07:57): [krb5_child[478251]] [find_principal_in_keytab] (0x4000): [RID#1047] Trying to find principal host/host.domain.net(a)IPADOMAIN.NET in keytab.
* (2024-05-27 20:07:57): [krb5_child[478251]] [match_principal] (0x1000): [RID#1047] Principal matched to the sample (host/host.domain.net(a)IPADOMAIN.NET).
* (2024-05-27 20:07:57): [krb5_child[478251]] [check_fast_ccache] (0x0200): [RID#1047] FAST TGT is still valid.
* (2024-05-27 20:07:57): [krb5_child[478251]] [become_user] (0x0200): [RID#1047] Trying to become user [693200437][693200437].
* (2024-05-27 20:07:57): [krb5_child[478251]] [main] (0x2000): [RID#1047] Running as [693200437][693200437].
* (2024-05-27 20:07:57): [krb5_child[478251]] [set_lifetime_options] (0x0100): [RID#1047] No specific renewable lifetime requested.
* (2024-05-27 20:07:57): [krb5_child[478251]] [set_lifetime_options] (0x0100): [RID#1047] No specific lifetime requested.
* (2024-05-27 20:07:57): [krb5_child[478251]] [set_canonicalize_option] (0x0100): [RID#1047] Canonicalization is set to [true]
* (2024-05-27 20:07:57): [krb5_child[478251]] [main] (0x0400): [RID#1047] Will perform auth
* (2024-05-27 20:07:57): [krb5_child[478251]] [main] (0x0400): [RID#1047] Will perform online auth
* (2024-05-27 20:07:57): [krb5_child[478251]] [tgt_req_child] (0x1000): [RID#1047] Attempting to get a TGT
* (2024-05-27 20:07:57): [krb5_child[478251]] [get_and_save_tgt] (0x0400): [RID#1047] Attempting kinit for realm [IPADOMAIN.NET]
* (2024-05-27 20:07:57): [krb5_child[478251]] [sss_krb5_responder] (0x4000): [RID#1047] Got question [otp].
* (2024-05-27 20:07:57): [krb5_child[478251]] [get_and_save_tgt] (0x0020): [RID#1047] 2350: [-1765328360][Preauthentication failed]
********************** BACKTRACE DUMP ENDS HERE *********************************
(2024-05-27 20:07:57): [krb5_child[478251]] [map_krb5_error] (0x0020): [RID#1047] 2479: [-1765328360][Preauthentication failed]
(2024-05-27 20:07:57): [krb5_child[478251]] [k5c_send_data] (0x0200): [RID#1047] Received error code 1432158222
Is this a known issue?
Regards,
Siggi
4 weeks
ipa-setup-ca
by Omar Pagan
Hey guys,
I finished installing two replicas of my master. Both installations of the replicas completed successfully, but when I try to run the ipa-setup-ca it is having some issues.
The errors I get are:
ipaserver.install.dogtaginstance: CRITICAL Failed to configure CA instance
ipaserver.install.dogtaginstance: CRITICAL See the installation logs and the following files/directories for more information:
ipaserver.install.dogtaginstance: CRITICAL /var/log/pki/pki-tomcat
[error] RuntimeError: CA configuration failed.
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
But I don't see any issues in the /var/log/pki/pki-tomcat, or at least I can't find any "CRITICAL" errors. Please advise on how to confirm that the master CA is working properly and perhaps how to get the 2 replicas to also help with the ca role. Thanks
1 month
Replica re-initialization failing Replication bind with GSSAPI auth failed: LDAP error 49 (Invalid credentials) ()
by Tania Hagan
Hi Freeipa users,
I have a replica that has been failing replication for a while, so I have tried the following command to re-initialize (a back up of the server did not work):
ipa-replica-manage -vd re-initialize --from healthly.ipa.server
On the replica that I run this command I just see Update in progress, 1606 seconds elapsed from the above command.
I see no errors in /var/log/dirsrv/slapd/errors on the replica, but on the healthy.ipa.server after 1000 seconds elapsed I see: ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=healthy.ipa.server-to-unhealthly.ipa.server" (unhealty:389) - Replication bind with GSSAPI auth failed: LDAP error 49 (Invalid credentials) ()
Any ideas how I can overcome this issue?
Many Thanks,
Tania
1 month
NFS4 kerberos auth for local services
by Djerk Geurts
Hi all,
Judging by my online searches, I’m far from the first to ask the question, but I’m keft with holes in my understanding of Kerberos and how services can authenticate via Kerberos (keytab).
I’m switching from sec=sys to sec=krb5p and either way struggle with local services which must place files on an NFS share for backup purposes. Using sec=sys things just work but the uid/gid numbers get matched locally and this often worked fine (when local services used the same aid/gid. But this doesn’t scale well, so I’m looking for ways to deal with this.
One way is to create a user in FreeIPA with the name of the service (for example bhsvc for Nakivo backup), and then adjust the uid on the local server to the IPA issued one, which is quick. But requires finding any file with the old id and changing it to the new one, which can be time consuming.
As the nfs client is a 3CX server, which don’t do well when manually configured as 3CX treat them as appliances. (God forbid someone might want to centrally manage these beast…); I would prefer not to change the uid of the local system account (phonesystem) to an IPA assigned one.
What are my options?
Despite finding how to configure gssproxy, I don’t yet understand how a daemon running as a certain user is mapped to an SPN with related keytab. Creating an SPN in IPA is easy, but how does the nfs-client know that a local system account should use/fetch a keytab for a certain SPN?
I could just manually set the uid of the local user on the nfs server, but while this worked with sec=sys, I don’t think this works with sec=krb5. So an option is to revert to sec=system, but I’d prefer not to.
The gssproxy config I created for the 3cxpbx daemon(s):
user@3cx04:~$ cat /etc/gssproxy/00-3cxpbx.conf
[service/3CXPBX]
mechs = krb5
cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_3cxpbx
cred_store = client_keytab:/var/lib/gssproxy/clients/3cxpbx.keytab
cred_usage = initiate
euid = 998
--
Thanks,
Djerk Geurts
1 month
update clients dns records
by Dmitry Krasov
Hello.
How can I update clients dns records automatically, without setup of DHCP server?
1 month
pki-tomcatd not starting
by Omar Pagan
Hello,
I came back from vacation and noticed that the pki-tomcatd was not running. All other services are running fine, I can kinit admin and search for users, I can also log into the UI and see everything. When I try to start the service I see the following errors:
Mar 11 20:44:44 ldap01.app.uaap.maxar.com ipa-pki-wait-running[7903]: ipa-pki-wait-running: Request failed unexpectedly, 404 Client Error: for url: http://ldap01.app.uaap.maxar.com:8080/ca/admin/ca/getStat>
Mar 11 20:44:44 ldap01.app.uaap.maxar.com systemd[1]: pki-tomcatd(a)pki-tomcat.service: Start-post operation timed out. Stopping.
I have checked all the certs and everything is in order:
$ getcert list | grep expire
expires: 2025-01-22 14:07:35 UTC
expires: 2025-01-22 14:06:46 UTC
expires: 2025-01-22 14:06:45 UTC
expires: 2025-01-22 14:06:45 UTC
expires: 2043-02-02 14:06:44 UTC
expires: 2025-01-22 14:06:45 UTC
expires: 2025-02-02 14:08:10 UTC
I also have checked this:
$ klist -ekt /etc/dirsrv/ds.keytab
Keytab name: FILE:/etc/dirsrv/ds.keytab
KVNO Timestamp Principal
---- ------------------- ------------------------------------------------------
2 02/02/2023 14:06:06 ldap/ldap01.app.uaap.maxar.com(a)APP.UAAP.MAXAR.COM (aes256-cts-hmac-sha1-96)
2 02/02/2023 14:06:06 ldap/ldap01.app.uaap.maxar.com(a)APP.UAAP.MAXAR.COM (aes128-cts-hmac-sha1-96)
2 02/02/2023 14:06:06 ldap/ldap01.app.uaap.maxar.com(a)APP.UAAP.MAXAR.COM (aes128-cts-hmac-sha256-128)
2 02/02/2023 14:06:06 ldap/ldap01.app.uaap.maxar.com(a)APP.UAAP.MAXAR.COM (aes256-cts-hmac-sha384-192)
2 02/02/2023 14:06:06 ldap/ldap01.app.uaap.maxar.com(a)APP.UAAP.MAXAR.COM (camellia128-cts-cmac)
2 02/02/2023 14:06:06 ldap/ldap01.app.uaap.maxar.com(a)APP.UAAP.MAXAR.COM (camellia256-cts-cmac)
not sure if that's correct or not. Please help, I don't see why pki-tomcatd would just die on me for no reason. I haven't run any updates / upgrades on the system and it was working fine before I left. Thanks
1 month
KDC Self Signed Certificate Creation
by Mark Selby
My company has 6 FreeIPA servers across 3 different locations. Five of the six servers are ok, but one we could not login to. The error messages pointed to the expired certificate located at `/var/kerberos/krb5kdc/kdc.crt`
My question is how do I "properly" renew or recreate this certificate. I have been able to renew it with the command listed below - but the renewed cert does not have the same characteristics as the other certs. The existing ones all see to be self signed with the specified profile while my new one does not have these features. It seems to be working Ok but it would great to understand how to generate this cert correctly. All is any help is greatly appreciated.
The servers that work all display the following with using getcert list -f /var/kerberos/krb5kdc/kdc.crt
Request ID '20191003181545':
status: MONITORING
stuck: no
key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key'
certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt'
CA: SelfSign
issuer: CN=ipa01.sub1.acme.org,O=ACME.ORG
subject: CN=ipa01.sub1.acme.org,O=ACME.ORG
expires: 2022-08-09 22:06:33 UTC
principal name: krbtgt/ACME.ORG(a)ACME.ORG
certificate template/profile: KDCs_PKINIT_Certs
pre-save command:
post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert
track: yes
auto-renew: yes
Using the local-getcert start-tracking command below gets me an updated cert but it is not self signed and does not have the specified profile.
local-getcert start-tracking \
-k /var/kerberos/krb5kdc/kdc.key \
-f /var/kerberos/krb5kdc/kdc.crt \
-T KDCs_PKINIT_Certs \
-C /usr/libexec/ipa/certmonger/renew_kdc_cert
Request ID '20220117193849':
status: MONITORING
stuck: no
key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key'
certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt'
CA: local
issuer: CN=Certificate Authority,O=ACME.ORG
subject: CN=vipa06.sub3.acme.org,O=ACME.ORG
expires: 2024-01-18 17:32:20 UTC
principal name: krbtgt/ACME.ORG(a)ACME.ORG
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-pkinit-KPKdc
pre-save command:
post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert
track: yes
auto-renew: yes
1 month
