Speeding up installation?
by Dominik Vogt
Installing the ipa-server on our VMs takes about 13 to 14 minutes.
We have to do this often during development. Stupid question: Is
there a way to speed this up substantially? More memory, more
CPUs or whatever?
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
3 years, 1 month
/var/log/krb5kdc.log server not found, how to do a kinit or krb5.conf that freeipa likes better
by Jelle de Jong
Hello everybody,
Can someone help how to do a kinit or change my krb5.conf so freeipa
does not create "Server not found in Kerberos database" warnings
flooding the logs?
After freeipa crashed because root / was 100% filled due to
/var/log/krb5kdc.* total size being more then 30GB I found that the log
is full with:
[root@freeipa01 ~]# tail -n 2 /var/log/krb5kdc.log
Mar 06 20:54:42 freeipa01.powercraft.lan krb5kdc[122009](info): TGS_REQ
(6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20),
camellia256-cts-cmac(26), aes128-cts-hmac-sha1-96(17),
aes128-cts-hmac-sha256-128(19), camellia128-cts-cmac(25)})
192.168.25.22: UNKNOWN_SERVER: authtime 0, etypes {rep=UNSUPPORTED:(0)}
nextcloud(a)POWERCRAFT.LAN for krbtgt/(null)(a)POWERCRAFT.LAN, Server not
found in Kerberos database
[root@nextcloud01 ~]# sudo -u apache kinit -r 14d -l 7d
nextcloud(a)POWERCRAFT.LAN
I create a kerberos ticket with the above command to create a ticket for
apache with nextcloud to use to access samba (libsmbclient) with
kerberos as user nextcloud (samba01 and nextcloud01 are both ipa clients)
[root@nextcloud01 ~]# sudo -u apache klist
Ticket cache: KEYRING:persistent:48:48
Default principal: nextcloud(a)POWERCRAFT.LAN
Valid starting Expires Service principal
03/06/21 19:04:04 03/07/21 19:03:14
cifs/samba01.powercraft.lan(a)POWERCRAFT.LAN
renew until 03/13/21 19:03:14
03/06/21 19:03:14 03/07/21 19:03:14 krbtgt/POWERCRAFT.LAN(a)POWERCRAFT.LAN
renew until 03/13/21 19:03:14
[root@nextcloud01 ~]# cat /etc/krb5.conf
#File modified by ipa-client-install
includedir /etc/krb5.conf.d/
includedir /var/lib/sss/pubconf/krb5.include.d/
[libdefaults]
default_realm = POWERCRAFT.LAN
dns_lookup_realm = true
dns_lookup_kdc = true
rdns = false
dns_canonicalize_hostname = false
# ticket_lifetime = 24h
forwardable = true
udp_preference_limit = 0
default_ccache_name = KEYRING:persistent:%{uid}
# krb5_ccname_template = FILE:%d/krb5cc_%U
[realms]
POWERCRAFT.LAN = {
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]
.powercraft.lan = POWERCRAFT.LAN
powercraft.lan = POWERCRAFT.LAN
nextcloud01.powercraft.lan = POWERCRAFT.LAN
[
Thank you in advance,
Kind regards,
Jelle de Jong
3 years, 1 month
Jira LDAP integration with JIRA
by Kaspars Tuna
I am working on integrating a Jira instance with a freeIPA instance trough LDAP to retrieve all the users being stored in the freeIPA user directory. I can manage to retrieve all the user, but I cannot seem to be able to retrieve the user groups/memberships, the "Test get user's memberships : Failed" seems to fail all the time with no particular info in the jira-software/logs/atlassian-jira.log file. No luck finding any other resources online, has anybody encountered such issues if so what did you do?
The schema I am using is bellow :
Directory type : LDAP, OpenLDAP (have also attempted to use LDAP with internal authentication, which doesn't give me any groups either)
base DN:cn=users,cn=accounts,dc=example,dc=io
Read Only, with Local groups checked and adding to jira-software -users by default.
Use schema - all user info is being retrieved, so no issue
Group Schema
Group Object Class : groupOfNames
Group Object Filter:(objectclass=groupOfNames)
Group Name attribute: cn
Group Description attribute : description
Membership schema
Group Memebers attribute : Member
User Membership attribute: memberOf
freeIPA user has fields memberOf: cn=group-example, cn=groups, cn=accounts, dc=example, dc=com
and groups has member:cn=usere, cn=accounts, cn=users, dc=example, dc=com
3 years, 1 month
Missing mandatory attribute ipaNTSecurityIdentifier.
by Lachlan Simpson
Last week I was having SSSD issues and Sumit was sharp enough to pick out that I didn't allow enough RIDs.
( https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste... )
I increase the range by 5,000,000 via the GUI, restarted all two SSSD services (test ipa server, test client) after clearing their caches and it started to work.
For reasons, the IPA test server was power cycled and when it came back up, IPA wont start. `ipactl start` aborts because "Failed to start smb Service"
I am seeing the following in the samba logs:
[2021/02/23 14:57:23.259648, 0] ../../source3/smbd/server.c:1782(main)
smbd version 4.12.3 started.
Copyright Andrew Tridgell and the Samba Team 1992-2020
[2021/02/23 14:57:23.312207, 1] ../../source3/profile/profile.c:55(set_profile_level)
INFO: Profiling turned OFF from pid 2360
[2021/02/23 14:57:23.345139, 0] ipa_sam.c:3980(get_fallback_group_sid)
Missing mandatory attribute ipaNTSecurityIdentifier.
[2021/02/23 14:57:23.345184, 0] ipa_sam.c:4950(pdb_init_ipasam)
Cannot find SID of fallback group.
[2021/02/23 14:57:23.345194, 0] ../../source3/passdb/pdb_interface.c:180(make_pdb_method_name)
pdb backend ipasam:ldapi://%2fvar%2frun%2fslapd-TEST-IDM-COMPANY-COM.socket did not correctly init (error was NT_STATUS_INVALID_PARAMETER)
[2021/02/23 15:05:11.201577, 0] ../../source3/smbd/server.c:1782(main)
smbd version 4.12.3 started.
Copyright Andrew Tridgell and the Samba Team 1992-2020
[2021/02/23 15:05:11.212856, 1] ../../source3/profile/profile.c:55(set_profile_level)
INFO: Profiling turned OFF from pid 3146
[2021/02/23 15:05:11.234448, 0] ipa_sam.c:3980(get_fallback_group_sid)
Missing mandatory attribute ipaNTSecurityIdentifier.
A quick search suggests that potentially my change of the RID has affected SMB but I'm not 100% sure what to do next.
I guess I need to add an ipaNTSecurityIdentifier variable - but I'm not sure where.
This page https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/trust-i... suggests that I need to add a sidgen to the FreeIPA users that exist, but those users were created via the GUI - shouldn't the SID have been created then?
And if they didn't, how come I've been able to reboot successfully relatively frequently without this issue happening before - is it because I changed the value of that one domain's ID range?
Cheers
L.
3 years, 1 month
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?
3 years, 1 month
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 .
3 years, 1 month
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
3 years, 1 month
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
3 years, 1 month
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
3 years, 1 month
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!
3 years, 1 month
