Re: Installing CA certificate isuue
by mskaraca＠yahoo.com
Hi
I just wanted to say thank you to this list and especially to Rob Crittenden..
I could not log in to freeipa-users, there may be a problem in logging in with social network accounts. So I am sending this as an email..
Firstly My issue was freeIpa was refusing to install my comodo certificate with a signature algorithm complain.
I am writing how I solved this issue with a complete CLI
#recommended by Rob and significant milestone in solving my problemupdate-crypto-policies --set DEFAULT:SHA1#I received ca-bundle from my CA with my CRT file sudo ipa-cacert-manage -t C,, install my-domain.ca-bundle sudo ipa-certupdate #pem file incudes all the certificate authority chain.. sudo ipa-server-certinstall --http --dirsrv mydomain.key mydomain.pem
I have only one questionWhy didIı need to add this ca file to my freeIPA server? I mean it is already sgined with a public CA? web servers can easily see and do not throw any error when I install this certificate. but same is not true when I install this certificate in IDM or in anyting other than a web server.. so why do they not know my CA automaticaly?
is it because this is especially designed for HTTPS connections? Do I need to request something different or from another vendor, such as verisgn?
Thanks again..
3 months, 2 weeks
idrange problem
by Steve Berg
For a few weeks now I've been seeing a problem getting authenticated to
my ipa domain. I can get command line and web UI stuff done by using
the admin user but if I get a ticket using my account which is in the
admins group I get the following on the web UI:
Your session has expired. Please log in again.
On the command line any ipa commands I've tried so far give me:
ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI
Error: Unspecified GSS failure. Minor code may provide more information
(Credential cache is empty)
Getting a ticket as admin on command line lets me run ipa commands with
no problem. I think I've got all pertinent certificates loaded up
properly. Gonna try a reboot on one of the servers shortly. I have 4
servers on r different vlans, replication between seems to be working
properly.
I think the problem is most of the user ID's we use on this domain are
not in the ID range configured. We let the install choose a default
range when we first set this up. Most of our users have a UID based on
their EDIPI # which is a 32-bit ID assigned when a user first gets a DoD
CAC. They're usually 10 digits long.
For instance the lowest EDIPI based UID we have currently is something
like 1004201873 and the largest is 1658224121. (I made those but
they're close to the actual UIDs.)
ipa idrange-find show me this, (did some masking of the info):
Range name: domain_id_range
First Posix ID of the range: 824xxx000
Number of IDs in the range: 200000
First RID of the corresponding RID range: 1000
First RID of the secondary RID range: 100000000
Range name: domain_subid_range
First Posix ID of the range: 214xxx3648
Number of IDs in the range: 214xxx2576
First RID of the corresponding RID range: 214xxx3648
Domain SID of the trusted domain: S-1-5-21-xxxxxx-83xx66-82xxx729
Range type: Active Directory domain range
Should I adjust the range that's already there or add a third that
encompasses the likely range of numbers I'm gonna see in the future? I
started to add a range with appropriate values but when it wanted the
primary and secondary RID base values I was not sure how to figure that
out or estimate.
--
//- Fixer of that which is broke -//
//- Home =sberg(a)mississippi.com -//
//- Sinners can repent, but stupid is forever. -//
3 months, 2 weeks
reliability of external radius
by Charles Hedrick
Currently our department uses passwords in IPA, with a few users using OTP. I'm considering using a University radius server for most users. Are there reliability implications? My concern is what happens if the radius server is slow to respond or even is down. I'd like users with accounts in IPA to still work, and I'd hope things would survive conditions of slow response.
3 months, 2 weeks
Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working
by Oliver Nixon
Hi,
I'm encountering the same issue after upgrading to 4.9.12.
I had previously imported users from another FreeIPA deployment and their UIDs were outside of the defined ID ranges.
I've created a new ID range to encompass these and run the following but the SIDs still don't get generated:
]# /usr/libexec/ipa/oddjob/org.freeipa.server.config-enable-sid --netbios-name DOMAIN-NAME --add-sids
Configuring SID generation
[1/8]: creating samba domain object
Samba domain object already exists
[2/8]: adding admin(group) SIDs
Admin SID already set, nothing to do
Admin group SID already set, nothing to do
[3/8]: adding RID bases
RID bases already set, nothing to do
[4/8]: updating Kerberos config
'dns_lookup_kdc' already set to 'true', nothing to do.
[5/8]: activating sidgen task
Sidgen task plugin already configured, nothing to do
[6/8]: restarting Directory Server to take MS PAC and LDAP plugins changes into account
[7/8]: adding fallback group
Fallback group already set, nothing to do
[8/8]: adding SIDs to existing users and groups
This step may take considerable amount of time, please wait..
Done.
3 months, 3 weeks
replication troubles
by Natxo Asenjo
hi,
we are having some trouble with our rhel 7 to rhel 8 migration and after
checking some things, it became apparent the replication is mostly broken
among the idm servers
I see in the errors:
agmt=%s(%s:%d): Can't locate CSN %s in the changelog (DB rc=%d). The
consumer may need to be reinitialized
According to this:
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11...
Reason: Most likely the changelog was recreated because of the disk is full
or the server ungracefully shutdown.
/var/log on this hosts was full recently, so this could have caused this
indeed.
I also see:
ERR - NSMMReplicationPlugin - send_updates - .... : data required to update
replica has been purged from the changelog, if the error persists the
replica must be reinitialized.
This is pretty clear.
So this server is the ca master.
The domain level is 1.
The rhel version is right now 7.9.
If I reinitialize this server with the ca role (master), with other server,
will it overwrite the CA?
--
Regards,
natxo
3 months, 3 weeks
Permission to create and manage OTP Tokens for non-admin user
by Russ Long
There have been a couple threads about this in this forum, but I have not been able to make anything work from those threads. I have a group of non-admin users that I would like to have able to manage OTP tokens for all users.
I have attempted to create a permission, and have assigned it to the users via a privilege.
Here's the permission:
$ ipa permission-show test --all --raw
dn: cn=test,cn=permissions,cn=pbac,dc=ipa,dc=example,dc=com
cn: test
ipapermright: all
ipapermincludedattr: ipatokentotptimestep
ipapermincludedattr: ipatokenotpalgorithm
ipapermincludedattr: ipatokentotpwatermark
ipapermincludedattr: ipatokenowner
ipapermincludedattr: ipatokenotpdigits
ipapermincludedattr: ipatokenuniqueid
ipapermincludedattr: ipatokentotpclockoffset
ipapermincludedattr: ipatokenotpkey
ipapermincludedattr: cn
ipapermincludedattr: ipatokenhotpsyncwindow
ipapermincludedattr: ipatokenhotpauthwindow
ipapermincludedattr: ipatokentotpsyncwindow
ipapermincludedattr: ipatokentotpauthwindow
ipapermbindruletype: permission
ipapermlocation: cn=otp,cn=etc,dc=ipa,dc=example,dc=com
ipapermtargetfilter: (objectclass=ipatokenotpconfig)
ipapermissiontype: SYSTEM
ipapermissiontype: V2
aci: (targetattr = "cn || ipatokenhotpauthwindow || ipatokenhotpsyncwindow || ipatokenotpalgorithm || ipatokenotpdigits || ipatokenotpkey || ipatokenowner || ipatokentotpauthwindow || ipatokentotpclockoffset || ipatokentotpsyncwindow || ipatokentotptimestep || ipatokentotpwatermark || ipatokenuniqueid")(targetfilter = "(objectclass=ipatokenotpconfig)")(version 3.0;acl "permission:test";allow (all) groupdn = "ldap:///cn=testrl,cn=permissions,cn=pbac,dc=ipa,dc=example,dc=com";)
objectclass: top
objectclass: groupofnames
objectclass: ipapermission
objectclass: ipapermissionv2
(membership information removed from above output, but it shows the proper members)
When users with this permission attempt to see OTP tokens, they can only see their own tokens.
Any ideas would be greatly appreciated.
3 months, 3 weeks
certmonger error on ubuntu
by Robson Francisco de Souza
Hello!
I've been running FreeIPA 4.3.1 on Ubuntu 16.04 for almost two years and
most certificates should expire within three weeks. As this deadline
approaches, I noticed certmonger has been unable to renew certificates due
to the error below.
After googling for two days, I found this issue has been observed by many
people before, mostly after expiration of the certificates, as in
https://tinyurl.com/vajmocw
Still, I couldn't find a solution to this problem.
If it is impossible to fix this issue while using FreeIPA 4.3.1, I would
like to:
1) Find a way to renew all certificates even if certmonger can't be fixed.
This would allow me to postpone the solution to after the next OS and/or
FreeIPA upgrade
2) Find out what version of FreeIPA I should upgrade to while the operating
system remains Ubuntu 16.04
Any help would be appreciated!
Thanks!
Robson
======> Command: systemctl status certmonger
Nov 17 20:53:08 ipa.cefapnet.icb.usp.br certmonger[3873125]: 2019-11-17
20:53:08 [3873125] Error 77 connecting to
https://ipa.cefapnet.icb.usp.br:8443/ca/agent/ca/profileReview: Problem
with the SSL CA cert (path? access rights?).
Nov 17 21:10:13 ipa.cefapnet.icb.usp.br
dogtag-ipa-ca-renew-agent-submit[3875188]: Forwarding request to
dogtag-ipa-renew-agent
Nov 17 21:10:13 ipa.cefapnet.icb.usp.br
dogtag-ipa-ca-renew-agent-submit[3875188]: dogtag-ipa-renew-agent returned 3
Nov 17 21:10:13 ipa.cefapnet.icb.usp.br certmonger[3873125]: 2019-11-17
21:10:13 [3873125] Error 77 connecting to
https://ipa.cefapnet.icb.usp.br:8443/ca/agent/ca/profileReview: Problem
with the SSL CA cert (path? access rights?).
Nov 17 21:25:20 ipa.cefapnet.icb.usp.br
dogtag-ipa-ca-renew-agent-submit[3875738]: Forwarding request to
dogtag-ipa-renew-agent
Nov 17 21:25:20 ipa.cefapnet.icb.usp.br
dogtag-ipa-ca-renew-agent-submit[3875738]: dogtag-ipa-renew-agent returned 3
Nov 17 21:25:21 ipa.cefapnet.icb.usp.br certmonger[3873125]: 2019-11-17
21:25:21 [3873125] Error 77 connecting to
https://ipa.cefapnet.icb.usp.br:8443/ca/agent/ca/profileReview: Problem
with the SSL CA cert (path? access rights?).
Nov 17 21:25:31 ipa.cefapnet.icb.usp.br
dogtag-ipa-ca-renew-agent-submit[3875766]: Forwarding request to
dogtag-ipa-renew-agent
Nov 17 21:25:31 ipa.cefapnet.icb.usp.br
dogtag-ipa-ca-renew-agent-submit[3875766]: dogtag-ipa-renew-agent returned 3
Nov 17 21:25:31 ipa.cefapnet.icb.usp.br certmonger[3873125]: 2019-11-17
21:25:31 [3873125] Error 77 connecting to
https://ipa.cefapnet.icb.usp.br:8443/ca/agent/ca/profileReview: Problem
with the SSL CA cert (path? access rights?).
--
Robson Francisco de Souza, PhD
Laboratório de Estrutura e Evolução de Proteínas (LEEP/PSEL)
Departamento de Microbiologia
Instituto de Ciências Biomédicas
Universidade de São Paulo
Av. Prof. Lineu Prestes, 1374 - Ed. Biomédicas II - Sala 250 - 2o. andar
Tel: 3091-0891
Cidade Universitária - CEP 05508-900 - São Paulo - SP - Brasil
----
Robson Francisco de Souza, PhD
Protein Structure and Evolution Laboratory (LEEP/PSEL)
Microbiology Departament
Biomedical Sciences Institute
University of Sao Paulo
Av. Prof. Lineu Prestes, 1374 - Biomédicas II - Sala 250
Phone: 55-11-3091-0891
Cidade Universitária - ZIP 05508-900 - São Paulo - SP - Brazil
3 months, 3 weeks
bind-dyndb-ldap caching
by brendan kearney
i am using the bind-dyndb-ldap plugin on my internal authoritative dns
servers, and have found that there is little to no caching going on in
bind. i am looking to understand if this is misconfiguration on my
part, or if this is a functional tradeoff when using a ldap backend.
when i delete the previous "rndc stats" output file and then run the
command to get the latest output, i can see that cache hits and many
other cache related stats are 0. i am wondering if is expected
behavior.
i am attaching the "rndc stats" output from my 3 internal bind
servers, and the same output from a caching recusrive resolver that
all clients are configured to use. the 3 internal servers show little
to no caching, while the recursive resolver shows many cache hits.
the configs between all 4 instances are very similar, and nothiing
stands out as specifically implementing caching in the recursive
instance.
would there be any insight as to what i might be doing wrong or not
doing, that is causing the lack of caching on the instances that use
bind-dyndb-ldap?
thanks,
brendan
3 months, 3 weeks
Re: FreeIPA web UI login's failing
by Rob Crittenden
Marc Pearson | i-Neda Ltd via FreeIPA-users wrote:
> Hello, looking for some help.
>
> Weve recently noted that the majority of our web UIs have started to
> fail to login. I have at least 1 thats still allowing log-ins at present.
>
> When attempting to login, we get a 401 unauthorised in the networking
> tab for the login POST request, and a banner appears: Your session has
> expired. Please log in again.
>
> In the kerbos logs I see the following:
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1861](info): AS_REQ (6
> etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
> aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
> camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.13.3.111:
> NEEDED_PREAUTH: WELLKNOWN/ANONYMOUS(a)INT.I-NEDA.COM
> <mailto:WELLKNOWN/ANONYMOUS@INT.I-NEDA.COM> for
> krbtgt/INT.I-NEDA.COM(a)INT.I-NEDA.COM
> <mailto:krbtgt/INT.I-NEDA.COM@INT.I-NEDA.COM>, Additional
> pre-authentication required
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1861](info): closing
> down fd 12
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): AS_REQ (6
> etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
> aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
> camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.13.3.111: ISSUE:
> authtime 1707232119, etypes {rep=aes256-cts-hmac-sha384-192(20),
> tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)},
> WELLKNOWN/ANONYMOUS(a)INT.I-NEDA.COM
> <mailto:WELLKNOWN/ANONYMOUS@INT.I-NEDA.COM> for
> krbtgt/INT.I-NEDA.COM(a)INT.I-NEDA.COM
> <mailto:krbtgt/INT.I-NEDA.COM@INT.I-NEDA.COM>
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): closing
> down fd 12
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): AS_REQ (6
> etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
> aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
> camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.13.3.111:
> NEEDED_PREAUTH: marc.admin(a)INT.I-NEDA.COM
> <mailto:marc.admin@INT.I-NEDA.COM> for
> krbtgt/INT.I-NEDA.COM(a)INT.I-NEDA.COM
> <mailto:krbtgt/INT.I-NEDA.COM@INT.I-NEDA.COM>, Additional
> pre-authentication required
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): closing
> down fd 12
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): AS_REQ (6
> etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
> aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
> camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.13.3.111: ISSUE:
> authtime 1707232119, etypes {rep=aes256-cts-hmac-sha1-96(18),
> tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)},
> marc.admin(a)INT.I-NEDA.COM <mailto:marc.admin@INT.I-NEDA.COM> for
> krbtgt/INT.I-NEDA.COM(a)INT.I-NEDA.COM
> <mailto:krbtgt/INT.I-NEDA.COM@INT.I-NEDA.COM>
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): closing
> down fd 12
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1861](info): TGS_REQ (6
> etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
> aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
> camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.13.3.111: ISSUE:
> authtime 1707232119, etypes {rep=aes256-cts-hmac-sha1-96(18),
> tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)},
> marc.admin(a)INT.I-NEDA.COM <mailto:marc.admin@INT.I-NEDA.COM> for
> HTTP/red-ipa01.int.i-neda.com(a)INT.I-NEDA.COM
> <mailto:HTTP/red-ipa01.int.i-neda.com@INT.I-NEDA.COM>
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1861](info): closing
> down fd 12
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): TGS_REQ (6
> etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
> aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
> camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.13.3.111:
> S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1707232119, etypes
> {rep=UNSUPPORTED:(0)} HTTP/red-ipa01.int.i-neda.com(a)INT.I-NEDA.COM
> <mailto:HTTP/red-ipa01.int.i-neda.com@INT.I-NEDA.COM> for
> ldap/red-ipa01.int.i-neda.com(a)INT.I-NEDA.COM
> <mailto:ldap/red-ipa01.int.i-neda.com@INT.I-NEDA.COM>, KDC policy
> rejects request
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): ...
> CONSTRAINED-DELEGATION s4u-client=<unknown>
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): closing
> down fd 12
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): TGS_REQ (6
> etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
> aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
> camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.13.3.111:
> S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1707232119, etypes
> {rep=UNSUPPORTED:(0)} HTTP/red-ipa01.int.i-neda.com(a)INT.I-NEDA.COM
> <mailto:HTTP/red-ipa01.int.i-neda.com@INT.I-NEDA.COM> for
> ldap/red-ipa01.int.i-neda.com(a)INT.I-NEDA.COM
> <mailto:ldap/red-ipa01.int.i-neda.com@INT.I-NEDA.COM>, KDC policy
> rejects request
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): ...
> CONSTRAINED-DELEGATION s4u-client=<unknown>
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): closing
> down fd 12
>
> We are not having issue with other parts of the authing system as we are
> still able to ssh into servers, use sudo over shared auth etc. And we
> can verify the issue isnt config on the cluster side. These hosts are
> update regularly in a round robin. One host that is allowing web-ui
> access was updated and restarted last night, so dont believe its a
> package / code level issue either.
>
> Any help or pointers would be greatly appreciated.
Please check this list archives. IPA now requires a PAC. This means
every user needs a SID. It is likely yours is missing it.
rob
>
> Regards,
>
> Marc.
>
>
> --
> _______________________________________________
> 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, report it: https://pagure.io/fedora-infrastructure/new_issue
>
3 months, 3 weeks
FreeIPA web UI login's failing
by Marc Pearson | i-Neda Ltd
Hello, looking for some help.
We've recently noted that the majority of our web UI's have started to fail to login. I have at least 1 that's still allowing log-in's at present.
When attempting to login, we get a 401 unauthorised in the networking tab for the login POST request, and a banner appears: "Your session has expired. Please log in again."
In the kerbos logs I see the following:
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1861](info): AS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.13.3.111: NEEDED_PREAUTH: WELLKNOWN/ANONYMOUS(a)INT.I-NEDA.COM<mailto:WELLKNOWN/ANONYMOUS@INT.I-NEDA.COM> for krbtgt/INT.I-NEDA.COM(a)INT.I-NEDA.COM<mailto:krbtgt/INT.I-NEDA.COM@INT.I-NEDA.COM>, Additional pre-authentication required
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1861](info): closing down fd 12
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): AS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.13.3.111: ISSUE: authtime 1707232119, etypes {rep=aes256-cts-hmac-sha384-192(20), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, WELLKNOWN/ANONYMOUS(a)INT.I-NEDA.COM<mailto:WELLKNOWN/ANONYMOUS@INT.I-NEDA.COM> for krbtgt/INT.I-NEDA.COM(a)INT.I-NEDA.COM<mailto:krbtgt/INT.I-NEDA.COM@INT.I-NEDA.COM>
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): closing down fd 12
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): AS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.13.3.111: NEEDED_PREAUTH: marc.admin(a)INT.I-NEDA.COM<mailto:marc.admin@INT.I-NEDA.COM> for krbtgt/INT.I-NEDA.COM(a)INT.I-NEDA.COM<mailto:krbtgt/INT.I-NEDA.COM@INT.I-NEDA.COM>, Additional pre-authentication required
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): closing down fd 12
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): AS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.13.3.111: ISSUE: authtime 1707232119, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, marc.admin(a)INT.I-NEDA.COM<mailto:marc.admin@INT.I-NEDA.COM> for krbtgt/INT.I-NEDA.COM(a)INT.I-NEDA.COM<mailto:krbtgt/INT.I-NEDA.COM@INT.I-NEDA.COM>
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): closing down fd 12
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1861](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.13.3.111: ISSUE: authtime 1707232119, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, marc.admin(a)INT.I-NEDA.COM<mailto:marc.admin@INT.I-NEDA.COM> for HTTP/red-ipa01.int.i-neda.com(a)INT.I-NEDA.COM<mailto:HTTP/red-ipa01.int.i-neda.com@INT.I-NEDA.COM>
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1861](info): closing down fd 12
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.13.3.111: S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1707232119, etypes {rep=UNSUPPORTED:(0)} HTTP/red-ipa01.int.i-neda.com(a)INT.I-NEDA.COM<mailto:HTTP/red-ipa01.int.i-neda.com@INT.I-NEDA.COM> for ldap/red-ipa01.int.i-neda.com(a)INT.I-NEDA.COM<mailto:ldap/red-ipa01.int.i-neda.com@INT.I-NEDA.COM>, KDC policy rejects request
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): ... CONSTRAINED-DELEGATION s4u-client=<unknown>
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): closing down fd 12
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.13.3.111: S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1707232119, etypes {rep=UNSUPPORTED:(0)} HTTP/red-ipa01.int.i-neda.com(a)INT.I-NEDA.COM<mailto:HTTP/red-ipa01.int.i-neda.com@INT.I-NEDA.COM> for ldap/red-ipa01.int.i-neda.com(a)INT.I-NEDA.COM<mailto:ldap/red-ipa01.int.i-neda.com@INT.I-NEDA.COM>, KDC policy rejects request
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): ... CONSTRAINED-DELEGATION s4u-client=<unknown>
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): closing down fd 12
We are not having issue with other parts of the authing system as we are still able to ssh into servers, use sudo over shared auth etc. And we can verify the issue isn't config on the cluster side. These hosts are update regularly in a round robin. One host that is allowing web-ui access was updated and restarted last night, so don't believe it's a package / code level issue either.
Any help or pointers would be greatly appreciated.
Regards,
Marc.
3 months, 3 weeks
