Hi,
you have deleted the bug template and your bug report is missing some crucial information to diagnose the problem. Could you please provide:

• step by step instructions to reproduce the problem
• the output of rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server on your IPA server and client
• the output of ipa-client-install
• attach the log file /var/log/ipaclient-install.log
• krb5kdc.log on your IPA server around the time of installation would also be helpful.

I also recommend that you open a bug with your vendor in case the problem is caused by a downstream change in Rocky.

1)
I enter the command install-ipa-cleint

This program will set up IPA client.
Version 4.10.2

Discovery was successful!
Do you want to configure chrony with NTP server or pool address? [no]:
Client hostname: inf-my-tt.domain
Realm: domain
DNS Domain: domain
IPA Server: dc01.domain
BaseDN: dc=domain,dc=domain,dc=domain

Continue to configure the system with these values? [no]: yes
Removed old keys for realm domain from /etc/krb5.keytab
Synchronizing time
Configuration of chrony was changed by installer.
Attempting to sync time with chronyc.
Time synchronization was successful.
User authorized to enroll computers: user
Password for user@domain:
Successfully retrieved CA cert
Subject: CN=Certificate Authority,O=domain
Issuer: CN=Certificate Authority,O=domain
Valid From: 2018-12-14 10:48:38
Valid Until: 2038-12-14 10:48:38

Enrolled in IPA realm domain
Please make sure the following ports are opened in the firewall settings:
TCP: 80, 88, 389
UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
Also note that following ports are necessary for ipa-client working properly after enrollment:
TCP: 464
UDP: 464, 123 (if NTP enabled)
Failed to obtain host TGT: Major (458752): No credentials were supplied, or the credentials were unavailable or inaccessible, Minor (2529639122): Pre-authentication failed: Invalid argument
Installation failed. Rolling back changes.
Disabling client Kerberos and LDAP configurations
Restoring client configuration files
nscd daemon is not installed, skip configuration
nslcd daemon is not installed, skip configuration
Client uninstall complete.
The ipa-client-install command failed. See /var/log/ipaclient-install.log for more information

2) IPA server
ipa-server-4.6.6-11.el7.centos.x86_64
ipa-client-4.6.6-11.el7.centos.x86_64
389-ds-base-1.3.10.1-9.el7_8.x86_64
pki-ca-10.5.17-6.el7.noarch
krb5-server-1.15.1-46.el7.x86_64

3) Ipa client (client host)
ipa-client-4.10.2-4.el9_3.1.x86_64

4) krb5kdc.log
Dec 08 11:32:29 dc01 krb5kdc2085: AS_REQ (4 etypes {20 19 18 17}) ip: NEEDED_PREAUTH: host/inf-my-tt@domain for krbtgt/domain@domain, Additional pre-authentication required
Dec 08 11:32:29 dc01 krb5kdc2085: AS_REQ (4 etypes {20 19 18 17}) ip: NEEDED_PREAUTH: host/inf-my-tt@domain for krbtgt/domain@domain, Additional pre-authentication required

Do you still have /etc/krb5.keytab from the failed enrollment? Can you show its content?

# klist -teC -k

the log of the client enrollment says that an IPA server part couldn't generate aes-sha1 keys for this host, for whatever reason. This definitely does not look like a valid environment. CentOS 7 IPA server should default to aes-sha1 encryption types.

Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp Principal

1 12/11/2023 10:24:09 host/inf-my-tt@domain (aes256-cts-hmac-sha384-192)
1 12/11/2023 10:24:09 host/inf-my-tt@domain (aes128-cts-hmac-sha256-128)

Ok, if the keytab is there, then you can try to repeat this experiment manually to get a krb5 trace. Make sure to change domain values back to what you had in the original ipaclient-install.log:

cat <<END > /tmp/krb5-temp.conf
includedir /etc/krb5.conf.d/
[libdefaults]
  default_realm = domain
  dns_lookup_realm = false
  rdns = false
  dns_canonicalize_hostname = false
  dns_lookup_kdc = true
  ticket_lifetime = 24h
  forwardable = true
  udp_preference_limit = 0
  default_ccache_name = KEYRING:persistent:%{uid}


[realms]
  domain = {
    kdc = dc01.domain:88
    master_kdc = dc01.domain:88
    admin_server = dc01.domain:749
    kpasswd_server = dc01.domain:464
    default_domain = domain
    pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
    pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem

  }


[domain_realm]
  .domain = domain
  domain = domain
  inf-my-tt.domain = domain
END
# export KRB5_TRACE=/dev/stderr
# KRB5_CONFIG=/tmp/krb5-temp.conf kinit -k

Please attach both the output from this client trace and krb5kdc.log entries from the KDC side for this access.

Did

Thanks. So the KDC does know about aes-sha2 enctypes for this host but does only use aes-sha1 in the negotiation and the client has no aes-sha1 key to respond but advertises the knowledge of those (types 18 and 17):

Dec 11 12:07:19 dc02.domain krb5kdc[87271](info): AS_REQ (4 etypes {20 19 18 17}) 10.21.254.174: NEEDED_PREAUTH: host/inf-my-tt.domain@domain for krbtgt/domain@domain, Additional pre-authentication required
...

[5549] 1702285639.620943: Getting initial credentials for host/inf-my-tt.DOMAIN@DOMAIN
[5549] 1702285639.620944: Found entries for host/inf-my-tt.DOMAIN@DOMAIN in keytab: aes256-sha2, aes128-sha2
[5549] 1702285639.620946: Sending unauthenticated request
[5549] 1702285639.620947: Sending request (193 bytes) to DOMAIN
[5549] 1702285639.620948: Resolving hostname dc02.DOMAIN
[5549] 1702285639.620949: Initiating TCP connection to stream dc02_ip:88
[5549] 1702285639.620950: Sending TCP request to stream dc02_ip:88
[5549] 1702285639.620951: Received answer (343 bytes) from stream dc02_ip:88
[5549] 1702285639.620952: Terminating TCP connection to stream dc02_ip:88
[5549] 1702285639.620953: Response was from primary KDC
[5549] 1702285639.620954: Received error from KDC: -1765328359/Additional pre-authentication required
[5549] 1702285639.620957: Preauthenticating using KDC method data
[5549] 1702285639.620958: Processing preauth types: PA-PK-AS-REQ (16), PA-PK-AS-REP_OLD (15), PA-PK-AS-REQ_OLD (14), PA-FX-FAST (136), PA-ETYPE-INFO2 (19), PA-PKINIT-KX (147), PA-ENC-TIMESTAMP (2), PA-FX-COOKIE (133)
--->>> [5549] 1702285639.620959: Selected etype info: etype aes256-cts, salt "DOMAINhostinf-my-tt.DOMAIN", params ""
[5549] 1702285639.620960: Received cookie: MIT
[5549] 1702285639.620961: PKINIT client has no configured identity; giving up
[5549] 1702285639.620962: Preauth module pkinit (147) (info) returned: 0/Success
[5549] 1702285639.620963: PKINIT client has no configured identity; giving up
[5549] 1702285639.620964: Preauth module pkinit (16) (real) returned: 22/Invalid argument
[5549] 1702285639.620965: Retrieving host/inf-my-tt.DOMAIN@DOMAIN from FILE:/etc/krb5.keytab (vno 0, enctype aes256-cts) with result: -1765328203/No key table entry found for host/inf-my-tt.DOMAIN@DOMAIN
[5549] 1702285639.620966: Preauth module encrypted_timestamp (2) (real) returned: -1765328203/No key table entry found for host/inf-my-tt.DOMAIN@DOMAIN

To fix this either a client needs to ask for aes-sha2 only or KDC should prefer aes-sha2 over aes-sha1 types if the keys are present. The latter is a bit hard as the December's discussion on krbdev shows: https://mailman.mit.edu/pipermail/krbdev/2023-December/thread.html.

Can you show output of

# ldapsearch -Y EXTERNAL -H ldapi://%2Frun%2Fslapd-DOMAIN.socket -s base -b cn=DOMAIN,cn=kerberos,dc=domain krbSupportedEncSaltTypes krbDefaultEncSaltTypes

?
Replace DOMAIN by the correct values (e.g. IPA1.TEST would be dc=ipa1,dc=test in the DN).

I don't have IPA 4.6 available, but for current master deployment it looks something like (since commit d38dd26):

# ldapsearch -Y EXTERNAL -H ldapi://%2Frun%2Fslapd-IPA1-TEST.socket  -b cn=IPA1.TEST,cn=kerberos,dc=ipa1,dc=test -s base krbSupportedEncSaltTypes krbDefaultEncSaltTypes
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base <cn=IPA1.TEST,cn=kerberos,dc=ipa1,dc=test> with scope baseObject
# filter: (objectclass=*)
# requesting: krbSupportedEncSaltTypes krbDefaultEncSaltTypes 
#

# IPA1.TEST, kerberos, ipa1.test
dn: cn=IPA1.TEST,cn=kerberos,dc=ipa1,dc=test
krbSupportedEncSaltTypes: aes256-cts:normal
krbSupportedEncSaltTypes: aes256-cts:special
krbSupportedEncSaltTypes: aes128-cts:normal
krbSupportedEncSaltTypes: aes128-cts:special
krbSupportedEncSaltTypes: aes128-sha2:normal
krbSupportedEncSaltTypes: aes128-sha2:special
krbSupportedEncSaltTypes: aes256-sha2:normal
krbSupportedEncSaltTypes: aes256-sha2:special
krbSupportedEncSaltTypes: camellia128-cts-cmac:normal
krbSupportedEncSaltTypes: camellia128-cts-cmac:special
krbSupportedEncSaltTypes: camellia256-cts-cmac:normal
krbSupportedEncSaltTypes: camellia256-cts-cmac:special
krbDefaultEncSaltTypes: aes256-sha2:special
krbDefaultEncSaltTypes: aes128-sha2:special
krbDefaultEncSaltTypes: aes256-cts:special
krbDefaultEncSaltTypes: aes128-cts:special

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Thanks.

Do you have any additional configuration in /etc/krb5.conf.d/ on the CentOS 7 server?

permitted_enctypes, default_tgs_enctypes, and default_tkt_enctypes on RHEL 7 does not include aes-sha2 by default, only aes-sha1 types, hence no aes-sha2 in use. However, this issue is not reproducible in our automated RHEL 7 server vs RHEL 9 client tests, so there might be local configuration differences.

In /etc/krb5.conf.d/ empty
In /etc/krb5.conf :

includedir /etc/krb5.conf.d/
includedir /var/lib/sss/pubconf/krb5.include.d/

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = domain
dns_lookup_realm = false
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = true
udp_preference_limit = 0
default_ccache_name = KEYRING:persistent:%{uid}

[realms]
domain = {
kdc = dc02.domain:88
master_kdc = dc02.domain:88
admin_server = dc02.domain:749
default_domain = domain
pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
}

[domain_realm]
.domain = domain
domain = domain
dc02.domain = domain

[dbmodules]
domain = {
db_library = ipadb.so
}

[plugins]
certauth = {
module = ipakdb:kdb/ipadb.so
enable_only = ipakdb
}

On clients
/etc/krb5.conf.d/crypto-policies -> /etc/crypto-policies/back-ends/krb5.config :

[libdefaults]
permitted_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96

Yep, the client side looks fine.

In short, this is not reproducible in RHEL 7 and RHEL 9 environments.

On the other hand, current krb5 build for RHEL 7 is 1.15.1-55, since November 2022 (for about a year), so you are missing quite a number of bugfixes. They should not be relevant to this problem, though.

Since this is not something that can be fixed by FreeIPA team directly and the same scenario works in our environment with up to date RHEL 7/RHEL 9 setup, there is nothing we can do on our side. Please talk to your vendor.

Re-opening. The key moment is that it is only reproducible with non-admin-based enrollment. If admin enrolls the host, everything works. If enrollment is delegated using 'Host Enrollment' role, then this failure happens.

Most like we need to extend 'Host Enrollment' with a permission that would allow key generation with IPA protected operation write_keys. This is allowed by default to anyone who manages the host but it requires explicitly setting managedby on the host so is not useful for automated enrollments.

A prototype fix is by adding a new permission:

ipa permission-add 'Allow retrieve keytab for host' --right=write --bindtype=permission --type host --attrs='ipaProtectedOperation;write_keys' --attrs='ipaProtectedOperation;read_keys'

and associate this permission with one of privileges used by the users enrolling hosts. For example, 'Host Administrators' already do the host creation and keytab management:

 ipa privilege-add-permission  'Host Administrators' --permissions='Allow retrieve keytab for host'

Then if enrollment user is added to a role with that privilege, it will work.

$ ipa role-add-member 'Enrollment Administrator' --users enroller
  Role name: Enrollment Administrator
  Description: Enrollment Administrator responsible for client(host) enrollment
  Member users: enroller
  Privileges: Host Enrollment
-------------------------
Number of members added 1
-------------------------
$ ipa role-add-member 'IT Specialist' --users enroller
  Role name: IT Specialist
  Description: IT Specialist
  Member users: enroller
  Privileges: Host Administrators, Host Group Administrators, Service Administrators, Automount Administrators
-------------------------
Number of members added 1
-------------------------

Two roles are needed because 'Host Enrollment' role does not grant any permission to create host at enrollment. This is intentional.

This permission is missing in all supported versions of RHEL IdM and FreeIPA which causes the fallback to pre-4.0 method of setting the keys for hosts. Then older server generates something in the response that causes ipa-getkeytab to fail parse and skip these aes-sha1 encryption types.

```

PR: https://github.com/freeipa/freeipa/pull/7126

master:

• a5d38ca host: update System: Manage Host Keytab permission

ipa-4-9:

• 7a4a96b host: update System: Manage Host Keytab permission

ipa-4-10:

• b41089b host: update System: Manage Host Keytab permission

ipa-4-11:

• 3842116 host: update System: Manage Host Keytab permission

ipa-4-6:

• 3d92e25 host: update System: Manage Host Keytab permission