回复: Login failed after upgrade
by 胡 玮文
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
2 years, 9 months
Login failed after upgrade
by 胡 玮文
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
2 years, 9 months
401 error when joining an IPA realm (from an Active Directory domain/realm)
by Adrien Dessemond
Hi,
I do have an issue with my latest Linux (CentOS 7) virtual machines (names
have been redacted):
1. They start their life in an AD domain (Windows 2019 DCs) and everything
is working as expected (for the rest of the explanation, I will use
"AD.DOMAIN" for this realm)
2. I have an IPA Server, which, despite having a FQDN ending in "ad.domain"
is enrolled in its own Kerberos domain (IPA.DOMAIN) => idmsrv01.ad.domain
2.On my client machine I do => realm leave
3. Then I try to make it rejoin my IPA domain/realm =>
# export KRB5_TRACE=/dev/stdout
# ipa-client-install --server idmsrv01.ad.domain --domain idm.domain
--realm IPA.DOMAIN --principal enrollmentaccount --mkhomedir --no-ntp
--force-join
And here is the issue :
(...)
Using existing certificate '/etc/ipa/ca.crt'.
Client hostname: myvm01.ad.domain
Realm: IPA.DOMAIN
DNS Domain: ipa.domain
IPA Server: idmsrv01.ad.domain
BaseDN: dc=ipa,dc=domain
Skipping synchronizing time with NTP server.
[19420] 1626829415.775243: ccselect can't find appropriate cache for server
principal ldap/idmsrv01.ad.domain(a)AD.DOMAIN
[19420] 1626829415.775244: Getting credentials enrollmentaccount(a)IPA.DOMAIN
-> ldap/idmsrv01.ad.domain(a)AD.DOMAIN using ccache
FILE:/tmp/krbccoz6hPK/ccache
[19420] 1626829415.775245: Retrieving enrollmentaccount(a)IPA.DOMAIN ->
ldap/idmsrv01.ad.domain(a)AD.DOMAIN from FILE:/tmp/krbccoz6hPK/ccache with
result: -1765328243/Matching credential not found (filename:
/tmp/krbccoz6hPK/ccache)
[19420] 1626829415.775246: Retrieving enrollmentaccount(a)IPA.DOMAIN ->
krbtgt/AD.DOMAIN(a)AD.DOMAIN from FILE:/tmp/krbccoz6hPK/ccache with result:
-1765328243/Matching credential not found (filename:
/tmp/krbccoz6hPK/ccache)
[19420] 1626829415.775247: Retrieving enrollmentaccount(a)IPA.DOMAIN ->
krbtgt/IPA.DOMAIN(a)IPA.DOMAIN from FILE:/tmp/krbccoz6hPK/ccache with result:
0/Success
[19420] 1626829415.775248: Starting with TGT for client realm:
enrollmentaccount(a)IPA.DOMAIN -> krbtgt/IPA.DOMAIN(a)IPA.DOMAIN
[19420] 1626829415.775249: Retrieving enrollmentaccount(a)IPA.DOMAIN ->
krbtgt/AD.DOMAIN(a)AD.DOMAIN from FILE:/tmp/krbccoz6hPK/ccache with result:
-1765328243/Matching credential not found (filename:
/tmp/krbccoz6hPK/ccache)
[19420] 1626829415.775250: Requesting TGT krbtgt/AD.DOMAIN(a)IPA.DOMAIN using
TGT krbtgt/IPA.DOMAIN(a)IPA.DOMAIN
[19420] 1626829415.775251: Generated subkey for TGS request: aes256-cts/3835
[19420] 1626829415.775252: etypes requested in TGS request: aes256-cts,
aes128-cts, aes256-sha2, aes128-sha2, des3-cbc-sha1, rc4-hmac,
camellia128-cts, camellia256-cts
[19420] 1626829415.775254: Encoding request body and padata into FAST
request
[19420] 1626829415.775255: Sending request (1565 bytes) to IPA.DOMAIN
[19420] 1626829415.775256: Resolving hostname idmsrv01.ad.domain
[19420] 1626829415.775257: Initiating TCP connection to stream
10.xxx.xxx.xxx:88
[19420] 1626829415.775258: Sending TCP request to stream 10.xxx.xxx.xxx:88
[19420] 1626829415.775259: Received answer (482 bytes) from stream
10.xxx.xxx.xxx:88
[19420] 1626829415.775260: Terminating TCP connection to stream
10.xxx.xxx.xxx:88
[19420] 1626829415.775261: Response was from master KDC
[19420] 1626829415.775262: Decoding FAST response
[19420] 1626829415.775263: TGS request result: -1765328377/Server
krbtgt/AD.DOMAIN(a)IPA.DOMAIN not found in Kerberos database
Unable to download CA cert from LDAP but found preexisting cert, using it.
Joining realm failed: HTTP response code is 401, not 200
Installation failed. Rolling back changes.
(...)
So basically my interpretation is : the IPA client is trying to initiate a
Kerberos authentication which fails and being unable to do that it is
unable to get a valid credential for the IPA server which in turn results
in a 401 error when doing an XML RPC call on it. The account used for
enrollment is not locked, not expired and is having the correct roles
especially the enrollment capability.
Understanding "TGS request result: -1765328377/Server
krbtgt/AD.DOMAIN(a)IPA.DOMAIN" seems the key to my issue but I have no clue
on what to do at this point.
- My IPA server has no direct trust to AD.DOMAIN.
- Client and server are both using IPA 4.6.8
- Server certificates seem correct and not expired.
Any idea on what is going on / what to look at next?
Best regards,
2 years, 9 months
Compatibility Plugin .update file for Active Directory
by Joseph Fry
My goal is to use the compatibility plugin to display IPA hosts in a format that an Active Directory centric tool can consume. Essentially my solution creates two containers under cn=compat called cn=adComputers and cn=adComputerGroups. An entry is added to adComputers for every ipaHost, and attributes populated that match active directory ldap attributes for a 'computer' object. We do the same for each IPA hostgroup.
I have come pretty close to getting this working, but now I need to get the groups populated with the group members, but not the IPA hosts... instead I need the members to be the corresponding cn=adComputers entries that were created.
So I need to manipulate the members attribute. For example the member attribute of one of the hostgroups in ipa is:
fqdn=test.lab.local,cn=computers,cn=accounts,dc=lab,dc=local
I need to change it to:
cn=test.lab.local,cn=adcomputers,cn=compat,dc=lab,dc=local
Below is my .update file. I want to add a line at the end like:
add:schema-compat-entry-attribute: member=%{member}
But want to rewrite the %{member} value as described above. I know I can do some logic here, as evidenced by https://pagure.io/freeipa/blob/master/f/install/updates/80-schema_compat.... where they use %ifeq and %%%deref_f. But I cannot find any documentation explaining what options are available. Essentially I am hoping there is some sort of regex manipulation capability here?
My .update file so far:
dn: cn=adComputers, cn=Schema Compatibility, cn=plugins, cn=config
add:objectClass: top
add:objectClass: extensibleObject
add:cn: adComputers
add:schema-compat-container-group: cn=compat, $SUFFIX
add:schema-compat-container-rdn: cn=adComputers
add:schema-compat-search-base: cn=computers, cn=accounts, $SUFFIX
add:schema-compat-search-filter: (&(fqdn=*)(objectClass=ipaHost))
add:schema-compat-entry-rdn: cn=%first("%{fqdn}")
add:schema-compat-check-access: yes
add:schema-compat-entry-attribute: objectclass=computer
add:schema-compat-entry-attribute: cn=%{fqdn}
add:schema-compat-entry-attribute: sAMAccountType=805306369
add:schema-compat-entry-attribute: dNSHostName=%{fqdn}
add:schema-compat-entry-attribute: operatingSystem=%{nsHardwarePlatform}
add:schema-compat-entry-attribute: operatingSystemVersion=%{nsOsVersion}
add:schema-compat-entry-attribute: name=%{serverHostName}
add:schema-compat-entry-attribute: sAMAccountName=$$%{serverHostName}
add:schema-compat-entry-attribute: location=%{nsHostLocation}
dn: cn=adComputerGroups, cn=Schema Compatibility, cn=plugins, cn=config
add:objectClass: top
add:objectClass: extensibleObject
add:cn: adComputerGroups
add:schema-compat-container-group: cn=compat, $SUFFIX
add:schema-compat-container-rdn: cn=adComputerGroups
add:schema-compat-search-base: cn=hostgroups, cn=accounts, $SUFFIX
add:schema-compat-search-filter: (&(member=*)(objectClass=ipahostgroup))
add:schema-compat-entry-rdn: cn=%{cn}
add:schema-compat-entry-check-access: yes
add:schema-compat-entry-attribute: objectclass=group
add:schema-compat-entry-attribute: cn=%{cn}
add:schema-compat-entry-attribute: groupType=-2147483646
add:schema-compat-entry-attribute: sAMAccountType=268435456
add:schema-compat-entry-attribute: name=%{cn}
add:schema-compat-entry-attribute: sAMAccountName=$$%{cn}
2 years, 9 months
Only some group names resolved
by iulian roman
Hello everybody,
In an Idm setup with replica and AD trust , I noticed that on few clients only some of the groups are resolved to names (on the IPA servers they are correctly resolved) . If I remove caches on IPA server, remove the cache in /var/lib/sss/db , I make it eventually work, although it seems quite random (and obviously not a solution in a production setup).
Does anyone have any idea what might be the cause of such behaviour ?
I have read almost anything I could find about troubleshooting sssd, and I have to admit that clearing caches and all that stuff is still trial and error and still something which probably either needs to be done better, either to be documented better . So far, from what I experienced in my setup, sssd and handling caches seems one of the biggest sources of trouble and a major roadblock in migrating to IPA.
2 years, 9 months
Freeipa as a CA
by Per Qvindesland
Hi
I would like to use Freeipa to sign SSL's for https use (if possible) but I am wondering where is the CA certs located so I can distribute it via a package rpm/deb?
Regards
Per
2 years, 9 months
Re: Limit the number of concurrent logins?
by Alexander Bokovoy
Hi,
please do not drop freeipa-users@ mailing list from CC:.
On ti, 20 heinä 2021, Galvanick Lucipher wrote:
>Alexander,
>
>thank you very much for your prompt answer. Just to make sure I understand,
>when you say "I don't think it is possible to achieve", you are referring
>to both active limiting of concurrent logins and detection of the number of
>simultaneous sessions?
Both. There is no such thing in MIT Kerberos that would have prevented
issuing multiple tickets for the same Kerberos principal within a time
interval. There is no way to reliably coordinate such rate limiting across
multiple KDCs.
A TGT issued for a Kerberos principal is valid during a certain period.
If you are in possession of the ticket, you can use it to request
service tickets to other Kerberized server applications. Those
applications may or may not maintain their own knowledge of who is being
logged into that specific application at a time. There is, however, no
generic facility to prevent multiple logins.
On Linux clients such as IPA-enrolled systems, there might be some PAM
modules that could check currently opened login sessions and prevent
opening a new one but this is client-specific and cannot be used for
deployment-wide prevention of simultaneous authenticated logons.
>
>Yours,
>GK
>
>On Tue, Jul 20, 2021 at 10:23 AM Alexander Bokovoy <abokovoy(a)redhat.com>
>wrote:
>
>> On ti, 20 heinä 2021, Galvanick Lucipher via FreeIPA-users wrote:
>> >Hi all,
>> >
>> >I would like to use FreeIPA to restrict the number of simultaneous logins
>> >to a given account, e.g. to prevent two active sessions simultaneously (or
>> >at least capture the number of concurrent logins, so I can e.g. send an
>> >alarm if Nlogins > 1). I've searched through the docs, but haven't found
>> >how to do it, neither at the FreeIPA level nor at the LDAP or Kerberos
>> >levels.
>> >
>> >Is it possible to limit the number of simultaneous logins to a FreeIPA
>> >account?
>>
>> I don't think it is possible to achieve. It is certainly not implemented
>> at the moment.
>>
>>
>> --
>> / Alexander Bokovoy
>> Sr. Principal Software Engineer
>> Security / Identity Management Engineering
>> Red Hat Limited, Finland
>>
>>
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
2 years, 9 months
Limit the number of concurrent logins?
by Galvanick Lucipher
Hi all,
I would like to use FreeIPA to restrict the number of simultaneous logins
to a given account, e.g. to prevent two active sessions simultaneously (or
at least capture the number of concurrent logins, so I can e.g. send an
alarm if Nlogins > 1). I've searched through the docs, but haven't found
how to do it, neither at the FreeIPA level nor at the LDAP or Kerberos
levels.
Is it possible to limit the number of simultaneous logins to a FreeIPA
account?
Thanks for your help,
GK
2 years, 9 months
FreeIPA server packages upgrade best practice
by Suchismita Panda
Hi,
I would like to know the best practice for patching FreeIPA-Server
packages. We generally have daily patching enabled in our servers. Will it
be a good idea to do automatic patching of FreeIPA-Server packages?
If we want to restrict the FreeIPA-Server packages from automatomatic
upgrade and rather keep it for manual upgrade, what are the packages we
should hold back with a version restriction? And how frequently should we
do the manual upgrade? If the FreeIPA-client packages are upgraded
regularly by daily patching(yum-cron or unattended upgrade) will there be
any problem with authentication, if the FreeIPA-Servers are behind version
upgrade?
We have two FreeIPA environments, one with CentOS7 and another with
CentOS8. And we have FreeIPA clients mostly with Ubuntu(18 and 20) and
CentOS (7 and 8).
Any help and guidance is appreciated.
Thanks
Suchi
2 years, 9 months
group name not resolved in IPA server for override
by iulian roman
Hello,
I have an issue with the group override on the IPA server. When I run the id command it does display all the group members , but for the primary GID which is overwritten it does not display the name, only the ID.
- groups userid
groups: cannot find name for group ID 20309 ( but it does correctly resolve the others )
- getent group <GID> does not display anything either
- if I manually run getent group <username> all the above commands will run and display all the information successfully
Any advice what might be wrong and how to enforce it to be resolved directly, without the getent group workaround ?
2 years, 9 months