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
2 hours, 51 minutes
when 2FA enabled, with 2 factor prompt asking doesn't work
by seojeong kim
on server side, ipauserauthtype set as password + otp.
[root@xxxxxx /]# ipa user-show ereen-test --raw | grep ipauserauthtype
ipauserauthtype: password
ipauserauthtype: otp
And I added new configuration in /etc/ssh/sshd_config on my host which is ipa client is installed.
GSSAPIAuthentication yes
And /etc/sssd/sssd.conf
[prompting/password/sshd]
password_prompt = password :
[prompting/2fa/sshd]
first_prompt = first pwd :
second_prompt = second otp :
But all the time, when I try ssh login with ereen-test, the prompt asks "password :"
I expect 2 factor asking as I configured like below
first_prompt :
second_prompt :
Is there other configuration should I set more ?
10 hours, 25 minutes
update clients dns records
by Dmitry Krasov
Hello.
How can I update clients dns records automatically, without setup of DHCP server?
13 hours, 26 minutes
Reinitializing isolated replica with updated certificate
by William Faulk
I have an IdM replica that stopped sending its replications to the other replicas in the environment. I want to reinitialize it to hopefully resolve that replication problem. However, when confirming what data would be lost in the reinitialization, I noticed that the replica has reissued itself certificates for its own LDAP and HTTP services. These certificates are the ones found in the "userCertificate" attributes of the "krbprincipalname=ldap/isolated-replica(a)EXAMPLE.COM,cn=services,cn=accounts,dc=example,dc=com" and "krbprincipalname=HTTP/isolated-replica(a)EXAMPLE.COM,cn=services,cn=accounts,dc=example,dc=com" DNs. The other replicas show the older certificates in those multivalue entries, but not the new ones. In addition, the previous certificates have now expired.
I'm concerned about what will happen if I perform a reinitialization of this replica. Will it restart its LDAP and HTTP services with an old, expired certificate? What effect will that have on other replicas trying to connect to it? Will it still have keys for those old certificates? Will it be able to reissue its certificates again? The existence of the "ipa-cert-fix" utility implies not.
Or will it keep its new certificates? Will those certificates cause a problem when they no longer exist in the replica's own domain database?
The replica in question will still accept replications from the rest of the environment. Is it possible to get another replica to push new certificates to it, so that that new certificate will exist in the domain database after a reinitialization happens?
This is all in an IdM environment run under RHEL 7.9, so FreeIPA 4.6.8. (I'm desperately trying to dig myself out of replication problems before I upgrade. This is the next-to-last issue.)
--
William Faulk
22 hours, 28 minutes
Questions about replica
by Dmitry Krasov
Hello.
just installed replica (ipa2.dom.loc), it seems works fine.
But how enrolled clients will know about this replica, if primary server will be down?
And how to make ipa2.dom.loc to work as primary server?
1 day, 3 hours
Freel IPA on CentOS CA_UNREACHABLE Error - kerberos
by girish f
We have one new customer, they have setup of one single node of IPA on CentOS.
There certificate is expired, and everthing went down.
When we are trying to bring services up.
pki_tomcatd is not starting, another thing is
When we run command > ipactl-getcerts list
One of the certificate is shwoing CA_Unreachable and getting error:
/var/kerberos/krb5kdc/kdc.crt /var/kerberos/krb5kdc/kdc.key
enter image description here
Created new certificate and CA -> it loads certificate, new dates it shows but still says CA unreachable.
1 day, 3 hours
when 2FA enabled, with 2 factor prompt asking doesn't work
by seojeong kim
on server side, ipauserauthtype set as password + otp.
[root@xxxxxx /]# ipa user-show ereen-test --raw | grep ipauserauthtype
ipauserauthtype: password
ipauserauthtype: otp
And I added new configuration in /etc/ssh/sshd_config on my host which is ipa client is installed.
GSSAPIAuthentication yes
And /etc/sssd/sssd.conf
[prompting/password/sshd]
password_prompt = password :
[prompting/2fa/sshd]
first_prompt = first pwd :
second_prompt = second otp :
But all the time, when I try ssh login with ereen-test, the prompt asks "password :"
I expect 2 factor asking as I configured like below
first_prompt :
second_prompt :
Is there other configuration should I set more ?
1 day, 11 hours
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
3 days, 7 hours
Freel IPA on CentOS CA_UNREACHABLE Error - kerberos
by girish f
We have one new customer, they have setup of one single node of IPA on CentOS.
There certificate is expired, and everthing went down.
When we are trying to bring services up.
pki_tomcatd is not starting, another thing is
When we run command > ipactl-getcerts list
One of the certificate is shwoing CA_Unreachable and getting error:
/var/kerberos/krb5kdc/kdc.crt /var/kerberos/krb5kdc/kdc.key
enter image description here
Created new certificate and CA -> it loads certificate, new dates it shows but still says CA unreachable.
3 days, 7 hours
ipa-ca-install failed
by Satish Patel
Folks,
Trying to deploy CA on a replica node and failed here without any
information. Can I restart the process again? Even log directories are
empty /var/log/pki/pki-tomcat
My OS is RockyLunux 8.9 and Master CA running on CentOS7.x
[root@ldap-vx-010103-3 ~]# ipa-ca-install
Directory Manager (existing master) password:
Run connection check to master
Connection check OK
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
[1/28]: creating certificate server db
[2/28]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 161 seconds elapsed
Update succeeded
[3/28]: creating ACIs for admin
[4/28]: creating installation admin user
[5/28]: configuring certificate server instance
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.
CA configuration failed.
4 days, 3 hours