expired Server-cert
by Serge Krawczenko
Greetings,all
I've been observing multiple issues for some time, unable to enroll new
clients etc.
Finally found out that the possible root cause is the expired Server-Cert
cert-pki-ca and therefore pki-tomcat service won't start
Here's the output of getcert list -d /etc/pki/pki-tomcat/alias/
Request ID '20171204131518':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert
cert-pki-ca',token='NSS Certificate DB',pin set
certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=....
subject: CN=....
expires: 2022-04-25 17:06:51 UTC
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth,id-kp-emailProtection
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "Server-Cert
cert-pki-ca"
Other certs in /etc/pki/pki-tomcat/alias/ seem to be ok but this one.
I'd like to understand how to perform the forced update for this one, i
assume it must be renewed automatically though
I tried to invoke post-save command manually but no luck.
Appreciate any ideas
1 hour, 14 minutes
Are URI dns records required?
by Ranbir
Hello,
My employer uses Windows for DNS and would prefer to keep using that
instead of freeipa's integrated DNS. Ok, sure, why not? I don't like
it, but there are bigger battles to fight.
I did the install on the first server without DNS, grabbed the DNS
records that needed to be imported into Windows DNS and handed them to
the Windows admin. He came back telling me that URI records aren't
supported in Windows DNS. Sweeeeeeeeet.
I can see that SRV records are still listed. Does that mean the URI
records can be safely left out?
Thanks,
--
Ranbir
1 hour, 43 minutes
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
6 hours, 16 minutes
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?
7 hours, 58 minutes
SSSD Problem after update
by Ronald Wimmer
Today I updated all packages on one of our IPA servers. Unfortunately,
SSSD stopped working:
[sssd] [main] (0x0010): SSSD couldn't load the configuration database.
[sssd] [ldb] (0x0020): Unable to open tdb '/var/lib/sss/db/config.ldb':
Permission denied
[sssd] [ldb] (0x0020): Failed to connect to '/var/lib/sss/db/config.ldb'
with backend 'tdb': Unable to open tdb '/var/lib/sss/db/config.ldb':
Permission denied
[sssd] [confdb_init] (0x0010): Unable to open config database
[/var/lib/sss/db/config.ldb]
[sssd] [confdb_setup] (0x0010): The confdb initialization failed [5]:
Input/output error
[sssd] [load_configuration] (0x0010): Unable to setup ConfDB [5]:
Input/output error
I noticed that owner and group of config.ldb are changed to sssd when I
try to restart the sssd.service. On all remaining IPA servers this
particular file belongs to root.
I will revert to the snapshot I made before updating packages in order
to make that IPA server work again properly.
Cheers,
Ronald
15 hours, 51 minutes
How to add NOPASSWD for ALL commands (no prompt for password)
by Damola Azeez
I'm trying to create a user to use for my automation. I don't want to have the Users created manually on each host as that's time-consuming. Is there a way I can use IPA to handle this requirement such that the user I create is sudo and runs Sudo commands without asking for a password?
22 hours, 21 minutes
c9s - package conflicts with updates
by lejeczek
Hi
just to let you @devel guys know in case this might affect &
brake IPA as in the (recent) past.
...
Problem 1: package pki-java-11.2.0-0.2.beta1.el9.noarch
requires pki-base = 11.2.0-0.2.beta1.el9, but none of the
providers can be installed
- package idm-pki-base-11.2.0-0.4.beta3.el9.noarch
obsoletes pki-base < 11.2.0-0.4.beta3.el9 provided by
pki-base-11.2.0-0.2.beta1.el9.noarch
- cannot install the best update candidate for package
pki-java-11.2.0-0.2.beta1.el9.noarch
- cannot install the best update candidate for package
pki-base-11.2.0-0.2.beta1.el9.noarch
Problem 2: problem with installed package
pki-java-11.2.0-0.2.beta1.el9.noarch
- package pki-java-11.2.0-0.2.beta1.el9.noarch requires
pki-base = 11.2.0-0.2.beta1.el9, but none of the providers
can be installed
- package pki-base-11.2.0-0.2.beta1.el9.noarch requires
python3-pki = 11.2.0-0.2.beta1.el9, but none of the
providers can be installed
- package python3-idm-pki-11.2.0-0.4.beta3.el9.noarch
obsoletes python3-pki < 11.2.0-0.4.beta3.el9 provided by
python3-pki-11.2.0-0.2.beta1.el9.noarch
- cannot install the best update candidate for package
python3-pki-11.2.0-0.2.beta1.el9.noarch
...
thanks, L
1 day, 5 hours
CA not configured on second replica but it is configured
by Pavlo Pocheptsov
Hi list.
ipa2 node was promoted to ca with ipa-ca-instal
and it shows all is good on its side:
[root@ipa2 ~]# ipa-replica-manage list
ipa3: master
ipa2: master
[root@ipa2 ~]# ipa-csreplica-manage list
ipa3: master
ipa2: *master*
[root@ipa2 ~]# ipa config-show |grep CA
Certificate Subject base: O=removed
IPA CA servers: *ipa2, ipa3*
IPA CA renewal master: ipa3
[root@ipa2 ~]# ipa server-role-find | grep -A1 -B1 CA
Server name: ipa2
Role name: CA server
Role status: *enabled*
--
Server name: ipa3
Role name: CA server
Role status: *enabled*
[root@ipa2 ~]# ipa-replica-manage list-ruv
Replica Update Vectors:
ipa2:389: 11
ipa3:389: 9
Certificate Server Replica Update Vectors:
ipa2:389: 12
ipa3:389: 10
But ipa3 node doesn't see ipa2 as ca master:
[root@ipa3 ~]# ipa-replica-manage list
ipa3: master
ipa2: master
[root@ipa3 ~]# ipa-csreplica-manage list
ipa3: master
ipa2: *CA not configured*
[root@ipa3 ~]# ipa config-show |grep CA
Certificate Subject base: O=removed
IPA CA servers: *ipa3* <----- no ipa2 here
IPA CA renewal master: ipa3
[root@ipa3 ~]# ipa server-role-find | grep -B1 -A1 CA
Server name: ipa2
Role name: CA server
Role status: *absent*
--
Server name: ipa3
Role name: CA server
Role status: enabled
[root@ipa3 ~]# ipa-replica-manage list-ruv
Replica Update Vectors:
ipa3:389: 9
ipa2:389: 11
Certificate Server Replica Update Vectors:
ipa3:389: 10
ipa2:389: 12
Centos 7.9
FreeIPA, version: 4.6.8
What is the real situation here? Is there CA replication btw replicas or no?
Is it possible to fix this and make ipa2 CA role visible on ipa3?
Any extra information I can provide to fully understand the issue?
Pavel
1 day, 7 hours
Re: hostgroup automember rules
by Alexander Bokovoy
Hi Angus,
On pe, 20 touko 2022, Angus Clarke via FreeIPA-users wrote:
>Hello
>
>FreeIPA 4.6.8
>
>We are very happy with hostgroup automember rules based on servername
>attribute however one of our internal customers uses a generic
>servername template for all of their servers regardless of its
>function.
>
>So I'm wondering what other attributes I might use for hostgroup
>automember - perhaps some of the attributes can be configured by the
>ipa-client-install (the host's "description" field perhaps) although I
>don't see such mention in the man page ... Presumably they could use a
>different enrollment user ("enrolledby") for each of their hostgroup
>functions (not ideal.)
>
>There are various attribute fields in the WebUI but I don't find much
>documentation for them. What is the "|" field - perhaps I can exploit
>this somehow?
Few years ago a customer of mine asked a similar question. Here is what
I answered:
----------------------------------------------------------------------
You can use nsHardwarePlatform attribute (part of nsHost objectclass).
It is exposed as '--platform' in IPA CLI for 'ipa host-*' commands.
Originally it was supposed to be filled by the IPA client join process
to 'uname -m' value. ipa-join tools still sends it to the server but the
value is ignored completely by the join process. As the result,
nsHardwarePlatform attribute is never set on the host object.
I don't see any code in IPA itself that would rely on the content of
nsHardwarePlatform attribute. We have web UI tests upstream that modify
the field to test that you can modify it but that's all.
Alternatively, one can use userClass attribute (--class in IPA CLI for
host-* commands). This one is also not utilized and is left specifically
for the customers to define its semantics.
Another alternative is nsHostLocation attribute (--location in IPA CLI for host-*
commands). Again, the semantics is totally left for customers to define.
----------------------------------------------------------------------
There are two ways of setting these fields:
- prior to enrollment, by pre-creating a host and setting the
attributes at that time.
- after the enrollment, right from the host using host keytab
The former can be done by a designated user/service account and can be
tuned with custom permissions to allow such modification. The latter
relies on the fact that the host principal has some write rights
already:
# kinit -k
# ipa host-show `hostname` --rights --all
dn: fqdn=dc.ipa.test,cn=computers,cn=accounts,dc=ipa,dc=test
Host name: dc.ipa.test
Principal name: host/dc.ipa.test(a)IPA.TEST
Principal alias: host/dc.ipa.test(a)IPA.TEST
SSH public key: [skip]
SSH public key fingerprint: [skip]
Requires pre-authentication: True
Trusted for delegation: False
Trusted to authenticate as user: False
Password: False
Member of host-groups: ipaservers
Keytab: True
Managed by: dc.ipa.test
Managing: dc.ipa.test
attributelevelrights: {'aci': '', 'cn': 'rscwo', 'description': 'rscwo', 'enrolledby': 'rsc', 'fqdn': 'rsc', 'ipaassignedidview': 'rsc', 'ipaclientversion': 'rsc', 'ipakrbauthzdata': 'rsc', 'ipasshpubkey': 'rscwo', 'ipauniqueid': 'rsc', 'krballowedtodelegateto': '', 'krbauthindmaxrenewableage': '', 'krbauthindmaxticketlife': '', 'krbcanonicalname': 'rsc', 'krbextradata': '', 'krblastadminunlock': '', 'krblastfailedauth': '', 'krblastpwdchange': 'rscwo', 'krblastsuccessfulauth': '', 'krbloginfailedcount': '', 'krbmaxrenewableage': '', 'krbmaxticketlife': '', 'krbobjectreferences': '', 'krbpasswordexpiration': 'rsc', 'krbprincipalaliases': 'rsc', 'krbprincipalauthind': 'rsc', 'krbprincipalexpiration': 'rsc', 'krbprincipalkey': 'swo', 'krbprincipalname': 'rsc', 'krbprincipaltype': '', 'krbpwdhistory': '', 'krbpwdpolicyreference': '', 'krbticketflags': '', 'krbticketpolicyreference': '', 'krbupenabled': '', 'l': 'rscwo', 'managedby': 'rsc', 'memberof': 'rsc', 'nsaccountlock': '', 'nshardwareplatform': 'rscwo', 'nshostlocation': 'rscwo', 'nsosversion': 'rscwo', 'objectclass': 'rsc', 'serverhostname': 'rsc', 'usercertificate': 'rscwo', 'userclass': 'rsc', 'userpassword': 'swo'}
cn: dc.ipa.test
ipauniqueid: b179f1ea-c4b8-11ec-9e86-52540083ff9d
krblastpwdchange: 20220425165647Z
objectclass: top, ipaobject, nshost, ipahost, ipaservice, pkiuser, krbprincipalaux, krbprincipal, krbticketpolicyaux, ipasshhost, ipaSshGroupOfPubKeys
serverhostname: dc
So, the host/dc.ipa.test(a)IPA.TEST principal can write to:
- nsHardwarePlatform
- nsHostLocation
- nsOSVersion
- l (locality)
- description
but it cannot write to 'userClass' attribute.
A handy mapping between attributes and command parameters is
'show-mappings' command:
# ipa show-mappings host-mod
Parameter : LDAP attribute
========= : ==============
desc : description?
locality : l?
location : nshostlocation?
platform : nshardwareplatform?
os : nsosversion?
password : userpassword?
random : random?
certificate : usercertificate*
krbprincipalname : krbprincipalname*
macaddress : macaddress*
sshpubkey : ipasshpubkey*
class : userclass*
auth-ind : krbprincipalauthind*
requires-pre-auth : ipakrbrequirespreauth?
ok-as-delegate : ipakrbokasdelegate?
ok-to-auth-as-delegate : ipakrboktoauthasdelegate?
rights : rights
updatedns : updatedns?
If you want to change parameters from the host itself, it would be
possible with
# kinit -k
# ipa host-mod `hostname` --locality=foo --location=bar --platform=some-platform --desc=some-host
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
1 day, 23 hours
Re: hostgroup automember rules
by Florence Blanc-Renaud
Hi,
On Fri, May 20, 2022 at 11:48 AM Angus Clarke via FreeIPA-users <
freeipa-users(a)lists.fedorahosted.org> wrote:
> Hello
>
> FreeIPA 4.6.8
>
> We are very happy with hostgroup automember rules based on servername
> attribute however one of our internal customers uses a generic servername
> template for all of their servers regardless of its function.
>
> So I'm wondering what other attributes I might use for hostgroup
> automember - perhaps some of the attributes can be configured by the
> ipa-client-install (the host's "description" field perhaps) although I
> don't see such mention in the man page ... Presumably they could use a
> different enrollment user ("enrolledby") for each of their hostgroup
> functions (not ideal.)
>
> There are various attribute fields in the WebUI but I don't find much
> documentation for them. What is the "|" field - perhaps I can exploit this
> somehow?
>
The automember group functionality is described in this chapter: Automating
group membership using IdM CLI
<https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/...>
.
You can define a new hostgroup with an automember rule based on any
attribute defined in the schema. Just be aware that the conditions are
defined using Perl-compatible regular expressions (PCRE) format.
The 'l' attribute is an alias for 'locality' or 'localityname' and can
contain any string. For any attribute you can find its description in the
LDAP schema.
The host entries have multiple object classes. For instance if you run
ipa host-show server.ipa.test --all --raw
you can see all its objectclasses:
objectClass: top
objectClass: ipaobject
objectClass: nshost
objectClass: ipahost
objectClass: ipaservice
objectClass: pkiuser
objectClass: krbprincipalaux
objectClass: krbprincipal
objectClass: krbticketpolicyaux
objectClass: ipasshhost
objectClass: ipaSshGroupOfPubKeys
Each object class defines the mandatory/optional attributes that the entry
can contain. For instance in order to find the attributes for the *nshost*
objectclass:
ldapsearch -LLL -o ldif-wrap=no -b cn=schema -s base objectclasses | grep
-i nshost
objectclasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined
objectclass' SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description
$ l $ nsHostLocation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN
'Netscape' )
The *nshost* objectclass allows the presence of *serverhostname*,
*description*, *l* etc...
Now to find what *description* can contain:
ldapsearch -LLL -o ldif-wrap=no -b cn=schema -s base attributetypes | grep
-i description
attributetypes: ( 2.5.4.13 NAME 'description' EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
X-ORIGIN 'RFC 4519' )
The SYNTAX part defines the type of data (the RFC 4517
<https://datatracker.ietf.org/doc/html/rfc4517#section-3.3.6> defines
1.3.6.1.4.1.1466.115.121.1.15 as a DirectoryString).
With this knowledge, you can pick an attribute where you want to store
information that can be used to group the hosts together, and create the
matching rule using this attribute.
If you are curious about LDAP schema in general, you can read the RFC 4519
<https://www.ietf.org/rfc/rfc4519.txt>.
HTH,
flo
> Any advice gladly received.
>
> Thanks a lot
> Angus
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
1 day, 23 hours