GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed)
by Ronald Wimmer
Today I tried to update one of our Keycloaks from version 12 to 18.
Everything looked good except Kerberos login. I am using the exact same
keytab file I used in KC version 12 but in version 18 I do get this:
May 24 23:18:36 kc001.linux.mydomain.at kc.sh[8164]: 2022-05-24
23:18:36,996 WARN
[org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator]
(executor-thread-2) SPNEGO login failed:
java.security.PrivilegedActionException: GSSException: Failure
unspecified at GSS-API level (Mechanism level: Checksum failed)
Any ideas what might be the cause?
Cheers,
Ronald
1 year, 11 months
[SSSD] Announcing SSSD 2.7.1
by Pavel Březina
# SSSD 2.7.1
The SSSD team is proud to announce the release of version 2.7.0 of the
System Security Services Daemon. The tarball can be downloaded from:
https://github.com/SSSD/sssd/releases/tag/2.7.1
See the full release notes at:
https://sssd.io/release-notes/sssd-2.7.1.html
RPM packages will be made available for Fedora shortly.
## Feedback
Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
## Highlights
### General information
* SSSD can now handle multi-valued RDNs if a unique name must be
determined with the help of the RDN.
### Important fixes
* A regression in `pam_sss_gss` module causing a failure if `KRB5CCNAME`
environment variable was not set was fixed.
### Packaging changes
* `sssd-ipa` doesn't require `sssd-idp` anymore
### Configuration changes
* New option `implicit_pac_responder` to control if the PAC responder is
started for the IPA and AD providers, default is `true`.
* New option `krb5_check_pac` to control the PAC validation behavior.
* multiple `crl_file` arguments can be used in the
`certificate_verification` option.
1 year, 11 months
Wildcard certificate
by Bret Wortman
I'm trying to create a wildcard certificate to use with some elasticsearch ECE systems and it's not working quite right yet. I found Fraser's blog at https://frasertweedale.github.io/blog-redhat/posts/2017-02-20-freeipa-wil... and followed the directions there. After installing the cert chain on my ES servers, when I connect over the web I'm getting an SSL_ERROR_BAD_CERT_DOMAIN error, even though the cert contains:
Subject Name
Organization OUR.NET 201804300753
Common Name *.elastic.our.net
Issuer Name
Organization OUR.NET 201804300753
Common Name Certificate Authority
Validity
Not Before Tue, 07 Jun 2022 14:48:08 GMT
Not After Fri, 07 Jun 2024 14:48:08 GMT
Subject Alt Names
DNS Name zsece01.our.net
DNS Name zsece02.our.net
DNS Name zsece013our.net
:
I've tried including elastic.our.net as an alt name too and it didn't prevent the error. What am I missing?
--
Bret Wortman
bret.wortman(a)damascusgrp.com
1 year, 11 months
Cert Errors when trying to delete a host or view certs in UI.
by Russ Long
When I attempt to delete a host (non-ipa server host, just a client), I get the following error:
ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (403)
When I go to Authentication -> Certificates, I get this error:
An error has occurred (IPA Error 4301: CertificateOperationError)
I see this old thread:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
I tried the suggestions there, however I'm unable to make this work.
Certmonger is running, and not showing any errors. SSL Certs all show monitored, are not expired, and are not stuck.
All IPA services are running.
IPA-healthcheck shows several errors regarding a 403 when connecting to the CA Rest API.
This is only a single-server install in my homelab, but rather than destroying it and starting over I'd really like to figure out what's up.
1 year, 12 months
PSA: Change in Firefox related to host names and its impact on IPA
by Rob Crittenden
Heads up about a change in Firefox v101.0 that can affect some
deployments of freeIPA.
https://www.mozilla.org/en-US/firefox/101.0/releasenotes reads:
"Removed "subject common name" fallback support from certificate
validation. This fallback mode was previously enabled only for manually
installed certificates. The CA Browser Forum Baseline Requirements have
required the presence of the "subjectAltName" extension since 2012, and
use of the subject common name was deprecated in RFC 2818."
This has been a long time coming. RFC2818 contains this:
https://datatracker.ietf.org/doc/html/rfc2818#section-3.1
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.
It is probably a safe assumption that other browsers will soon follow suit.
If you don't use the IPA CA then you need to verify that the
certificates, from Let's Encrypt for example, contain a DNS Subject
Alternative Name (SAN) (LE should already). If not then you need to work
with the provider(s) to reissue new ones.
Installations with an IPA CA has enabled a DNS SAN for the Apache and
389 certificates since 4.5.1 so newer deployments should be unaffected
by this.
To confirm that the current IPA-issued certificates, including an IPA CA
signed as a subordinate by an external CA, contain a SAN:
For IPA 4.6 and earlier:
# getcert list -d /etc/httpd/alias -n Server-Cert
# getcert list -d /etc/dirsrv/slapd-<REALM> -n Server-Cert
For IPA 4.7 and later:
# getcert list -f /var/lib/ipa/certs/httpd.crt
# getcert list -d /etc/dirsrv/slapd-<REALM> -n Server-Cert
Included in the output for each cert should be a line like:
dns: ipa.example.test
Where ipa.example.test is the hostname of the machine.
If it isn't you can use certmonger to add a DNS SAN and reissue an
existing certificate with:
# getcert resubmit -i <certmonger_request_id> -D $(hostname)
If you aren't using an IPA CA then it is still possible to verify but it
is slightly more complicated because the certificate nickname(s) may be
different.
For IPA 4.6 and earlier:
# grep NSSNickname /etc/httpd/conf.d/nss.conf
# certutil -L -d /etc/httpd/alias -n "<the value from above>"
# grep nsSSLPersonalitySSL /etc/dirsrv/slapd-REALM/dse.ldif
# certutil -L -d /etc/dirsrv/slapd-REALM -n "<the value from above>"
The output for each should contain something like:
Name: Certificate Subject Alt Name
DNS name: "ipa.example.test"
Where ipa.example.test is the hostname of the machine.
For IPA 4.7 and later:
# grep SSLCertificateFile /etc/httpd/conf.d/ssl.conf
# openssl x509 -noout -text -in "<the value from above>"
The output should contain something like:
X509v3 Subject Alternative Name:
DNS:ipa.example.test
# grep nsSSLPersonalitySSL /etc/dirsrv/slapd-REALM/dse.ldif
# certutil -L -d /etc/dirsrv/slapd-REALM -n "<the value from above>"
The output for each should contain something like:
Name: Certificate Subject Alt Name
DNS name: "ipa.example.test"
Where ipa.example.test is the hostname of the machine.
If not you'll need to contact the issuing CA to get a replacement with a
DNS SAN.
rob
1 year, 12 months
SSSD login stopped working on Ubuntu 22.04
by Joyce Babu
I have a FreeIPA installation with many Pop!_OS 21.10 clients. Today I upgraded one of the clients to Pop!_OS 22.04, and I can no longer authenticate with FreeIPA on the upgraded client.
In krb5kdc.log file on the server, I can see the error 'verify failure: Incorrect password in encrypted challenge'
=======
May 17 14:07:43 ipa.myhost.com krb5kdc[301](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 192.168.10.14: NEEDED_PREAUTH: joyce(a)MYHOST.COM for krbtgt/MYHOST.COM(a)MYHOST.COM, Additional pre-authentication required
May 17 14:07:43 ipa.myhost.com krb5kdc[301](info): closing down fd 12
May 17 14:07:43 ipa.myhost.com krb5kdc[302](info): preauth (encrypted_challenge) verify failure: Incorrect password in encrypted challenge
May 17 14:07:43 ipa.myhost.com krb5kdc[302](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 192.168.10.14: PREAUTH_FAILED: joyce(a)MYHOST.COM for krbtgt/MYHOST.COM(a)MYHOST.COM, Preauthentication failed
May 17 14:07:43 ipa.myhost.com krb5kdc[302](info): closing down fd 12
=======
If I try the same username/password on a Pop!_OS 21.10 client, I can login successfully and I see the following log message. I tried multiple times with multiple users, and had the same result.
=======
May 17 14:05:51 ipa.myhost.com krb5kdc[299](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 192.168.10.24: NEEDED_PREAUTH: joyce(a)MYHOST.COM for krbtgt/MYHOST.COM(a)MYHOST.COM, Additional pre-authentication required
May 17 14:05:51 ipa.myhost.com krb5kdc[299](info): closing down fd 12
May 17 14:05:51 ipa.myhost.com krb5kdc[301](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 192.168.10.24: ISSUE: authtime 1652796351, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, joyce(a)MYHOST.COM for krbtgt/MYHOST.COM(a)MYHOST.COM
May 17 14:05:51 ipa.myhost.com krb5kdc[301](info): closing down fd 12
May 17 14:05:51 ipa.myhost.com krb5kdc[300](info): TGS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 192.168.10.24: ISSUE: authtime 1652796351, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, joyce(a)MYHOST.COM for host/ws024.office-mng.myhost.net(a)MYHOST.COM
May 17 14:05:51 ipa.myhost.com krb5kdc[300](info): closing down fd 12
=======
What changed in Ubuntu 22.04? Could this be due to incompatible encryption type?
1 year, 12 months
krbPrincipalExpiration and ssh keys
by Jim Kinney
It seems if valid ssh keys exist, the expired account status doesn't block login with ssh keys. Any operation that touches a password is blocking.
Is there a pam setting in sshd that needs tweaking to deny access if account is expired?
--
Computers amplify human error
Super computers are really cool
2 years
keytab encryption settings
by G H
I got FreeIPA up and running but am having trouble getting it working with apache, I tried both mod_auth_mellon and mod_auth_gssapi. My goal is to have something that 1) attempts kerberos 2) falls back to user/pass auth.
For mod_auth_gssapi, I am able to get get SSO working with my local Firefox, but the fallback HTTPBasic auth fails. Opening a private firefox window (to break kerberos) and entering my username/pass I get the following Apache log error:
GSS ERROR gss_init_sec_context(): [Unspecified GSS failure. Minor code may provide more information (KDC has no support for encryption type)
Apache config is:
<Location />
AuthType GSSAPI
AuthName "Kerberos Login"
GssapiCredStore keytab:/etc/httpd/http.keytab
GssapiBasicAuth On
GssapiBasicAuthMech krb5
Require valid-user
</Location>
Okay, so I moved to mod_auth_mellon (SAML auth via Keycloak via FreeIPA). With this one I got username/pass auth working, but kerberos does not work. I followed the instructions here: https://jdennis.fedorapeople.org/doc/mellon-install/mellon-install-guide....
Keycloak reports the below message when I *require* kerberos auth (over username/passwd):
Caused by: GSSException: Failure unspecified at GSS-API level (Mechanism level: Invalid argument (400) - Cannot find key of appropriate type to decrypt AP-REQ - AES256 CTS mode with HMAC SHA1-96)
So I think something might be wrong with my keytab file. Lots of posts around the internet are about Windows AD and say to enable AES encryption for that service, but I do not see such an option in FreeIPA.
So am I missing something with the encryption settings ?
Here is my keytab creation command: ipa-getkeytab -s freeipa.example.com -p HTTP/keycloak.example.com -k /tmp/client1.keytab
And here is the result:
[root@freeipa ~]# klist -e -k /tmp/client1.keytab
Keytab name: FILE:/tmp/client1.keytab
KVNO Principal
---- --------------------------------------------------------------------------
1 HTTP/keycloak.example.com(a)EXAMPLE.COM (aes256-cts-hmac-sha1-96)
1 HTTP/keycloak.example.com(a)EXAMPLE.COM (aes128-cts-hmac-sha1-96)
2 years
After upgrade, only one direction replication while should be bi-directions replication
by Kathy Zhu
Hi Team,
We upgraded our Centos 7 IPA masters to the latest:
CentOS Linux release 7.9.2009 (Core)
*ipa*-server.x86_64 4.6.8-5.el7.centos.10
*389-ds*-base.x86_64 1.3.10.2-15.el7_9
*389-ds*-base-libs.x86_64 1.3.10.2-15.el7_9
*389-ds*-base-snmp.x86_64 1.3.10.2-15.el7_9
*slapi*-nis.x86_64 0.56.5-3.el7_9
After that, 8 of 10 masters had replication issues. After reinitializing, 2
of them are still having issues. They can accept replication from other
masters but their own changes can not be replicated to others.
Here are the logs in /var/log/dirsrv/slapd-EXAMPLE-COM/errors:
[01/Jun/2022:21:53:02.324756398 -0700] - ERR - NSMMReplicationPlugin -
send_updates - agmt="cn=dc1-ipa1.example.com-to-dc2-ipa1.example.com"
(dc2-ipa1:389): Data required to update replica has been purged from the
changelog. If the error persists the replica must be reinitialized.
[01/Jun/2022:21:53:03.396330801 -0700] - ERR - agmt="cn=
dc1-ipa1.example.com-to-dc3-ipa1.example.com" (dc3-ipa1:389) -
clcache_load_buffer - Can't locate CSN 627e26a50005001d0000 in the
changelog (DB rc=-30988). If replication stops, the consumer may need to be
reinitialized.
[01/Jun/2022:21:53:03.396502102 -0700] - ERR - NSMMReplicationPlugin -
changelog program - repl_plugin_name_cl - agmt="cn=
dc1-ipa1.example.com-to-dc3-ipa1.example.com" (dc3-ipa1:389): CSN
627e26a50005001d0000 not found, we aren't as up to date, or we purged
[01/Jun/2022:21:53:03.396694568 -0700] - ERR - NSMMReplicationPlugin -
send_updates - agmt="cn=dc1-ipa1.example.com-to-dc3-ipa1.example.com"
(dc3-ipa1:389): Data required to update replica has been purged from the
changelog. If the error persists the replica must be reinitialized.
[01/Jun/2022:21:53:04.411599251 -0700] - ERR - agmt="cn=
dc1-ipa1.example.com-to-ipa0.example.com" (ipa0:389) - clcache_load_buffer
- Can't locate CSN 627e26a50005001d0000 in the changelog (DB rc=-30988). If
replication stops, the consumer may need to be reinitialized.
[01/Jun/2022:21:53:04.411753186 -0700] - ERR - NSMMReplicationPlugin -
changelog program - repl_plugin_name_cl - agmt="cn=
dc1-ipa1.example.com-to-ipa0.example.com" (ipa0:389): CSN
627e26a50005001d0000 not found, we aren't as up to date, or we purged
[01/Jun/2022:21:53:04.411893312 -0700] - ERR - NSMMReplicationPlugin -
send_updates - agmt="cn=dc1-ipa1.example.com-to-ipa0.example.com"
(ipa0:389): Data required to update replica has been purged from the
changelog. If the error persists the replica must be reinitialized.
[01/Jun/2022:21:53:05.482898290 -0700] - ERR - agmt="cn=
dc1-ipa1.example.com-to-dc2-ipa1.example.com" (dc2-ipa1:389) -
clcache_load_buffer - Can't locate CSN 627e26a50005001d0000 in the
changelog (DB rc=-30988). If replication stops, the consumer may need to be
reinitialized.
[01/Jun/2022:21:53:05.483231727 -0700] - ERR - NSMMReplicationPlugin -
changelog program - repl_plugin_name_cl - agmt="cn=
dc1-ipa1.example.com-to-dc2-ipa1.example.com" (dc2-ipa1:389): CSN
627e26a50005001d0000 not found, we aren't as up to date, or we purged
[01/Jun/2022:21:53:05.483483005 -0700] - ERR - NSMMReplicationPlugin -
send_updates - agmt="cn=dc1-ipa1.example.com-to-dc2-ipa1.example.com"
(dc2-ipa1:389): Data required to update replica has been purged from the
changelog. If the error persists the replica must be reinitialized.
Note, those messages are after being reinitialized.
Any idea what's wrong here?
Thanks.
Kathy.
2 years
