supported override method
by iulian roman
Hello,
I would like to do an override only for a set of servers , therefore not in the Default Trust View. I have created another view, where I added only the servers for which I want to do the override and the users + UIDs which I need to override. The Default Trust View is therefore empty.
Is the method above supported (not having anything in the Default Trust View, but in a newly defined custom ID view) ?
2 years, 7 months
post-save command to "ipa-getcert request" not working
by Ranbir
Hello Everyone,
I'm running an updated CentOS 8 KVM on an up to date CentOS 7 host. My
freeipa servers CentOS 7 hosts and fully updated, too. In the KVM I'm
requesting a certificate from my freeipa CA, which in and of itself
works just find. But, when I add a post-save command, that command is
never executed.
Here's the request I'm making:
ipa-getcert request -g 2048 -k /etc/pki/containers/sabnzbd-
server/sabnzbd-server.key -f /etc/pki/containers/sabnzbd-
server/sabnzbd-server.cert -K HTTP/sabnzbd.theinside.rnr -N
"CN=sabnzbd.theinside.rnr,O=THEINSIDE.RNR" -D sabnzbd.theinside.rnr -C
/usr/local/sbin/sabnzbd-server-certs -v -w
The content of that script is just a one liner for podman to copy the
contents of the /etc/pki/containers/sabnzbd-server/ directory to my
container. The script works without issue if I run it manually. I'm
also able to successfully run the podman command at a terminal.
At first I had the command in the script entered directly in the
request, which also didn't work. The bash script was my last attempt at
getting the post-save command to work.
I don't see any errors in the logs or in the terminal. In fact, it
looks like certmonger doesn't even attempt to run the post-save
command. Here's a short snippet from the log:
-- Logs begin at Sat 2021-07-24 17:02:34 EDT, end at Mon 2021-07-26 00:43:48 EDT. --
Jul 26 00:16:16 containment01 certmonger[109481]: Certificate in file "/etc/pki/containers/sabnzbd-server/sabnzbd-server.cert" issued by CA and saved.
Jul 26 00:16:16 containment01 certmonger[30743]: 2021-07-26 00:16:16 [30743] No hooks set for pre-save command.
Jul 26 00:16:16 containment01 certmonger[30743]: 2021-07-26 00:16:16 [30743] Certificate issued (0 chain certificates, 0 roots).
Jul 26 00:16:16 containment01 certmonger[30743]: ".
Jul 26 00:16:16 containment01 certmonger[30743]: -----END CERTIFICATE-----
Am I doing something wrong or have I hit a bug?
--
Ranbir
2 years, 7 months
ipahealthcheck.ds.dse.DSECheck.DSSKEWLE0003: The time skew is over 24 hours.
by Louis Lagendijk
Some time ago I hosed my freeipa setup (RHEL8, 3 servers), probably by
starting yum update pretty much at the same time, without realizing
that it would be better to spread it out a bit. This was at the time I
got the RHEL 8.4 updates.
One server seemed pretty messed up, so I deleted it from the topology
and re-executed the ipa-replica-install.
I deleted some duplicates from the replication, manally fixed the
password issue from https://github.com/dogtagpki/pki/issues/3650
on the re-installed server.
ipa-healthcheck now reports:
[root@ipa1 ipa-tools]# ipa-healthcheck --failures-only --output-type
human
CRITICAL: ipahealthcheck.ds.dse.DSECheck.DSSKEWLE0003: The time skew is
over 24 hours. Setting nsslapd-ignore-time-skew
to "on" on each replica will allow replication to continue, but if the
time skew continues to increase other serious replication problems can
occur.
ERROR: ipahealthcheck.ds.dse.DSECheck.DSSKEWLE0002: The time skew is
over 12 hours. If this time skew continues to increase
to 24 hours then replication can potentially stop working. Please
continue to
monitor the time skew offsets for increasing values. Setting nsslapd-
ignore-time-skew
to "on" on each replica will allow replication to continue, but if the
time skew
continues to increase other more serious replication problems can
occur.
I got the following from ds389:
[root@ipa1 ipa-tools]# dsctl slapd-HOME-FAZANT-NET get-nsstate
Replica
DN: cn=replica,cn=dc\3dhome\2cdc\3dfazant\2cdc\3dnet,cn=mappi
ng tree,cn=config
Replica Suffix: dc=home,dc=fazant,dc=net
Replica ID: 21
Gen Time: 1627578955
Gen Time String: Thu Jul 29 19:15:55 2021
Gen as CSN: 6102e24b000400210000
Local Offset: 0
Local Offset String: 0 seconds
Remote Offset: 591807
Remote Offset String: 6 days, 20 hours, 23 minutes, 27 seconds
Time Skew: 591807
Time Skew String: 6 days, 20 hours, 23 minutes, 27 seconds
Seq Num: 4
System Time: Thu Jul 29 19:17:08 2021
Diff in Seconds: 73
Diff in days/secs: 0:73
Endian: Little Endian
Replica DN: cn=replica,cn=o\3dipaca,cn=mapping tree,cn=config
Replica Suffix: o=ipaca
Replica ID: 22
Gen Time: 1627578483
Gen Time String: Thu Jul 29 19:08:03 2021
Gen as CSN: 6102e073000000220000
Local Offset: 0
Local Offset String: 0 seconds
Remote Offset: 81231
Remote Offset String: 22 hours, 33 minutes, 51 seconds
Time Skew: 81231
Time Skew String: 22 hours, 33 minutes, 51 seconds
Seq Num: 0
System Time: Thu Jul 29 19:17:08 2021
Diff in Seconds: 545
Diff in days/secs: 0:545
Endian: Little Endian
I have no idea how to solve this issue. Apparently my google-fu is not
strong enough to find a solution. Can you guys please give me some
hints?
Thanks. Louis
2 years, 7 months
Changing directory manager password
by Ian Pilcher
Maybe it's just me, but I still find the documentation on this subject
confusing. (This is probably because the docs seem to be telling me
that I don't need to do anything beyond the actual password change, and
I don't trust answers that seem too easy.)
I running a single-node IPA 4.6.8 on RHEL 7. The actual password change
with ldapmodify[1] is simple enough. Am I reading the FreeIPA
documentation[2] correctly, that I don't need to perform any other
steps?
Thanks!
[1]
https://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpas...
[2] https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password
--
========================================================================
Ian Pilcher Sr. Principal Product Manager
+1 469 892-8704 Red Hat Cloud Platforms
========================================================================
2 years, 8 months
failure to sync with replicas
by Scott Serr
I'm running 5 ipa servers with (the latest on CentOS 8) 4.9.2.
Synchronization had stopped yesterday and also 3 days ago. It actually
stopped yesterday after I stopped / modified / started "ipa1" to
configure rotating logs longer so I could track down what happened 3
days ago.
2021-07-27 17:22:46 ipactl stop
2021-07-27 17:22:59 emacs dse.ldif # Modify to access and error log
rotation values
2021-07-27 17:23:45 ipactl start
Below seems to be what kicked off the bad behavior. I've seen a few
posts about removing the keys out of dse.ldif when this happens. I'm a
bit leery of doing this, as I don't fully understand what is going on.
(is it comparable to clearing out known_host entries when using ssh?)
[27/Jul/2021:17:23:49.818525015 -0600] - ERR - attrcrypt_unwrap_key -
Failed to unwrap key for cipher AES
[27/Jul/2021:17:23:49.820422259 -0600] - ERR - attrcrypt_cipher_init -
Symmetric key failed to unwrap with the private key; Cert might have
been renewed since the
key is wrapped. To recover the encrypted contents, keep the wrapped
symmetric key value.
[27/Jul/2021:17:23:50.040967207 -0600] - ERR - attrcrypt_unwrap_key -
Failed to unwrap key for cipher 3DES
[27/Jul/2021:17:23:50.043074553 -0600] - ERR - attrcrypt_cipher_init -
Symmetric key failed to unwrap with the private key; Cert might have
been renewed since the
key is wrapped. To recover the encrypted contents, keep the wrapped
symmetric key value.
[27/Jul/2021:17:23:50.044268421 -0600] - ERR - attrcrypt_init - All
prepared ciphers are not available. Please disable attribute encryption.
[27/Jul/2021:17:23:50.263786473 -0600] - ERR - attrcrypt_unwrap_key -
Failed to unwrap key for cipher AES
[27/Jul/2021:17:23:50.266090934 -0600] - ERR - attrcrypt_cipher_init -
Symmetric key failed to unwrap with the private key; Cert might have
been renewed since the key is wrapped. To recover the encrypted
contents, keep the wrapped symmetric key value.
[27/Jul/2021:17:23:50.470918523 -0600] - ERR - attrcrypt_unwrap_key -
Failed to unwrap key for cipher 3DES
[27/Jul/2021:17:23:50.472915669 -0600] - ERR - attrcrypt_cipher_init -
Symmetric key failed to unwrap with the private key; Cert might have
been renewed since the key is wrapped. To recover the encrypted
contents, keep the wrapped symmetric key value.
[27/Jul/2021:17:23:50.474282471 -0600] - ERR - attrcrypt_init - All
prepared ciphers are not available. Please disable attribute encryption.
[27/Jul/2021:17:23:50.891048127 -0600] - ERR - schema-compat-plugin -
scheduled schema-compat-plugin tree scan in about 5 seconds after the
server startup!
Then ipa1 can't talk to the replicas (ipa2,ipa3,ipa5,ipa6) shown below:
[27/Jul/2021:17:23:51.081696109 -0600] - ERR - set_krb5_creds - Could
not get initial credentials for principal
[ldap/ipa1.hpc.example.com(a)HPC.EXAMPLE.COM] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
requested realm)
[27/Jul/2021:17:23:51.086755379 -0600] - ERR - NSMMReplicationPlugin -
bind_and_check_pwp - agmt="cn=meToipa4.hpc.example.com" (ipa4:389) -
Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact
LDAP server) ()
[27/Jul/2021:17:23:51.091748474 -0600] - ERR - set_krb5_creds - Could
not get initial credentials for principal
[ldap/ipa1.hpc.example.com(a)HPC.EXAMPLE.COM] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
requested realm)
[27/Jul/2021:17:23:51.093430455 -0600] - ERR - NSMMReplicationPlugin -
bind_and_check_pwp -
agmt="cn=ipa1.hpc.example.com-to-ipa6.hpc.example.com" (ipa6:389) -
Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact
LDAP server) ()
[27/Jul/2021:17:23:51.094725291 -0600] - ERR - schema-compat-plugin -
schema-compat-plugin tree scan will start in about 5 seconds!
[27/Jul/2021:17:23:51.096059194 -0600] - ERR - set_krb5_creds - Could
not get initial credentials for principal
[ldap/ipa1.hpc.example.com(a)HPC.EXAMPLE.COM] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
requested realm)
[27/Jul/2021:17:23:51.097152619 -0600] - INFO - slapd_daemon - slapd
started. Listening on All Interfaces port 389 for LDAP requests
[27/Jul/2021:17:23:51.098356748 -0600] - INFO - slapd_daemon - Listening
on All Interfaces port 636 for LDAPS requests
[27/Jul/2021:17:23:51.099577958 -0600] - INFO - slapd_daemon - Listening
on /var/run/slapd-HPC-EXAMPLE-COM.socket for LDAPI requests
[27/Jul/2021:17:23:51.100701349 -0600] - ERR - NSMMReplicationPlugin -
bind_and_check_pwp - agmt="cn=caToipa3.hpc.example.com" (ipa3:389) -
Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact
LDAP server) ()
[27/Jul/2021:17:23:51.101782194 -0600] - ERR - set_krb5_creds - Could
not get initial credentials for principal
[ldap/ipa1.hpc.example.com(a)HPC.EXAMPLE.COM] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
requested realm)
[27/Jul/2021:17:23:51.103848248 -0600] - ERR - NSMMReplicationPlugin -
bind_and_check_pwp - agmt="cn=caToipa5.hpc.example.com" (ipa5:389) -
Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact
LDAP server) ()
[27/Jul/2021:17:23:58.152621025 -0600] - ERR - schema-compat-plugin -
Finished plugin initialization.
[27/Jul/2021:17:24:21.201225830 -0600] - ERR - NSMMReplicationPlugin -
bind_and_check_pwp - agmt="cn=meToipa2.hpc.example.com" (ipa2:389) -
Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact
LDAP server) ()
[27/Jul/2021:17:24:21.203158794 -0600] - ERR - NSMMReplicationPlugin -
bind_and_check_pwp -
agmt="cn=ipa1.hpc.example.com-to-ipa6.hpc.example.com" (ipa6:389) -
Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact
LDAP server) ()
[27/Jul/2021:17:24:21.204833314 -0600] - ERR - NSMMReplicationPlugin -
bind_and_check_pwp - agmt="cn=meToipa3.hpc.example.com" (ipa3:389) -
Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact
LDAP server) ()
[27/Jul/2021:17:24:21.206099975 -0600] - ERR - NSMMReplicationPlugin -
bind_and_check_pwp - agmt="cn=meToipa5.hpc.example.com" (ipa5:389) -
Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact
LDAP server) ()
[27/Jul/2021:17:54:03.675297221 -0600] - ERR - NSMMReplicationPlugin -
bind_and_check_pwp - agmt="cn=caToipa2.hpc.example.com" (ipa2:389) -
Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact
LDAP server) ()
After realizing I had a problem this morning, I rebooted ipa1 but it did
not help syncing. I re-initialized ipa1 from ipa3, this got them all
authenticating to each other and in sync.
[28/Jul/2021:08:09:10.347094254 -0600] - INFO - NSMMReplicationPlugin -
bind_and_check_pwp - agmt="cn=caToipa3.hpc.inl.gov" (ipa3:389):
Replication bind with GSSAPI auth resumed
[28/Jul/2021:08:09:10.449170075 -0600] - INFO - NSMMReplicationPlugin -
bind_and_check_pwp - agmt="cn=meToipa3.hpc.inl.gov" (ipa3:389):
Replication bind with GSSAPI auth resumed
[....]
I changed the Data Manager password with "dsconf" -- but that was
between the first failure and the second. Could that be causing
problems? What direction to go from here? Thank you!
Scott
2 years, 8 months
sssd_nss error - GetAccountDomain() not supported
by iulian roman
Hello,
I see the following error in the sssd_nss logs on the IPA server:
[nss] [cache_req_common_get_acct_domain_recv] (0x0080): CR #2: Could not get account domain [1432158301]: GetAccountDomain() not supported
That seems to be related to the error bellow , which I get when running groups <user_name>:
groups: cannot find name for group ID
Any idea where does it come from (is if from AD or from IPA server) and how can it be solved ?
2 years, 8 months
Network I/O error when trying to resolve AD users
by Ronald Wimmer
Today I set up an IPA test web application in our IPA test environment.
I figured out that my AD user was resolved but the user of my colleague
was not. (getent passwd userA/userB)
I stopped SSSD, cleared the cache with 'rm -rf /var/lib/sss/db/*' and
started SSSD again. After that I could not resolve any AD user. The sssd
logs showed an Network I/O error:
==> /var/log/sssd/sssd_ipatest.mydomain.at.log <==
(2021-06-30 11:46:14): [be[ipatest.mydomain.at]] [ipa_s2n_exop_done]
(0x0040): ldap_extended_operation result: Operations error(1), Failed to
handle the request.
.
(2021-06-30 11:46:14): [be[ipatest.mydomain.at]] [ipa_s2n_exop_done]
(0x0040): ldap_extended_operation failed, server logs might contain more
details.
(2021-06-30 11:46:14): [be[ipatest.mydomain.at]] [ipa_s2n_get_user_done]
(0x0040): s2n exop request failed.
(2021-06-30 11:46:14): [be[ipatest.mydomain.at]]
[ipa_subdomain_account_done] (0x0040): ipa_get_*_acct request failed:
[1432158230]: Network I/O Error.
==> /var/log/sssd/sssd_nss.log <==
(2021-06-30 11:46:14): [nss] [cache_req_common_process_dp_reply]
(0x0040): CR #197: Data Provider Error: 3, 1432158230, Network I/O Error
(2021-06-30 11:46:14): [nss] [cache_req_common_process_dp_reply]
(0x0400): CR #197: Due to an error we will return cached data
(2021-06-30 11:46:14): [nss] [cache_req_search_cache] (0x0400): CR #197:
Looking up [aduser271(a)ORG.MYDOMAIN.AT] in cache
(2021-06-30 11:46:14): [nss] [cache_req_search_cache] (0x0400): CR #197:
Object [aduser271(a)ORG.MYDOMAIN.AT] was not found in cache
(2021-06-30 11:46:14): [nss] [cache_req_process_result] (0x0400): CR
#197: Finished: Not found
(2021-06-30 11:46:14): [nss] [client_recv] (0x0200): Client disconnected!
What the hell is going on here? Any hints would be highly appreciated!
Cheers,
Ronald
2 years, 8 months
Revisting Add user -> custom script
by Chris Candreva
10 years ago, a user asked running a custom script on user creation, to
take care of disk provisioning.
https://freeipa-users.redhat.narkive.com/eSX61h7t/add-user-custom-script
Having the same need I found this post, however nothing about the posted
plugin seems to currently work.
I've determined so far the plugin location moved from ipalib to ipa
server. I've changed the class. The logging didn't work, and the passing
of 'dn' gave a type error. The minimal version below at least doesn't
generate any errors, but also does not run the script (which simple echos
output to a /tmp/cxc.log file.
I would appreciate any assistance either pointing to an already updated
version of this type of plugin, assistance doing so, or someone
knowledgable updating it for IPA 4.9.2
/usr/lib/python3.6/site-packages/ipaserver/plugins/cript_post_add_callback.py
```
from ipapython import ipautil
from ipaserver.plugins.user import user_add
def script_post_add_callback(inst, ldap, dn, attrs_list, *keys, **options):
# inst.log.error('User added')
# if 'ipa_user_script' in inst.api.env:
# try:
ipautil.run(['/usr/local/sbin/cxc.sh',"add", "dn"])
# except:
# pass
return dn
```
/usr/local/sbin/cxc.sh
```
#!/bin/bash
echo "Hello, world: $1 $2" >>/tmp/cxc.log
```
---
========================================================================
Chris Candreva -- chris(a)westnet.com -- http://www.westnet.com/~chris
2 years, 8 months
One way Trust with AD with ID Views for Groups is not working as expected
by Peter Tselios
What I have:
AD Domain: Example.com
IPA Domain lx.example.com
CentOS 7.9
sssd 1.16
IPA is a master a 2 replicas. All the machines have the following configuration:
Max domain level: 1
Enabled server roles: CA server, IPA master, DNS server, NTP server, AD trust agent, AD trust controller
We use ID Views for both Users and Groups in AD.
Our issues are with the ID Views for the groups.
We constantly get the following error:
/usr/bin/id: cannot find name for group ID XXX
The XXX is the GID defined in the ID View of the user.
The problem is resolved if I do one of the following:
===============================
[username@ipa_client]: cd /home
ls -lrt
===============================
OR
getent group <GID>
OR
getent group <ID View groupname>
OR
getent group <ad_groupname@domain>
Of course, the issue is returning when cache is expired or when a **new** user that has the same primary GID tries to login on a server.
What kind of information would you need in order to help me to solve this issue?
2 years, 8 months
Re: 回复: Login failed after upgrade
by Rob Crittenden
Thanks for closing the loop on this. It may help others than run it this.
regards
rob
胡 玮文 via FreeIPA-users wrote:
> Hi,
>
> It turns out this is a docker specific problem when the container is run with --privileged
>
> See https://github.com/freeipa/freeipa-container/issues/383#issuecomment-8867... for more
>
> ________________________________________
> 发件人: 胡 玮文 <huww98(a)outlook.com>
> 发送时间: 2021年7月26日 11:15
> 收件人: freeipa-users(a)lists.fedorahosted.org
> 主题: Login failed after upgrade
>
> Hi all,
>
> Some similar issues have appeared on this list several times, but I think mine is different.
>
> I have a docker deployment with 2 replicas. I upgraded them from docker image freeipa/freeipa-server:fedora-33-4.9.2 to fedora-34-4.9.6. The upgrade process goes smoothly. However, now I cannot log in into web-UI, with the error "Login failed due to an unknown reason", and every ipa command returns "ipa: ERROR: No valid Negotiate header in server response". 2 replicas report the same error and reboot does not help. But kinit works.
>
> The strange thing is that no "fail" message in kdc log. So I don't have any idea what may go wrong. ipa-healthcheck reports 2 warning, but they seem not relevant here: "No DNA range defined" and missing ipa-ca AAAA records (we don't have IPv6 address now, so manually removed AAAA)
>
> Some previous threads indicate an outdated keytab, but It seems not my case. "kinit -k -t /var/lib/ipa/gssproxy/http.keytab HTTP/ipa1.mydomain.com(a)MYDOMAIN.COM" works fine.
>
> Any help is very appreciated.
>
> Thanks
> Hu Weiwen
>
> /var/log/httpd/error_log:
>
> [auth_gssapi:error] [pid 2062:tid 2117] [client fe80::a242:3fff:fe37:52fb%enp13s0f1:60752] GSS ERROR gss_acquire_cred[_from]() failed to get server creds: [Unspecified GSS failure. Minor code may provide more information ( SPNEGO cannot find mechanisms to negotiate)]
> [wsgi:error] [pid 2056:tid 2353] [remote 125.216.246.30:12133] ipa: INFO: 401 Unauthorized: No session cookie found
>
> /var/log/krb5kdc.log
>
> krb5kdc[2041](info): AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17), camellia128-cts-cmac(25)}) 202.38.247.181: NEEDED_PREAUTH: WELLKNOWN/ANONYMOUS(a)MYDOMAIN.COM for krbtgt/MYDOMAIN.COM(a)MYDOMAIN.COM, Additional pre-authentication required
> krb5kdc[2041](info): closing down fd 11
> krb5kdc[2027](info): AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17), camellia128-cts-cmac(25)}) 202.38.247.181: ISSUE: authtime 1627268346, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, WELLKNOWN/ANONYMOUS(a)MYDOMAIN.COM for krbtgt/MYDOMAIN.COM(a)MYDOMAIN.COM
> krb5kdc[2027](info): closing down fd 11
> krb5kdc[2027](info): AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17), camellia128-cts-cmac(25)}) 202.38.247.181: NEEDED_PREAUTH: myusername(a)MYDOMAIN.COM for krbtgt/MYDOMAIN.COM(a)MYDOMAIN.COM, Additional pre-authentication required
> krb5kdc[2027](info): closing down fd 11
> krb5kdc[2027](info): AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17), camellia128-cts-cmac(25)}) 202.38.247.181: ISSUE: authtime 1627268346, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, myusername(a)MYDOMAIN.COM for krbtgt/MYDOMAIN.COM(a)MYDOMAIN.COM
> krb5kdc[2027](info): closing down fd 11
> krb5kdc[2027](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17), camellia128-cts-cmac(25)}) 202.38.247.181: ISSUE: authtime 1627268346, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, myusername(a)MYDOMAIN.COM for HTTP/ipa1.mydomain.com(a)MYDOMAIN.COM
> krb5kdc[2027](info): closing down fd 11
>
> journalctl does not show any error. "systemctl status" reports every service is running
> _______________________________________________
> 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
>
2 years, 8 months