KRB5KDC Service crashing with core dump
by Ash Ryder
Hello Guys,
I am having a bit of trouble keeping the krb5kdc service up for longer than 10mins. I have
just installed Free IPA on our windows domain and can authenticate when the service is up
to the IPA server with my windows credentials.
I have just installed the development tools to run GBD but i am having issues.. is someone able to please advise how to obtain a backtrace? with a simple guide? I'm not that Linux savvy yet :)
The service errors with the following:
Loaded: loaded (/usr/lib/systemd/system/krb5kdc.service; disabled; vendor preset:
disabled)
Active: failed (Result: core-dump) since Mon 2021-04-26 10:09:02 AEST; 3h 55min ago
Process: 139132 ExecStart=/usr/sbin/krb5kdc -P /var/run/krb5kdc.pid $KRB5KDC_ARGS
(code=exited, status=0/SUCCESS)
Main PID: 139136 (code=dumped, signal=ABRT)
LOG SSD_Example.com shows this around the same time the service stops
(2021-04-26 10:08:53): [be[linux.example.com]] [sdap_id_conn_data_expire_handler]
(0x0080): connection is about to expire, releasing it
(2021-04-26 10:09:01): [be[linux.example.com]] [sasl_bind_send] (0x0020): ldap_sasl_bind
failed (-2)[Local error]
(2021-04-26 10:09:01): [be[example.com]] [sasl_bind_send] (0x0080): Extended failure
message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code
may provide more information (Cannot contact any KDC for realm
'LINUX.EXAMPLE.COM')]
KRB5KDC.LOG
Apr 26 10:09:01 IPA01.linux.example.com krb5kdc[139141](info): AS_REQ (7 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), camellia128-cts-cmac(25),
DEPRECATED:arcfour-hmac(23)}) 10.2.0.208: NEEDED_PREAUTH:
host/IPA01.linux.example.com(a)LINUX.EXAMPLE.COM for
krbtgt/LINUX.EXAMPLE.COM(a)LINUX.EXAMPLE.COM, Additional pre-authentication required
Apr 26 10:09:01 IPA01.linux.example.com krb5kdc[139141](info): closing down fd 12
Apr 26 10:09:01 IPA01.linux.example.com krb5kdc[139136](Error): worker 139142 exited with
status 134
Apr 26 10:09:01 IPA01.linux.example.com krb5kdc[139141](info): AS_REQ (7 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), camellia128-cts-cmac(25),
DEPRECATED:arcfour-hmac(23)}) 10.2.0.208: ISSUE: authtime 1619395741, etypes
{rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18),
ses=aes256-cts-hmac-sha1-96(18)}, host/IPA01.linux.example.com(a)LINUX.EXAMPLE.COM for
krbtgt/LINUX.EXAMPLE.COM(a)LINUX.EXAMPLE.COM
Apr 26 10:09:01 IPA01.linux.example.com krb5kdc[139141](info): closing down fd 11
Apr 26 10:09:01 IPA01.linux.example.com krb5kdc[139141](info): closing down fd 10
Apr 26 10:09:01 IPA01.linux.example.com krb5kdc[139141](info): closing down fd 9
Apr 26 10:09:01 IPA01.linux.example.com krb5kdc[139141](info): closing down fd 8
Apr 26 10:09:01 IPA01.linux.example.com krb5kdc[139141](info): shutting down
Apr 26 10:09:01 IPA01.linux.example.com krb5kdc[139141](info): IPA certauth plugin
un-loaded.
Thank in advance,
Ash
2 years, 11 months
Use of certificates to have https secure connection
by guille.colmena@gmail.com
Hello,
I have run that command and I get the following message. The file
doesn't exist.
certutil -L -d /etc/httpd/alias -n Server-Cert
certutil: Could not find cert: Server-Cert
: PR_FILE_NOT_FOUND_ERROR: File not found
Not sure what to do next.
Also is here where I can find the passphrase?
cat /etc/ipa/nssdb/pwdfile.txt
Thank you for your help,
gcol
2 years, 11 months
general question - replication of master
by Sinh Lam
Hi -
General question. I would like to add freeradius to freeipa. Currently we
have a single master with multiple replicas at various sites. Will
replication break if I only add freeradius to the master but not to the
various sites?
Thanks.
Sinh
2 years, 11 months
Dovecot integration, expired password as well as if over quota login notice; local user can't login
by Robert Kudyba
As I continue to test FreeIPA, freeipa-server-4.9.3-1, on Fedora 33 I've
run into the following issues with web mail and Dovecot integration.
1. I followed
https://www.freeipa.org/page/Dovecot_IMAPS_Integration_with_FreeIPA_using...
but I couldn't get web mail to login until I used the suggestion from
https://blog.delouw.ch/2017/02/19/integrate-dovecot-imap-with-freeipa-usi...
and changed logins auth_mechanisms = plain gssapi login
2. even with auth_mechanisms = plain gssapi login, I could then no longer
login to webmail with any local Unix (non-Kerberized) users.
The dovecot logs show:
auth: Error: policy(localuser(a)ourdomain.edu,127.0.0.1,<r2eFe+PAvut/AAAB>):
Policy server HTTP error: connect(x.x.x.x:8084) failed: Connection refused
auth: Debug: policy(localuser(a)ourdomain.edu,127.0.0.1,<r2eFe+PAvut/AAAB>):
Policy report action finished
auth: Debug: http-client[1]: request [Req2: POST
https://x.x.x.x:8084/?command=report]: Destroy (requests left=1)
auth: Debug: http-client[1]: request [Req2: POST
https://x.x.x.x:8084/?command=report]: Free (requests left=0)
auth: Debug: http-client: conn x.x.x.x[2]: Connection close
auth: Debug: http-client: conn x.x.x.x[2]: Connection disconnect
auth: Debug: http-client: conn x.x.x.x[2]: Disconnected: connect() failed:
Connection refused (fd=23)
auth: Debug: http-client: conn x.x.x.x[2]: Detached peer
auth: Debug: http-client: conn x.x.x.x[2]: Connection destroy
auth: Debug: http-client: host x.x.x.x: Idle host timed out
auth: Debug: http-client: host x.x.x.x: Host destroy
auth: Debug: http-client: host x.x.x.x: Host session destroy
auth: Debug: http-client[1]: queue https://x.x.x.x:8084: Destroy
auth: Debug: client passdb out: FAIL 1 user=localuser(a)ourdomain.edu
original_user=localuser
imap-login: Debug: Ignoring unknown passdb extra field: original_user
imap-login: Info: Aborted login (auth failed, 1 attempts in 3 secs): user=<
localuser(a)ourdomain.edu>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1,
secured, session=<r2eFe+PAvut/AAAB>
3. If a user was over quota there was no way to tell on the webmail page
that they were over quota but the dovecot logs show imap(ouruser): Error:
mkdir(/path/to/ouruser/mail/.imap) failed: Disk quota exceeded
Is this more of a Dovecot and webmail issue? Would there be a security risk
if the web page displayed a warning that could be generalized to inform the
user to either check their quota or password reset being needed?
2 years, 11 months
GSSAPI Error with AD trust
by iulian roman
I have an IPA setup with replica which has trust configured with an Active Directory domain. The trust has been configured and it does show correctly when listed, but users cannot authenticate against Active Directory. The only error I see (on IPA server sssd logs) after I enabled debugging is:
[sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server ldap/dccontroller.example.local(a)IPADEV.EXAMPLE.LOCAL not found in Kerberos database)]
This error is logged for all 8 domain controllers behind Active Directory domain.
Any hint where to look for or check would be really appreciated .
2 years, 11 months
missed ipa-certupdate after adding certificates root ca and httpd
by Embedded Devel
any work around for missing the ipa-certupdate step ? we injected the root CA and missed the step,
so now we are basically locked out from doing anything ipa, even loggging in with the error
ipa: ERROR: cannot connect to 'https://ipa.domain.com/ipa/json'
<https://ipa.awnix.net/ipa/json>: [SSL: CERTIFICATE_VERIFY_FAILED]
certificate verify failed (_ssl.c:897)
The certificate in mysite.crt must be signed by a CA known by the
service you are loading the certificate into. If it is not the case, you
can use the commands/ipa-cacert-manage install/ and/ipa-certupdate/ to load
the CA's certificate prior to installing the new certificate.
# ipa-cacert-manage -p DM_PASSWORD -n NICKNAME -t C,, install ca.crt
# ipa-certupdate
Note: the command ipa-certupdate must be executed on all the IPA hosts
(master/replicas/clients) before moving to the next step.
Configuration of the 3rd part certificate
You can install the new bundle using:
# ipa-server-certinstall -w -d mysite.key mysite.crt
The option -w|--http installs the certificate for the HTTP server, and
-d|--dirsrv installs the certificate for the LDAP server. Please see
ipa-server-certinstall(1) man page for more information regarding all
the available options.
Then restart your daemons:
# systemctl restart httpd.service
# systemctl restart dirsrv(a)MY-REALM.service
2 years, 12 months
Is something changed in the compat tree in CentOS/RHEL 8?
by Peter Tselios
We use the FreeIPA servers as authentication source for Opestack Keystone.
However, after the migration of our FreeIPA to CentOS 8 from CentOS 7, Openstack users cannot login.
IPA Logs from the Openstack queries where I detected the different answer:
CentOS 7
op=4 SRCH base="cn=groups,cn=compat,dc=example,dc=com" scope=2 filter="(&(cn=dev_admins)(cn=dev_admins)(objectClass=posixGroup))" attrs="cn description"
op=4 RESULT err=0 tag=101 nentries=1 etime=0.000771612
op=5 SRCH base="cn=dev_admins,cn=groups,cn=compat,dc=example,dc=com" scope=0 filter="(objectClass=posixGroup)" attrs="memberUid"
op=5 RESULT err=0 tag=101 nentries=1 etime=0.000322091
CentOS 8
op=4 SRCH base="cn=groups,cn=compat,dc=test,dc=example,dc=com" scope=2 filter="(&(cn=dev_admins)(cn=dev_admins)(objectClass=posixGroup))" attrs="cn description"
op=4 RESULT err=0 tag=101 nentries=1 wtime=0.000169800 optime=0.000829186 etime=0.000997334
op=5 SRCH base="cn=dev_admins,cn=groups,cn=compat,dc=test,dc=example,dc=com" scope=0 filter="(objectClass=posixGroup)" attrs="memberUid"
op=5 RESULT err=0 tag=101 nentries=0 wtime=0.000131140 optime=0.000667892 etime=0.000794799
Notice that in CentOS 8 we have nentries=0
To reproduce the problem there is no need for Keystone or Openstack as it’s reproducible by a simple ldapsearch:
CentOS 7
$ LDAPBASE="dc=example,dc=com"
$ ldapsearch -v -H ldaps://localhost:636 -D "uid=appusers,cn=sysaccounts,cn=etc,${LDAPBASE}" -W -s base -b "cn=dev_admins,cn=groups,cn=compat,${LDAPBASE}" "(objectClass=posixGroup)" memberUid
CentOS 8
$ LDAPBASE="dc=test,dc=example,dc=com"
$ ldapsearch -v -H ldaps://localhost:636 -D "uid=appusers,cn=sysaccounts,cn=etc,${LDAPBASE}" -W -s base -b "cn=dev_admins,cn=groups,cn=compat,${LDAPBASE}" "(objectClass=posixGroup)" memberUid
If using the “-s sub” scope in CentOS 8, we can see the group object, which make me thing that the “compat” branch is there and that it’s just a problem with the searching of the object
Is there any possibility to fix this, or we should stick with CentOS 7?
2 years, 12 months
PKI-Tomcat flagging up on security scans
by Jake Reynolds
Hi,
I'm running ipa-server 4.8.7-13 on Centos 8.3.
My security scanning software is lighting up with a lot of warnings about my FreeIPA servers - specifically Apache Tomcat vulnerabilities exposed on the PKI-Tomcat ports - 8080/8443. It is detecting v9.0.30, and seemingly has a different list of vulnerabilities for each version below 9.0.43 that the service is vulnerable to.
Firstly, is the detection accurate? How can I determine the tomcat version in use here? If the detection is correct, has this dependency been upgraded/is in the process of upgrading?
Secondly, why are these ports exposed at all? It seems that the server.xml defines AJP listening on port localhost:8009, which is what Apache forwards requests to. However this port simply forwards on to 8443 which is listening publicly, and we also have 8080 listening publicly. As far as I can see from documentation connectivity to these endpoints should not be needed.
Thirdly, how can I configure pki-tomcat to not listen on these ports? I've tried editing the connectors in /etc/pki/pki-tomcat/server.xml but the pki-tomcatd service fails on restart - presumably an ipa service somewhere is configured to connect to the FQDN/external IP rather than localhost. Error is ` ipa-pki-wait-running: Connection failed: HTTPConnectionPool(host='my.fqdn.com', port=8080): Max retries exceeded with url: /ca/admin/ca/getStatus (Caused by NewConnectionErr`. I'm aware I could firewall off the ports, but I'd rather they weren't listening in the first place.
The only reference I've been able to find is the bug here https://github.com/dogtagpki/pki/issues/2748 - but this seems unresolved, and only refers to installation as oppose to modifying an existing install.
Thanks!
Jake
2 years, 12 months
Updating Letsencrypt certificate fails
by Reino Wallin
When the letsencrypt certificate was renewed a couple of months ago, a problem occurred.
I found this guide and tried to follow it:
https://yyhh.org/blog/2021/01/fix-freeipa-httpd-lets-encrypt-certificate-...
But it seems I have messed up something, and I would like some hints how to solve my problem.
ipa-server: 4.6.8
Among other things I get this error message:
ipa-server-certinstall -w fullchain.pem privkey.pem
Directory Manager password:
Enter private key unlock password:
Peer's certificate issuer is not trusted (certutil: certificate is invalid: Peer's Certificate issuer is not recognized.
). Please run ipa-cacert-manage install and ipa-certupdate to install the CA certificate.
The ipa-server-certinstall command failed.
Below are outputs from some important commands with my domain replaced with example.net:
certutil -L -d /etc/httpd/alias/
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Signing-Cert u,u,u
DSTRootCAX3 C,,
EXAMPLE.NET IPA CA CT,C,C
letsencryptx3 C,,
CN=ipa.example.net u,u,u
ldapsearch -Y GSSAPI -Q -b cn=certificates,cn=ipa,cn=etc,dc=example,dc=net
# extended LDIF
#
# LDAPv3
# base <cn=certificates,cn=ipa,cn=etc,dc=example,dc=net> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# certificates, ipa, etc, example.net
dn: cn=certificates,cn=ipa,cn=etc,dc=example,dc=net
objectClass: nsContainer
objectClass: top
cn: certificates
# EXAMPLE.NET IPA CA, certificates, ipa, etc, example.net
dn: cn=EXAMPLE.NET IPA CA,cn=certificates,cn=ipa,cn=etc,dc=example,dc=net
ipaConfigString: ipaCa
ipaConfigString: compatCA
ipaCertSubject: CN=Certificate Authority,O=EXAMPLE.NET
ipaKeyTrust: trusted
cACertificate;binary:: Replaced with XXX
ipaPublicKey:: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1nIS8VuSpvUaTucptnP
BDEXQYh4cxPT5qkHbuaBrZ7z8TvS2V5K2HCB/Gm6kkyZghxQFMm7zZdDNJQSu9pXUb2HDwv2wdBf6
ZBLxAZNYWJ4qTCXG5RhY13xcORnxzflXkQsMk1Pz4BZb6yEjZx9UvGXVWcdzoKVC9u1YF+jHdcKyQ
4o4K/mcy7PR/F73j3VVAyUXB7WIHT6KLaIp13Ir2byRAHHSPrIa3RBvodrRLQPuHQZZhO5O4BRXPR
6v1rwTgF+EI1Ua3w+mRmP7fHgCQcehvwkXy7zV7GMtaSchcDUf4EluWarG0UsclbLG9orVBnX6kBu
T++1Zs/nVnMAE8wIDAQAB
ipaCertIssuerSerial: CN=Certificate Authority,O=EXAMPLE.NET;1
objectClass: ipaCertificate
objectClass: pkiCA
objectClass: ipaKeyPolicy
objectClass: top
cn: EXAMPLE.NET IPA CA
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.1
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.2
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.3
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.4
# DSTRootCAX3, certificates, ipa, etc, example.net
dn: cn=DSTRootCAX3,cn=certificates,cn=ipa,cn=etc,dc=example,dc=net
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.1
cn: DSTRootCAX3
objectClass: ipaCertificate
objectClass: pkiCA
objectClass: ipaKeyPolicy
objectClass: top
ipaCertSubject: CN=DST Root CA X3,O=Digital Signature Trust Co.
ipaPublicKey:: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA36/pl1AIg1e0zGJl9pC
C7MfTLGswylvs2cN9x0DBGBSL4Ogzdkkq4z8hSZOsTg6vPkjLZe780yEPZdIq2TKPjOX3d7ASe7WV
wImjqbrtcy56DAYyg6J+ihQwzRGg4So4uXkKMf1QvYBl37dRY4PI4ohh6kthgexSa7mi4ksaKJ9Io
54M2gmOPhcuHt0g31vGKoqrLr1wrcULGiWQdHLFe2qrNNYwif/laBN7VAvI1q7sWpySHj1ks4zG37
/JQXDsFnLVJuw4VTlD0Pz9GFxA8Zfr1ZqbjR262iW5xtjfwRUCOqvabvE+LvVcCJw81oNp5BCbGSq
2KVfj5T2bn/ACXQIDAQAB
cACertificate;binary:: Replaced with XXX
ipaKeyTrust: trusted
ipaCertIssuerSerial: CN=DST Root CA X3,O=Digital Signature Trust Co.;912997355
75339953335919266965803778155
# letsencryptx3, certificates, ipa, etc, example.net
dn: cn=letsencryptx3,cn=certificates,cn=ipa,cn=etc,dc=example,dc=net
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.1
cn: letsencryptx3
objectClass: ipaCertificate
objectClass: pkiCA
objectClass: ipaKeyPolicy
objectClass: top
ipaCertSubject: CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US
ipaPublicKey:: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnNMM8FrlLke3cl03g7N
oYzDq1zUmGSXhvb418XCSL7e4S0EFq6meNQhY7LEqxGiHC6PjdeTm86dicbp5gWAf15Gan/PQeGdx
yGkOlZHP/uaZ6WA8SMx+yk13EiSdRxta67nsHjcAHJyse6cF6s5K671B5TaYucv9bTyWaN8jKkKQD
IZ0Z8h/pZq4UmEUEz9l6YKHy9v6Dlb2honzhT+Xhq+w3Brvaw2VFn3EK6BlspkENnWAa6xK8xuQSX
gvopZPKiAlKQTGdMDQMc2PMTiVFrqoM7hD8bEfwzB/onkxEz0tNvjj/PIzark5McWvxI0NHWQWM6r
6hCm21AvA2H3DkwIDAQAB
cACertificate;binary:: Replaced with XXX
ipaKeyTrust: trusted
ipaCertIssuerSerial: CN=DST Root CA X3,O=Digital Signature Trust Co.;132987958
40390663119752826058995181320
# letsencryptr3-cross, certificates, ipa, etc, example.net
dn: cn=letsencryptr3-cross,cn=certificates,cn=ipa,cn=etc,dc=example,dc=net
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.1
cn: letsencryptr3-cross
objectClass: ipaCertificate
objectClass: pkiCA
objectClass: ipaKeyPolicy
objectClass: top
ipaCertSubject: CN=R3,O=Let's Encrypt,C=US
ipaPublicKey:: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuwIVKMz2oJTTDxLsjVW
Sw/iC8ZmmekKIp10mqrUrucVMsa+Oa/l1yKPXD0eUFFU1V4yeqKI5GfWCPEKpTm71O8Mu243AsFzz
WTjn7c9p8FoLG77AlCQlh/o3cbMT5xys4Zvv2+Q7RVJFlqnBU840yFLuta7tj95gcOKlVKu2bQ6Xp
UA0ayvTvGbrZjR8+muLj1cpmfgwF126cm/7gcWt0oZYPRfH5wm78Sv3htzB2nFd1EbjzK0lwYi8YG
d1ZrPxGPeiXOZT/zqItkel/xMY6pgJdz+dU/nPAeX1pnAXFK9jpP+Zs5Od3FOnBv5IhR2haa4ldbs
TzFID9e1RoYvbFQIDAQAB
cACertificate;binary:: Replaced with XXX
ipaKeyTrust: trusted
ipaCertIssuerSerial: CN=DST Root CA X3,O=Digital Signature Trust Co.;850781574
26496920958827089468591623647
# search result
search: 4
result: 0 Success
# numResponses: 6
# numEntries: 5
2 years, 12 months