Weub UI fails with "Login failed due to an unknown reason."
by anilkumar panditi
Hi,
We have freeipa running as docker container and recently,
Weub UI fails with "Login failed due to an unknown reason."
I went through the following ,
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
And checked below,
when I run openssl x509 -text -in /var/kerberos/krb5kdc/kdc.crt
sh-4.2# openssl x509 -text -in /var/kerberos/krb5kdc/kdc.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 10 (0xa)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=XX.COM, CN=Certificate Authority
Validity
Not Before: Mar 28 15:30:41 2020 GMT
Not After : Mar 29 15:30:41 2022 GMT
Subject: O=XXX.COM, CN=freeipa.XX.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c6:15:96:06:ec:5e:10:8d:92:a4:c4:29:11:58:
eb:47:94:46:b3:e0:92:0b:e1:60:50:ce:50:1b:6a:
25:28:88:de:5b:41:c7:3c:92:cf:02:c3:0c:a5:14:
37:68:04:c0:c6:e1:1a:c4:ac:6f:8c:04:55:d5:42:
3d:3c:78:29:88:3f:a4:81:52:35:88:3f:7e:fc:80:
8a:ea:14:2a:f2:a8:49:ab:d6:32:5b:ea:35:d4:3b:
4d:14:4f:2c:5a:97:e3:a5:83:be:a6:9e:61:21:0a:
e0:2a:37:f8:41:9a:a2:8c:fb:54:a2:b2:9a:9d:32:
ff:8a:bb:0d:a4:05:b9:31:db:cd:9e:75:05:b3:bf:
7f:f4:d7:84:8e:2e:16:92:db:51:97:01:1e:19:58:
93:1b:9b:1c:56:a1:18:10:62:3f:8e:43:84:4f:c5:
90:3b:e9:de:2e:71:4e:32:33:52:22:1f:51:a8:7b:
fa:46:88:8f:ea:d5:c7:0a:ab:9a:36:ca:ff:e4:d2:
fb:04:4a:39:81:06:b1:59:fc:9b:59:d9:2d:91:9d:
bc:65:c9:e0:55:37:88:ba:4d:f8:4d:68:7a:4c:70:
69:4b:3e:74:aa:d4:c2:65:20:bf:d5:37:5e:73:c6:
b3:a8:4b:ca:37:8c:09:ee:cd:23:26:ed:d8:65:e0:
3b:bf
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:E2:12:D1:0E:77:B1:9B:A6:5F:96:06:9E:C1:4F:9D:C1:6A:1C:5C:0C
Authority Information Access:
OCSP - URI:http://ipa-ca.XX.com/ca/ocsp
X509v3 Key Usage: critical
Digital Signature, Non Repudiation, Key Encipherment, Data
Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, 1.3.6.1.5.2.3.5
X509v3 CRL Distribution Points:
Full Name:
URI:http://ipa-ca.XX.com/ipa/crl/MasterCRL.bin
CRL Issuer:
DirName: O = ipaca, CN = Certificate Authority
X509v3 Subject Key Identifier:
6B:84:45:F0:3F:20:AA:C9:6A:FE:08:33:A7:4F:4D:F5:07:95:18:31
X509v3 Subject Alternative Name:
othername:<unsupported>, othername:<unsupported>
Signature Algorithm: sha256WithRSAEncryption
08:97:ce:4f:cf:25:c3:8b:3b:c5:70:b3:1e:57:2d:49:2a:70:
18:cf:7a:93:01:6a:26:0b:7b:7e:42:0d:8e:77:01:20:cd:41:
50:9d:03:0d:8b:ad:52:1c:e0:c0:56:3e:2a:de:3c:b4:c5:49:
63:11:8e:10:04:1a:d9:9a:3d:59:2c:7f:f2:7f:88:37:82:15:
aa:b7:c0:cc:83:a0:98:22:6f:e8:f9:8e:95:5f:d8:0f:65:ba:
96:cb:cc:22:ab:fe:e2:54:b5:f3:35:f8:39:4e:3e:7d:55:77:
4a:79:9e:0e:c0:1c:26:b1:b4:05:a1:92:0c:9c:4c:b8:46:73:
a4:b2:07:ff:6c:20:c7:e8:cb:44:66:78:e3:68:a5:74:0d:33:
d3:93:5c:dc:df:46:c9:d7:18:09:a9:8b:d2:02:b2:34:f6:ac:
2f:10:19:d1:c8:35:d8:4e:94:5a:5f:ac:b3:27:3c:ba:3f:06:
9c:64:6a:24:72:75:c1:8e:f4:6a:4a:1f:a6:31:93:74:36:78:
99:89:d0:34:5f:2b:f2:ab:90:5f:ce:46:8e:cf:6a:19:66:31:
df:57:2f:d5:98:b1:f7:69:a7:a3:f2:9f:80:77:56:d1:ff:22:
ef:80:25:d0:fd:5f:6a:a6:74:df:4c:3a:99:62:b6:40:64:d5:
0e:d4:c9:c0
-----BEGIN CERTIFICATE-----
MIIE3jCCA8agAwIBAgIBCjANBgkqhkiG9w0BAQsFADA/MR0wGwYDVQQKDBRESUNF
REFUQVBMQVRGT1JNLkNPTTEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MB4XDTIwMDMyODE1MzA0MVoXDTIyMDMyOTE1MzA0MVowRjEdMBsGA1UECgwURElD
RURBVEFQTEFURk9STS5DT00xJTAjBgNVBAMMHGZyZWVpcGEuZGljZWRhdGFwbGF0
Zm9ybS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGFZYG7F4Q
jZKkxCkRWOtHlEaz4JIL4WBQzlAbaiUoiN5bQcc8ks8CwwylFDdoBMDG4RrErG+M
BFXVQj08eCmIP6SBUjWIP378gIrqFCryqEmr1jJb6jXUO00UTyxal+Olg76mnmEh
CuAqN/hBmqKM+1SispqdMv+Kuw2kBbkx282edQWzv3/014SOLhaS21GXAR4ZWJMb
mxxWoRgQYj+OQ4RPxZA76d4ucU4yM1IiH1Goe/pGiI/q1ccKq5o2yv/k0vsESjmB
BrFZ/JtZ2S2RnbxlyeBVN4i6TfhNaHpMcGlLPnSq1MJlIL/VN15zxrOoS8o3jAnu
zSMm7dhl4Du/AgMBAAGjggHcMIIB2DAfBgNVHSMEGDAWgBTiEtEOd7Gbpl+WBp7B
T53BahxcDDBGBggrBgEFBQcBAQQ6MDgwNgYIKwYBBQUHMAGGKmh0dHA6Ly9pcGEt
Y2EuZGljZWRhdGFwbGF0Zm9ybS5jb20vY2Evb2NzcDAOBgNVHQ8BAf8EBAMCBPAw
HAYDVR0lBBUwEwYIKwYBBQUHAwEGBysGAQUCAwUwfwYDVR0fBHgwdjB0oDygOoY4
aHR0cDovL2lwYS1jYS5kaWNlZGF0YXBsYXRmb3JtLmNvbS9pcGEvY3JsL01hc3Rl
ckNSTC5iaW6iNKQyMDAxDjAMBgNVBAoMBWlwYWNhMR4wHAYDVQQDDBVDZXJ0aWZp
Y2F0ZSBBdXRob3JpdHkwHQYDVR0OBBYEFGuERfA/IKrJav4IM6dPTfUHlRgxMIGe
BgNVHREEgZYwgZOgQAYKKwYBBAGCNxQCA6AyDDBrcmJ0Z3QvRElDRURBVEFQTEFU
Rk9STS5DT01ARElDRURBVEFQTEFURk9STS5DT02gTwYGKwYBBQICoEUwQ6AWGxRE
SUNFREFUQVBMQVRGT1JNLkNPTaEpMCegAwIBAaEgMB4bBmtyYnRndBsURElDRURB
VEFQTEFURk9STS5DT00wDQYJKoZIhvcNAQELBQADggEBAAiXzk/PJcOLO8Vwsx5X
LUkqcBjPepMBaiYLe35CDY53ASDNQVCdAw2LrVIc4MBWPirePLTFSWMRjhAEGtma
PVksf/J/iDeCFaq3wMyDoJgib+j5jpVf2A9lupbLzCKr/uJUtfM1+DlOPn1Vd0p5
ng7AHCaxtAWhkgycTLhGc6SyB/9sIMfoy0RmeONopXQNM9OTXNzfRsnXGAmpi9IC
sjT2rC8QGdHINdhOlFpfrLMnPLo/BpxkaiRydcGO9GpKH6Yxk3Q2eJmJ0DRfK/Kr
kF/ORo7PahlmMd9XL9WYsfdpp6Pyn4B3VtH/Iu+AJdD9X2qmdN9MOplitkBk1Q7U
ycA=
-----END CERTIFICATE-----
And,
sh-4.2# ls -l /var/lib/ipa-client/pki/kdc-ca-bundle.pem
-rw-r--r--. 1 root root 1326 Mar 28 2020
/var/lib/ipa-client/pki/kdc-ca-bundle.pem
Could you please help?
2 years, 9 months
ipa-adtrust-install fails with invalid 'cn': must be Unicode text
by iulian roman
Hello,
When I run ipa-adtrust-install command in order to configure trust prerequisites , it fails in step 4, with the following error:
Configuring CIFS
[1/24]: validate server hostname
[2/24]: stopping smbd
[3/24]: creating samba domain object
Samba domain object already exists
[4/24]: retrieve local idmap range
[error] ConversionError: invalid 'cn': must be Unicode text
Unexpected error - see /var/log/ipaserver-install.log for details:
ConversionError: invalid 'cn': must be Unicode text
The existing idrange is in the following format :
dn: cn=IPA.EXAMPLE.COM_id_range,cn=ranges,cn=etc,dc=ipa,dc=example,dc=com
Any hint/suggestion would be really appreciated .
2 years, 9 months
Problems after upgrade
by Ronald Wimmer
Some time ago we upgraded our IPA servers from CentOS 7.x to Oracle
Linux 8.3. We did it exactly as recommended in the respective documentation.
A few days ago we found out that two out of our eight servers do not
work as they should. On both of them pki-tomcatd refuses to start. The
two servers are ipa2 and ipa6 - both have the CA feature installed.
Additionally, on ipa6 configuration is not replicated to the other
servers. ipa2 seems to have even more problems. kinit does not work,
neither does the WebGUI.
My first question is addressed to Rob. Is ipa-healthcheck checking the
whole IPA server landscape or does it check only the server where the
command is issued?
What would probably be the best way to make these two servers work
normal again? (I am thinking of just ripping these two servers out of
the topology and setting them up from scratch again?)
Cheers,
Ronald
2 years, 9 months
FreeIPA server host keytab was deleted
by Grant Janssen
an inexperienced administrator overwrote the /etc/krb5.keytab on my IDM server. (ugh!)
I had thought ipa-getkeytab was retrieving the keytab, but now see I regenerated it and SHOULD have used the -r flag.
ipa-getkeytab(1) IPA Manual Pages ipa-getkeytab(1)
NAME
ipa-getkeytab - Get a keytab for a Kerberos principal
SYNOPSIS
ipa-getkeytab -p principal-name -k keytab-file [ -e encryption-types ] [ -s ipaserver ] [ -q ] [ -D|--binddn BINDDN ] [ -w|--bindpw ] [ -P|--password PASSWORD ] [ --cacert CACERT ] [
-H|--ldapuri URI ] [ -Y|--mech GSSAPI|EXTERNAL ] [ -r ]
DESCRIPTION
Retrieves a Kerberos keytab.
-snip-
WARNING: retrieving the keytab resets the secret for the Kerberos principal. This renders all other keytabs for that principal invalid.
-snip-
grant@ef-idm01:/etc[20210302-15:39][#1009]$ ipa-getkeytab -s ef-idm01.production.efilm.com<http://ef-idm01.production.efilm.com> -p host/ef-idm01.production.efilm.com<http://ef-idm01.production.efilm.com> -k ~/ef-idm01.krb5.keytab
Keytab successfully retrieved and stored in: /home/grant/ef-idm01.krb5.keytab
grant@ef-idm01:/etc[20210302-15:40][#1010]$ sudo rsync -av ~/ef-idm01.krb5.keytab /etc/krb5.keytab
sending incremental file list
ef-idm01.krb5.keytab
sent 521 bytes received 31 bytes 1104.00 bytes/sec
total size is 418 speedup is 0.76
grant@ef-idm01:/etc[20210302-15:40][#1011]$ ls -al /etc/krb5.keytab
-rw------- 1 grant grant 418 Mar 2 15:40 /etc/krb5.keytab
grant@ef-idm01:/etc[20210302-15:40][#1012]$ sudo chown root.root /etc/krb5.keytab
grant@ef-idm01:/etc[20210302-15:41][#1013]$
What are the possible repercussions of regenerating this keytab?
I don’t see any issues. Am I missing anything?
thanx
- grant
2 years, 9 months
SSSD restart is required for AD users to work
by Anestis Karampatziakis
Hi,
Recently we established a one-way trust between our FreeIPA server and a client’s AD domain.
Users and groups have been created and mapped; we are now testing user access, hbac and sudo rules.
An issue we came across is that on all clients we need to restart SSSD for the correct usergroups and group membership to appear on id and getent command.
Check test_user user and group membership:
[root@server1 root]# id test_user(a)ad.domain.com
uid=370001170(test_user(a)ad.domain.com) gid=370001170(test_user(a)ad.domain.com<mailto:test_user@ad.domain.com>)
groups=370001170(test_user(a)ad.domain.com)
[root@server1 root]# service sssd restart
Redirecting to /bin/systemctl restart sssd.service
Recheck user, new groups appear.
[root@server1 root]# id test_user(a)ad.domain.com
uid=370001170(test_user(a)ad.domain.com) gid=370001170(test_user(a)ad.domain.com<mailto:test_user@ad.domain.com>)
groups=370001170(test_user@ad.domain.com),370001628(ad_group(a)ad.domain.com),1262600020(posix_group),370000513(domain users(a)ad.domain.com)
370001628(ad_group(a)ad.domain.com<mailto:ad_group@ad.domain.com>) and 1262600020(posix_group) are the FreeIPA posix group and the mapped AD group.
Another thing is that although sssd restart appears to resolve the issue, when checking the next usergroup we need to do the same exercise.
Check test_user2 user and group membership:
root@server1 root# id test_user2@ad_domain
uid=370001175(test_user2@ad_domain) gid=370001175(test_user2@ad_domain)
groups=370001175(test_user2@ad_domain),370000513(domain users@ad_domain)
root@server1 root# getent group posix_group2
[empty response]
Responses are not correct. Restart SSSD.
root@server1 root# service sssd restart
Check again:
root@server1 root# id test_user2@ad_domain
uid=370001175(test_user2@ad_domain) gid=370001175(test_user2@ad_domain)
groups=370001175(test_user2@ad_domain),370000513(domain users@ad_domain),370001634(ad_group2@ad_domain),1262600032(posix_group2)
root@server1 root# getent group posix_group2
ad_pis_users:*:1262600032:test_user2@ad_domain
Response is correct and users can login according to hbac and sudo rules.
Our FreeIPA server version is: 4.6.6-11.el7.centos
Is there something we have missing in our configuration?
Thanks,
Anestis
2 years, 9 months
FreeIPA Multi-master dse.ldif updates
by Yuri Krysko
Hello,
We run two IPA servers in a multi-master replication topology. Could anyone please advise if it is normal to have dse.ldif files on both IPA servers be updated every minute roughly with nsState attribute being modified by cn=Multimaster Replication Plugin,cn=plugins,cn=config ?
Thanks much!
2 years, 9 months
ipa-replica-install failure.
by Arjen Heidinga
Hi!
My primary IPA-server is severely damaged. It is an old server, updated
and updated and updated through time (anaconda-ks.cfg is 4 Dec 2014). I
run Fedora-33 (now).
Because the installation is broken on several parts (missing certs, odd
tomcat issues), I thought, lets replicate and reinstall and start over
fresh-ish. New machine, ipa-replica install goes smooth for about an
hour (or so) and burns down:
The ipa-replica-install command failed, exception: CalledProcessError:
CalledProcessError(Command ['/bin/systemctl', 'start',
'pki-tomcatd(a)pki-tomcat.service'] returned non-zero exit status 1: 'Job
for pki-tomcatd(a)pki-tomcat.service failed because a timeout was
exceeded.\nSee "systemctl status pki-tomcatd(a)pki-tomcat.service" and
"journalctl -xe" for details.\n')
CalledProcessError(Command ['/bin/systemctl', 'start',
'pki-tomcatd(a)pki-tomcat.service'] returned non-zero exit status 1: 'Job
for pki-tomcatd(a)pki-tomcat.service failed because a timeout was
exceeded.\nSee "systemctl status pki-tomcatd(a)pki-tomcat.service" and
"journalctl -xe" for details.\n')
The ipa-replica-install command failed. See
/var/log/ipareplica-install.log for more information
(install log attached).
Inspecting the tomcat-ca log i see:
2021-02-25 13:07:18 [main] INFO: PluginRegistry: Loading plugin registry
from /var/lib/pki/pki-tomcat/conf/ca/registry.cfg
2021-02-25 13:07:18 [main] SEVERE: LdapBoundConnFactory: Unable to
connect to LDAP server: Authentication failed
netscape.ldap.LDAPException: Authentication failed (49)
Yes, this is one of the issues I had with the main server. Somehow not
trusting the tomcat client-cert anymore. Ended up with doing password
auth without ssl.
Is there a way to repair this, or trick the server into doing this. Or
should I do a fresh start?
Kind regards,
Arjen Heidinga
2 years, 9 months