Install Freeipa on top of openshift as a pod/container
by anilkumar panditi
Hi,
I am looking for installing freeipa on top of openshift as a pod/container,
I have tried the dockerhub image freeipa/freeipa-server:centos-7-4.6.8
where i got permission issues and POD went into error.
Is there any specific freeipa image/Dockerfile that runs smooth on
Openshift where the worker node OS is RHEL.
Thanks,
Anil
3 years
Re: ipa-healthcheck error
by Rob Crittenden
Dungan, Scott A. via FreeIPA-users wrote:
> Hi, Rob.
>
> Just to be clear: we get the same error on all three IPA servers in the domain when running health-check. All three are CA servers, and one is the renewal master. We should run ipa-server-upgrade on all three?
If the CA truly isn't being tracked, yes.
To be safe I'd run it on one server, confirm healthcheck no longer
reports it, then proceed to the others.
ipa-server-upgrade checks the status of the certs that should be tracked
and should correct any that are incorrect.
rob
>
> Thanks,
>
> Scott.
>
>
> -----Original Message-----
> From: Rob Crittenden <rcritten(a)redhat.com>
> Sent: Monday, April 5, 2021 12:51 PM
> To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
> Cc: Dungan, Scott A. <sdungan(a)caltech.edu>
> Subject: Re: [Freeipa-users] ipa-healthcheck error
>
> Dungan, Scott A. via FreeIPA-users wrote:
>> When running a ipa-healthcheck we are seeing one "ERROR" condition
>> under the ipahealthcheck.ipa.certs section:
>>
>>
>>
>> {
>>
>> "source": "ipahealthcheck.ipa.certs",
>>
>> "check": "IPACertTracking",
>>
>> "result": "ERROR",
>>
>> "uuid": "df8e46a4-427b-4b40-8db8-e09633d6d903",
>>
>> "when": "20210405174840Z",
>>
>> "duration": "1.014180",
>>
>> "kw": {
>>
>> "key": "cert-database=/etc/pki/pki-tomcat/alias,
>> cert-nickname=caSigningCert cert-pki-ca,
>> ca-name=dogtag-ipa-ca-renew-agent,
>> cert-presave-command=/usr/libexec/ipa/certmonger/stop_pkicad,
>> cert-postsave-command=/usr/libexec/ipa/certmonger/renew_ca_cert
>> \"caSigningCert cert-pki-ca\", template-profile=caCACert",
>>
>> "msg": "Missing tracking for
>> cert-database=/etc/pki/pki-tomcat/alias, cert-nickname=caSigningCert
>> cert-pki-ca, ca-name=dogtag-ipa-ca-renew-agent,
>> cert-presave-command=/usr/libexec/ipa/certmonger/stop_pkicad,
>> cert-postsave-command=/usr/libexec/ipa/certmonger/renew_ca_cert
>> \"caSigningCert cert-pki-ca\", template-profile=caCACert"
>>
>> }
>>
>> },
>>
>>
>>
>> I am not sure what to do about this or where to look for more
>> information. Any help pointing me in the right direction would be much
>> appreciated.
>
> This means that you have a CA configured on the server but the IPA CA signing cert isn't tracked by certmonger. Running ipa-server-upgrade should fix it.
>
> rob
> _______________________________________________
> 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
>
3 years
Re: [Freeipa-users]Απ: Re: Retrieve service keytab with host keytab authentication?
by Alexander Bokovoy
On ma, 05 huhti 2021, Peter Tselios via FreeIPA-users wrote:
>I cannot see the reply in the web, so, maybe I missed something.
I saw recently some issues with deduplication so haven't seen my
responses on several lists as well.
My response, however, did go to your personal email as CC: too.
>The fact that I need to authenticate in order to retrieve the keytab is obvious.
>Maybe in my OP I focused too much on the authentication method, but for
>me, the most important issue is the lack of API call (and yes, I plan
>to submit an RFE for this). The GSSAPI support is very interesting and
>I will investigate it further; it looks very promising.
Regarding an RFE, depending where you want to file it, I think we'll
reject it.
Adding a keytab retrieval to IPA API is not going to provide any
security on top of ipa-getkeytab use. In fact, it is actually will
reduce that because now one more party would have a key content beyond
LDAP server response to ipa-getkeytab request. This is certainly not
going to be accepted.
If you want to have ansible-freeipa support for ipa-getkeytab, that is a
different story. I think it should be added there, indeed. It would
require a full (free)ipa-client package installation, not just
python3-ipalib, though.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
3 years
Re: ipa-healthcheck error
by Rob Crittenden
Dungan, Scott A. via FreeIPA-users wrote:
> When running a ipa-healthcheck we are seeing one ERROR condition under
> the ipahealthcheck.ipa.certs section:
>
>
>
> {
>
> "source": "ipahealthcheck.ipa.certs",
>
> "check": "IPACertTracking",
>
> "result": "ERROR",
>
> "uuid": "df8e46a4-427b-4b40-8db8-e09633d6d903",
>
> "when": "20210405174840Z",
>
> "duration": "1.014180",
>
> "kw": {
>
> "key": "cert-database=/etc/pki/pki-tomcat/alias,
> cert-nickname=caSigningCert cert-pki-ca,
> ca-name=dogtag-ipa-ca-renew-agent,
> cert-presave-command=/usr/libexec/ipa/certmonger/stop_pkicad,
> cert-postsave-command=/usr/libexec/ipa/certmonger/renew_ca_cert
> \"caSigningCert cert-pki-ca\", template-profile=caCACert",
>
> "msg": "Missing tracking for
> cert-database=/etc/pki/pki-tomcat/alias, cert-nickname=caSigningCert
> cert-pki-ca, ca-name=dogtag-ipa-ca-renew-agent,
> cert-presave-command=/usr/libexec/ipa/certmonger/stop_pkicad,
> cert-postsave-command=/usr/libexec/ipa/certmonger/renew_ca_cert
> \"caSigningCert cert-pki-ca\", template-profile=caCACert"
>
> }
>
> },
>
>
>
> I am not sure what to do about this or where to look for more
> information. Any help pointing me in the right direction would be much
> appreciated.
This means that you have a CA configured on the server but the IPA CA
signing cert isn't tracked by certmonger. Running ipa-server-upgrade
should fix it.
rob
3 years
Security of LDAP connections in FreeIPA
by Kevin Cassar
Hi,
As I understand, FreeIPA uses the 389 Directory server as its LDAP implementation. I wanted to know few things about the LDAP connections and whether they are encrypted by default. I tried googling, but couldn't find substantive documentation regarding this.
So far, I know that the Directory Server supports a variety of secure connection types, namely, on port 389 via STARTTLS, LDAPS (port 636) and SASL. However, I'm unsure about what exact mechanism is used to secure (client --> server) and (server <--> server) LDAP connections in FreeIPA, and whether I need to enable any attributes like "Secure bind" for example, on the FreeIPA server.
In case of client --> server connections, I see that the /etc/ldap/ldap.conf has URI set to LDAPS, but, running TCPDUMP on a client showed all outgoing connections to FreeIPA server heading towards port 389. Similarly, I grepped the access logs for STARTTLS connection indicator as defined in the link below, but couldn't find anything:
https://directory.fedoraproject.org/docs/389ds/howto/howto-starttls.html
I'm specifically looking to understand the security of client to server LDAP connections, and server to server connections (when replication is set up.)
Any help is appreciated.
3 years
ipa-healthcheck error
by Dungan, Scott A.
When running a ipa-healthcheck we are seeing one "ERROR" condition under the ipahealthcheck.ipa.certs section:
{
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertTracking",
"result": "ERROR",
"uuid": "df8e46a4-427b-4b40-8db8-e09633d6d903",
"when": "20210405174840Z",
"duration": "1.014180",
"kw": {
"key": "cert-database=/etc/pki/pki-tomcat/alias, cert-nickname=caSigningCert cert-pki-ca, ca-name=dogtag-ipa-ca-renew-agent, cert-presave-command=/usr/libexec/ipa/certmonger/stop_pkicad, cert-postsave-command=/usr/libexec/ipa/certmonger/renew_ca_cert \"caSigningCert cert-pki-ca\", template-profile=caCACert",
"msg": "Missing tracking for cert-database=/etc/pki/pki-tomcat/alias, cert-nickname=caSigningCert cert-pki-ca, ca-name=dogtag-ipa-ca-renew-agent, cert-presave-command=/usr/libexec/ipa/certmonger/stop_pkicad, cert-postsave-command=/usr/libexec/ipa/certmonger/renew_ca_cert \"caSigningCert cert-pki-ca\", template-profile=caCACert"
}
},
I am not sure what to do about this or where to look for more information. Any help pointing me in the right direction would be much appreciated.
-S
3 years
Retrieve service keytab with host keytab authentication?
by Peter Tselios
Hello,
When I retrieve a service keytab, what I do is more or less this:
ipa-getkeytab -a admin -P password -s service/client.example.com -k /path/to/keytab
However, the ipa-getkeytab man page mention this:
===========
-Y, --mech
SASL mechanism to use if -D and -w are not specified. Use either GSSAPI or EXTERNAL.
===========
So, if I am not mistaken, that means I can use another keytab in order to download the service/client.example.com one. Is that true?
And if so, which keytab should I use and how? Because I cannot find an option that goes along with the -Y GSSAPI.
Thanks
3 years
Crash in ipadb_get_principal
by Sushmita Bhattacharya
Hi,
I am facing an issue with a ipa-kdb crash in ipadb_get_principal function, in ipa version 4.6.8. Backtrace below:-
(gdb) bt
#0 0x00007fec38d8d387 in raise () from /lib64/libc.so.6
#1 0x00007fec38d8ea78 in abort () from /lib64/libc.so.6
#2 0x00007fec38d861a6 in __assert_fail_base () from /lib64/libc.so.6
#3 0x00007fec38d86252 in __assert_fail () from /lib64/libc.so.6
#4 0x00007fec3046d353 in ldap_get_values_len () from
/lib64/libldap_r-2.4.so.2
#5 0x00007fec3201422e in ipadb_ldap_attr_to_int () from
/usr/lib64/krb5/plugins/kdb/ipadb.so
#6 0x00007fec320173cb in ipadb_parse_ldap_entry () from
/usr/lib64/krb5/plugins/kdb/ipadb.so
#7 0x00007fec3201832b in ipadb_get_principal () from
/usr/lib64/krb5/plugins/kdb/ipadb.so
#8 0x00007fec3a918bb7 in krb5_db_get_principal () from /lib64/libkdb5.so.8
#9 0x000056443d95fff2 in kdc_get_server_key ()
#10 0x000056443d9603ce in kdc_process_tgs_req ()
#11 0x000056443d95ac97 in process_tgs_req ()
#12 0x000056443d958df3 in dispatch ()
#13 0x000056443d96c950 in process_tcp_connection_read ()
#14 0x00007fec39127b48 in verto_fire () from /lib64/libverto.so.1
#15 0x00007fec31242b13 in tevent_common_invoke_fd_handler () from
/lib64/libtevent.so.0
#16 0x00007fec31249087 in epoll_event_loop_once () from /lib64/libtevent.so.0
#17 0x00007fec31247057 in std_event_loop_once () from /lib64/libtevent.so.0
#18 0x00007fec3124225d in _tevent_loop_once () from /lib64/libtevent.so.0
#19 0x00007fec3912731f in verto_run () from /lib64/libverto.so.1
#20 0x000056443d957af6 in main ()
(gdb) q
We observed this crash with kerberos version 1.15.1.
The issue is that the ldap handle passed from function ipadb_parse_ldap_entry and eventually to openldap, is an invalid LDAP handle (though not NULL). Hence there is an assert failure in function ldap_get_values_len.
(gdb) f 4
#4 0x00007fec3046d353 in ldap_get_values_len (ld=ld@entry=0x56443f44b850,
entry=entry@entry=0x56443f5c4fe0,
target=target@entry=0x7fec3202192b "krbTicketFlags") at getvalues.c:98
98 assert( LDAP_VALID( ld ) );
(gdb) p ld->ldc->ldc_options.ldo_valid
$1 = -17435
(gdb) p/x ld->ldc->ldc_options.ldo_valid
$2 = 0xbbe5
(gdb) f 5
#5 0x00007fec3201422e in ipadb_ldap_attr_to_int
(lcontext=lcontext@entry=0x56443f44b850, le=le@entry=0x56443f5c4fe0,
attrname=attrname@entry=0x7fec3202192b "krbTicketFlags",
result=result@entry=0x7ffcdd2accc4) at ipa_kdb_common.c:383
383 vals = ldap_get_values_len(lcontext, le, attrname);
(gdb) f 7
#7 0x00007fec3201832b in ipadb_get_principal (kcontext=0x56443f47b920,
search_for=<optimized out>, flags=8192, entry=0x7ffcdd2acec8)
at ipa_kdb_principals.c:1311
1311 kerr = ipadb_parse_ldap_entry(kcontext, principal, lentry, entry,
&pol);
(gdb)
Any ideas on this issue ? Is there a specific fix available ? It looks like someone reported a similar crash here : https://pagure.io/freeipa/issue/5633, but there was no fix documented, and it got closed as there was insufficient info. Any help will be much appreciated.
Thanks,
Sushmita
3 years
FreeIPA configuration via Ansible Tower / AWX
by Russ Long
I have an ansible role built out using the Ansible-provided FreeIPA commands, however for more flexibility I want to switch over to the ones available from the FreeIPA project directly. I run the playbook that calls this role from AWX/Tower, and cannot figure out the proper way to set the ipaadmin_principal and ipaadmin_password so I do not have to include it on every individual task. I have tried setting them as variables in the playbook, in the AWX Template, and in the Inventory used by AWX.
These work fine if I set the principal and password on every task, but that's a lot of unnecessary code that also causes confusion for others looking at this.
I'm sure I'm missing something obvious, but help would be appreciated.
--Russ
3 years
Memory leak - ns-slapd
by Jim Richard
When I upgraded IPA back in early February I stared to see an apparent memory leak.
Note please the links to some Zabbix screens, it was only after I suspected a problem that I started tracking ns-slapd memory usage specifically as well. There are two nodes and they both show the same thing happening.
https://photos.app.goo.gl/SFo4rAYpiaE2bK9S7
https://photos.app.goo.gl/aQvgab2StMBGDFa48
https://photos.app.goo.gl/MfFBxFbBHoaRJs7f7
https://photos.app.goo.gl/ik3j3magF8D3toxx8
You can see the trend over a year and then all of the sudden, starting on the day I upgraded, well, you can see. The up’s and down’s after early February are me doing various restarts trying to figure out what was going on.
I’ve tried to get valgrind working but I’m not having any luck there.
Tried some stracing but I’m not sure if what I’m seeing is normal.
Any help please on where to look, how to troubleshoot further.
Thanks !
I see a constant stream of the following from strace on the ns-slapd pid but that might be expected as we’re not an IPv6 environment and FD 9 refers to an IPv6 socket.
getpeername(9, 0x7ffc612b7650, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
poll([{fd=63, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=10, events=POLLIN}, {fd=193, events=POLLIN}, {fd=192, events=POLLIN}, {fd=79, events=POLLIN}, {fd=191, events=POLLIN}, {fd=189, events=POLLIN}, {fd=188, events=POLLIN}, {fd=187, events=POLLIN}, {fd=186, events=POLLIN}, {fd=184, events=POLLIN}, {fd=183, events=POLLIN}, {fd=182, events=POLLIN}, {fd=181, events=POLLIN}, {fd=180, events=POLLIN}, {fd=140, events=POLLIN}, {fd=230, events=POLLIN}, {fd=229, events=POLLIN}, {fd=227, events=POLLIN}, {fd=179, events=POLLIN}, {fd=177, events=POLLIN}, {fd=226, events=POLLIN}, {fd=225, events=POLLIN}, {fd=197, events=POLLIN}, {fd=174, events=POLLIN}, {fd=176, events=POLLIN}, {fd=175, events=POLLIN}, {fd=173, events=POLLIN}, {fd=146, events=POLLIN}, {fd=162, events=POLLIN}, ...], 245, 250) = 1 ([{fd=384, revents=POLLIN}])
futex(0x7f233f68a3f4, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f2335714080, FUTEX_WAKE_PRIVATE, 1) = 1
getpeername(9, 0x7ffc612b7650, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
poll([{fd=63, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=10, events=POLLIN}, {fd=193, events=POLLIN}, {fd=192, events=POLLIN}, {fd=79, events=POLLIN}, {fd=191, events=POLLIN}, {fd=189, events=POLLIN}, {fd=188, events=POLLIN}, {fd=187, events=POLLIN}, {fd=186, events=POLLIN}, {fd=184, events=POLLIN}, {fd=183, events=POLLIN}, {fd=182, events=POLLIN}, {fd=181, events=POLLIN}, {fd=180, events=POLLIN}, {fd=140, events=POLLIN}, {fd=230, events=POLLIN}, {fd=229, events=POLLIN}, {fd=227, events=POLLIN}, {fd=179, events=POLLIN}, {fd=177, events=POLLIN}, {fd=226, events=POLLIN}, {fd=225, events=POLLIN}, {fd=197, events=POLLIN}, {fd=174, events=POLLIN}, {fd=176, events=POLLIN}, {fd=175, events=POLLIN}, {fd=173, events=POLLIN}, {fd=146, events=POLLIN}, {fd=162, events=POLLIN}, ...], 245, 250) = 1 ([{fd=63, revents=POLLIN}])
read(63, "\0\0", 200) = 2
Upgraded from:
2021-02-01T14:25:20Z DEBUG ---> Package ipa-server.x86_64 4.8.4-7.module_el8.2.0+374+0d2d74a1 will be upgraded
2021-02-01T14:25:20Z DEBUG ---> Package ipa-server.x86_64 4.8.7-13.module_el8.3.0+606+1e8766d7 will be an upgrade
2021-02-01T14:25:20Z DEBUG ---> Package 389-ds-base.x86_64 1.4.2.4-10.module_el8.2.0+489+38ed056a will be upgraded
2021-02-01T14:25:20Z DEBUG ---> Package 389-ds-base.x86_64 1.4.3.8-6.module_el8.3.0+604+ab7bf9cc will be an upgrade
2021-02-01T14:25:20Z DEBUG ---> Package 389-ds-base-libs.x86_64 1.4.2.4-10.module_el8.2.0+489+38ed056a will be upgraded
2021-02-01T14:25:20Z DEBUG ---> Package 389-ds-base-libs.x86_64 1.4.3.8-6.module_el8.3.0+604+ab7bf9cc will be an upgrade
2021-02-01T14:25:20Z DEBUG ---> Package 389-ds-base-snmp.x86_64 1.4.2.4-10.module_el8.2.0+489+38ed056a will be upgraded
2021-02-01T14:25:20Z DEBUG ---> Package 389-ds-base-snmp.x86_64 1.4.3.8-6.module_el8.3.0+604+ab7bf9cc will be an upgrade
Current versions are:
CentOS 8:
ipa-client.x86_64 4.8.7-14.module_el8.3.0+698+d6d67052 @appstream
ipa-client-common.noarch 4.8.7-14.module_el8.3.0+698+d6d67052 @appstream
ipa-common.noarch 4.8.7-14.module_el8.3.0+698+d6d67052 @appstream
ipa-healthcheck.noarch 0.4-6.module_el8.3.0+482+9e103aab @AppStream
ipa-healthcheck-core.noarch 0.4-6.module_el8.3.0+482+9e103aab @AppStream
ipa-selinux.noarch 4.8.7-14.module_el8.3.0+698+d6d67052 @appstream
ipa-server.x86_64 4.8.7-14.module_el8.3.0+698+d6d67052 @appstream
ipa-server-common.noarch 4.8.7-14.module_el8.3.0+698+d6d67052 @appstream
389-ds-base.x86_64 1.4.3.8-6.module_el8.3.0+604+ab7bf9cc @AppStream
389-ds-base-libs.x86_64 1.4.3.8-6.module_el8.3.0+604+ab7bf9cc @AppStream
Linux sso-111.sec.placeiq.net 4.18.0-240.15.1.el8_3.x86_64 #1 SMP Mon Mar 1 17:16:16 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Jim Richard
System Administrator III
jrichard(a)placeiq.com | (646) 338-8905 | www.placeiq.com
3 years
