August 2022 - FreeIPA-users - Fedora mailing-lists

DNS/DNSSEC via freeipa/bind9 supporting Unbound
by Harry G. Coin 11 Aug '22

11 Aug '22

Alexander Bokovoy asked for a note on the use of Unbound as a slave resolver to freeipa's bind9+dnssec because of the issues discussed under Re: [Freeipa-users] Re: Dnssec rejected by Cloudflair, Google, accepted by Verizon, AT&T Summarizing: Unbound is just a lot faster than bind9+dnssec, additionally offering native support for DANE, DNS over tls and etc. Older hardware running bind9 can't process DNS + DNSSec queries under the timeout limits used by major public dns resolvers relied upon by thousands, including mail providers. Unbound can and does. Steps: 1. Work with existing freeipa tools and documentation to get dnssec working properly under bind9, validate it using at least two of the public dnssec diagnostic tools (verisign, etc.). 2. Use global dns performance testing tools to see whether all report good results from several dozen of the world's public dns resolvers. If they all report 'green' or 'ok', then your servers are 'fast enough' and you don't need this further work (unless you want DANE, dns over tls and the other things unbound offers). 3. For at least one, and preferably at least as many freeipa master/slaves identify an ip4 (and ip6) address for use by the unbound resolver service. It's best if they are in the same subnet as at least one of the freeipa machine's interfaces and preferably secured for physical reasons or, second best, encryption. 4. Load those addresses into the 'Allow Transfer' section of Freeipa's dns domain manager settings window. Be sure reasonable values exist in every section measured in (seconds). I also chose to edit /etc/named/ipa-options-ext.conf to 'notify explicit; also-notify { all freeipa and unbound addresses other than the current host } ; allow-notify { only freeipa and not unbound addresses; } You might take the chance to set up acls and make good decisions about rate limiting and allow-* settings. I found only rebooting freeipa & bind9 caused bind9 to get the updated 'allow transfer' settings from freeipa. Restarting bind9 alone was not enough. 5. Either in a new network name space on the same host as freeipa or in a vm on that host, or, well, anywhere really except on the same set of addresses as freeipa's named daemon: Load unbound and prove up it is working under default settings using the addresses reserved above. 6. Create a file in unbound.conf.d for access control. I suggest leading it off with access-control: 0.0.0.0/0 refuse_non_local access-control: ::0/0 refuse_non_local access-control: 127.0.0.0/8 allow_snoop access-control: ::1 allow_snoop followed by whatever local address ranges you'd like for full dns recursive services, such as your 'lan' or equivalent eg access-control: 10.something.whatnot.0/24 allow In an related 'options' file, include 'interface' lines for each host address you want unbound to process incoming queries (your local lan interface as well), and including at least one of the host addresses you entered into freeipa above. Include 'outgoing-interface' lines the interface on the unbound host that matches at least one of the addresses entered into freeipa. In another file, or one file per zone, add an 'auth-zone:' section using 'name:' as the zone to support, and 'primary:..." entries for each freeipa server. 7. Restart unbound. use dig @unbound-serverip to validate proper operation. 8. Change NS records on all servers to be handled by unbound to point to the unbound's interfaces named in the 'interface' lines above. I chose to have public IPs point at the unbound supported slave resolvers, and left all local lan resolution using freeipa, since there was no security value added by dns over tls & etc owing to the physical site-wire security. But YMMV. 9. Revalidate proper DNSSEC validation and worldwide resolver performance/accuracy. In my case, 'ancient' servers passed all tests using the unbound frontend with and without dnssec. They also passed using freeipa's setup without dnssec (nearly always, one in Australia and one in Brazil would occasionally fail). Freeipa's servers with dnssec passed most of them, but failed google and cloudflare always, occasionally one or two others but passed most. There are a fair few other options to do with performance and features you can add and manage, well documented by the unbound support folks. That's it! Hope that helps others. Harry Coin https://rockstablesystems.com

2 1

IdM with trust relationship with Samba AD DC - User accounts with passwords expired
by Mateo Duffour 10 Aug '22

10 Aug '22

Hi, We currently have an IdM installation with a trust relationship with a Samba AD DC. Our user accounts reside on Samba AD DC, we dont have user accounts on IdM. We are having a problem with Samba user acounts that have its passwords expired. When we try to login with an ubuntu IdM client with one of those accounts, it fails and asks again for password. The behaviour we are expecting is that Ubuntu should ask for a password change. Thanks, best regards. Lic. Mateo Duffour Unidad Informática 2901.40.91 [ http://maps.apple.com/?q=18%20de%20julio%20985%20-%20Piso%204,Montevideo,Ur… | 18 de julio 985 - Piso 3, Montevideo, Uruguay ] [ http://www.fnr.gub.uy/ | ] No me imprimas si no es necesario. Protejamos el medio ambiente. Este mensaje y la información adjunta al mismo está dirigido exclusivamente a su destinatario. Puede contener información confidencial, privilegiada o de uso restringido, protegida por las normas. Si Ud. recibió este e-mail por error, por favor, sírvase notificarle a quien se lo envió y borrar el original. Cualquier otro uso del e-mail por Ud. está prohibido.

5 43

Potential API change for FreeIPA plugin writers
by Alexander Bokovoy 08 Aug '22

08 Aug '22

Hi, as you have probably noticed in a thread we had with Leo on freeipa-users@ about FreeIPA plugin development, we hadn't had consistency in handling boolean types between LDAP and IPA Python API level. A change is coming that would make 'native' boolean types used in both worlds. If your plugins rely on Bool() parameter handling in FreeIPA, your code might be affected. If your scripts using output of IPA API rely on case-sensitive output, you might need to adjust your code. If not, you can skip this email. Pull request https://github.com/freeipa/freeipa/pull/6294 turns handling of boolean types to be native to each side: - in LDAP, TRUE and FALSE strings used to represent the values - in Python, native True and False constants of bool type will be used to represent an LDAP boolean. Prior to PR#6294, when an LDAP attribute with a boolean syntax was read from LDAP, its representation in IPA Python code was either 'TRUE' or 'FALSE' string. This created a bit of inconvenience: - Python code had to explicitly compare a value to 'TRUE' or 'FALSE', - Web UI JavaScript code had to use a radio-box where a simple checkbox would be enough - JavaScript plugin code would need to handle all types of 'TRUE', 'FALSE', 1, 0, true, false, none in every place where a boolean type would be enough After PR#6294 is merged, IPA Python code will use Python bool type. JSON-RPC response to an IPA API command request would produce a simple 'true' or 'false' instead of ["TRUE"] or ["FALSE"] elements. This means, for example, that in the following command ipa dnszone-show ipa.test instead of "idnsallowdynupdate": [ "TRUE" ], one would get "idnsallowdynupdate": [ true ], and the output of 'ipa dnszone-show ipa.test' would have 'True' instead of 'TRUE' (and False instead of 'FALSE'): $ ipa dnszone-show ipa.test Zone name: ipa.test. Active zone: True Authoritative nameserver: idm.ipa.test. Administrator e-mail address: hostmaster.ipa.test. SOA serial: 1654159048 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant IPA.TEST krb5-self * A; grant IPA.TEST krb5-self * AAAA; grant IPA.TEST krb5-self * SSHFP; Dynamic update: True Allow query: any; Allow transfer: none; If your scripts rely on the case-sensitive output, you'd need to fix them. IPA tools already able to handle the changes so they are backward-compatible. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland

3 3

Dnssec rejected by Cloudflair, Google, accepted by Verizon, AT&T
by Harry G. Coin 08 Aug '22

08 Aug '22

I have a dnssec enabled domain that passes all the verisign and related dnssec tests (all green, no errors) and dns sources like AT&T and Verizon. But it fails at some popular dns servers like google and cloudflair. I'd appreciate what anyone can make of that, there are no obvious debugging directions when verisgn says 'all good'. If I turn on the 'cdflag' most all of https://dnschecker.org/#A/quietfountain.com works. Turn it off, and some report problems. Some clues most welcome! Harry Coin Here's Quad9, for example: [root@registry1 ~]# dig @9.9.9.9 quietfountain.com ; <<>> DiG 9.11.36-RedHat-9.11.36-3.el8 <<>> @9.9.9.9 quietfountain.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45758 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;quietfountain.com. IN A ;; ANSWER SECTION: quietfountain.com. 43200 IN A 147.135.121.120 quietfountain.com. 43200 IN A 51.81.131.192 ;; Query time: 1463 msec ;; SERVER: 9.9.9.9#53(9.9.9.9) ;; WHEN: Tue Jul 26 17:53:39 CDT 2022 ;; MSG SIZE rcvd: 78 But, here's cloudflair and google: [root@registry1 ~]# dig @1.1.1.1 quietfountain.com ; <<>> DiG 9.11.36-RedHat-9.11.36-3.el8 <<>> @1.1.1.1 quietfountain.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 64113 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for quietfountain.com.) ;; QUESTION SECTION: ;quietfountain.com. IN A ;; Query time: 2197 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) ;; WHEN: Tue Jul 26 17:51:22 CDT 2022 ;; MSG SIZE rcvd: 103 [root@registry1 ~]# dig @8.8.8.8 quietfountain.com ; <<>> DiG 9.11.36-RedHat-9.11.36-3.el8 <<>> @8.8.8.8 quietfountain.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61907 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;quietfountain.com. IN A ;; Query time: 2303 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Tue Jul 26 17:51:35 CDT 2022 ;; MSG SIZE rcvd: 46

3 7

Ubuntu uses /etc/apache2/nssdb instead of the /etc/httpd/alias service and the certificate store.
by roy liang 07 Aug '22

07 Aug '22

> I made the following soft link > ln -s /etc/apache2/nssdb /etc/httpd/alias > But return code 77 as well, so what do I need to do? > > root@migration-ipa-65-186:/.ipa/log# tailf renew.log > 2022-04-09T16:02:13Z 21810 MainThread ipa DEBUG stderr=* Trying > 10.12.65.186... > * Connected to migration-ipa-65-186.hiido.host.yydevops.com (10.12.65.186) port 8443 (#0) > * Initializing NSS with certpath: sql:/etc/httpd/alias > * WARNING: failed to load NSS PEM library libnsspem.so. Using OpenSSL PEM certificates > will not work. > * Closing connection 0 > GET > "https://migration-ipa-65-186.hiido.host.yydevops.com:8443/ca/agent/ca/profi…" > code = 77 > code_text = "Problem with the SSL CA cert (path? access rights?)" > results = "(null)" > > 2022-04-09T16:02:22Z 21811 MainThread ipa DEBUG Initializing principal > host/migration-ipa-65-186.hiido.host.yydevops.com(a)YYDEVOPS.COM using keytab > /etc/krb5.keytab > 2022-04-09T16:02:22Z 21811 MainThread ipa DEBUG using ccache > /var/run/certmonger/tmp-FYfJPZ/ccache > 2022-04-09T16:02:22Z 21811 MainThread ipa DEBUG Attempt 1/1: success > 2022-04-09T16:02:22Z 21811 MainThread ipa DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2022-04-09T16:02:23Z 21811 MainThread ipa.ipapython.ipaldap.SchemaCache > DEBUG flushing ldap://migration-ipa-65-186.hiido.host.yydevops.com:389 from SchemaCache > 2022-04-09T16:02:23Z 21811 MainThread ipa.ipapython.ipaldap.SchemaCache > DEBUG retrieving schema for SchemaCache > url=ldap://migration-ipa-65-186.hiido.host.yydevops.com:389 > conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7f307a537290> > 2022-04-09T16:02:24Z 21811 MainThread ipa DEBUG Starting external process > 2022-04-09T16:02:24Z 21811 MainThread ipa DEBUG > args=/usr/lib/certmonger/dogtag-ipa-renew-agent-submit -vv > 2022-04-09T16:02:24Z 21811 MainThread ipa DEBUG Process finished, return > code=3 > 2022-04-09T16:02:24Z 21811 MainThread ipa DEBUG stdout=Error 77 connecting > to https://migration-ipa-65-186.hiido.host.yydevops.com:8443/ca/agent/ca/pro...: > Problem with the SSL CA cert (path? access rights?). > > 2022-04-09T16:02:24Z 21811 MainThread ipa DEBUG stderr=* Trying > 10.12.65.186... > * Connected to migration-ipa-65-186.hiido.host.yydevops.com (10.12.65.186) port 8443 (#0) > * Initializing NSS with certpath: sql:/etc/httpd/alias > * WARNING: failed to load NSS PEM library libnsspem.so. Using OpenSSL PEM certificates > will not work. > * Closing connection 0 > GET > "https://migration-ipa-65-186.hiido.host.yydevops.com:8443/ca/agent/ca/profi…" > code = 77 > code_text = "Problem with the SSL CA cert (path? access rights?)" > results = "(null)" > > 2022-04-09T16:02:32Z 21809 MainThread ipa DEBUG Initializing principal > host/migration-ipa-65-186.hiido.host.yydevops.com(a)YYDEVOPS.COM using keytab > /etc/krb5.keytab > 2022-04-09T16:02:32Z 21809 MainThread ipa DEBUG using ccache > /var/run/certmonger/tmp-svWgpP/ccache > 2022-04-09T16:02:32Z 21809 MainThread ipa DEBUG Attempt 1/1: success > 2022-04-09T16:02:32Z 21809 MainThread ipa DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2022-04-09T16:02:33Z 21809 MainThread ipa.ipapython.ipaldap.SchemaCache > DEBUG flushing ldap://migration-ipa-65-186.hiido.host.yydevops.com:389 from SchemaCache > 2022-04-09T16:02:33Z 21809 MainThread ipa.ipapython.ipaldap.SchemaCache > DEBUG retrieving schema for SchemaCache > url=ldap://migration-ipa-65-186.hiido.host.yydevops.com:389 > conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7fbd8bfd6f80> > 2022-04-09T16:02:34Z 21809 MainThread ipa DEBUG Starting external process > 2022-04-09T16:02:34Z 21809 MainThread ipa DEBUG > args=/usr/lib/certmonger/dogtag-ipa-renew-agent-submit -vv > 2022-04-09T16:02:34Z 21809 MainThread ipa DEBUG Process finished, return > code=3 > 2022-04-09T16:02:34Z 21809 MainThread ipa DEBUG stdout=Error 77 connecting > to https://migration-ipa-65-186.hiido.host.yydevops.com:8443/ca/agent/ca/pro...: > Problem with the SSL CA cert (path? access rights?). > > 2022-04-09T16:02:34Z 21809 MainThread ipa DEBUG stderr=* Trying > 10.12.65.186... > * Connected to migration-ipa-65-186.hiido.host.yydevops.com (10.12.65.186) port 8443 (#0) > * Initializing NSS with certpath: sql:/etc/httpd/alias > * WARNING: failed to load NSS PEM library libnsspem.so. Using OpenSSL PEM certificates > will not work. > * Closing connection 0 > GET > "https://migration-ipa-65-186.hiido.host.yydevops.com:8443/ca/agent/ca/profi…" > code = 77 > code_text = "Problem with the SSL CA cert (path? access rights?)" > results = "(null)" > > 2022-04-09T16:02:42Z 21812 MainThread ipa DEBUG Initializing principal > host/migration-ipa-65-186.hiido.host.yydevops.com(a)YYDEVOPS.COM using keytab > /etc/krb5.keytab > 2022-04-09T16:02:42Z 21812 MainThread ipa DEBUG using ccache > /var/run/certmonger/tmp-DSagx_/ccache > 2022-04-09T16:02:42Z 21812 MainThread ipa DEBUG Attempt 1/1: success > 2022-04-09T16:02:42Z 21812 MainThread ipa DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2022-04-09T16:02:43Z 21812 MainThread ipa.ipapython.ipaldap.SchemaCache > DEBUG flushing ldap://migration-ipa-65-186.hiido.host.yydevops.com:389 from SchemaCache > 2022-04-09T16:02:43Z 21812 MainThread ipa.ipapython.ipaldap.SchemaCache > DEBUG retrieving schema for SchemaCache > url=ldap://migration-ipa-65-186.hiido.host.yydevops.com:389 > conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7f1c70811b00> > 2022-04-09T16:02:44Z 21812 MainThread ipa DEBUG Starting external process > 2022-04-09T16:02:44Z 21812 MainThread ipa DEBUG > args=/usr/lib/certmonger/dogtag-ipa-renew-agent-submit -vv > 2022-04-09T16:02:44Z 21812 MainThread ipa DEBUG Process finished, return > code=3 > 2022-04-09T16:02:44Z 21812 MainThread ipa DEBUG stdout=Error 77 connecting > to https://migration-ipa-65-186.hiido.host.yydevops.com:8443/ca/agent/ca/pro...: > Problem with the SSL CA cert (path? access rights?). > > 2022-04-09T16:02:44Z 21812 MainThread ipa DEBUG stderr=* Trying > 10.12.65.186... > * Connected to migration-ipa-65-186.hiido.host.yydevops.com (10.12.65.186) port 8443 (#0) > * Initializing NSS with certpath: sql:/etc/httpd/alias > * WARNING: failed to load NSS PEM library libnsspem.so. Using OpenSSL PEM certificates > will not work. > * Closing connection 0 > GET > "https://migration-ipa-65-186.hiido.host.yydevops.com:8443/ca/agent/ca/profi…" > code = 77 > code_text = "Problem with the SSL CA cert (path? access rights?)" > results = "(null)" > > root@migration-ipa-65-186:/.ipa/log# ll /etc/httpd/alias > lrwxrwxrwx 1 root root 18 Apr 10 00:00 /etc/httpd/alias -> /etc/apache2/nssdb hello Can I get some attention? Using Ubuntu install freeipa is an addition left by the company, I also feel very sorry. If I fix the expiration problem, I will migrate to centos, but I need to solve the certificate expiration problem first, Ubuntu does not use /etc/httpd/alias service and certificate store./etc/apache2/nssdb /apache2/nssdb /etc/apache2/nssdb

3 14

Deployment in Docker container on DigitalOcean VPS
by Georgiy Odisharia 07 Aug '22

07 Aug '22

Hello there, I completely newbie in questions of LDAP. I want to deploy FreeIPA to my VPS hosted on DigitalOcean using Docker image, It will be used only for personal purposes. I have couple of questions. 1, Could I set up FreeIPA with following domains this way: a. LDAP server is available from freeipa.<my domain>. b. Web interface is available through services.<my domain>/freeipa. c. My devices will be in DEVICES.<MY DOMAIN> domain. 2. FreeIPA contains DNS server. I have on my host machine enabled proxy caching DNS server in systemd. I understand I must disable it. Which consequences it will bring? What should I do to have DNS resolving on my host machine and have DNS enabled inside Docker container with DNS server inside it? 3. I want to reuse my acme.sh issued keys by Let's Encrypt for my personal website for FreeIPA. Is it enough and what should I do to achieve that? I don't want to use recommended way to do it, I want to integrate acme.sh issued keys inside FreeIPA container.

2 1

Deployment in Docker container on DigitalOcean VPS
by Georgiy Odisharia 06 Aug '22

06 Aug '22

Hello there, I completely newbie in questions of LDAP. I want to deploy FreeIPA to my VPS hosted on DigitalOcean using Docker image, It will be used only for personal purposes. I have couple of questions. 1, Could I set up FreeIPA with following domains this way: a. LDAP server is available from freeipa.<my domain>. b. Web interface is available through services.<my domain>/freeipa. c. My devices will be in DEVICES.<MY DOMAIN> domain. 2. FreeIPA contains DNS server. I have on my host machine enabled proxy caching DNS server in systemd. I understand I must disable it. Which consequences it will bring? What should I do to have DNS resolving on my host machine and have DNS enabled inside Docker container with DNS server inside it? 3. I want to reuse my acme.sh issued keys by Let's Encrypt for my personal website for FreeIPA. Is it enough and what should I do to achieve that? I don't want to use recommended way to do it, I want to integrate acme.sh issued keys inside FreeIPA container.

1 0

road-warrior laptop vs password change in FreeIPA
by Harald Dunkel 04 Aug '22

04 Aug '22

Hi folks, I've got a few colleagues running Debian 10 or 11 on a laptop. Their account is managed by FreeIPA in the office. On first-time login their laptop is wired to the office lan. When they are in home office they have a VPN connection (IPsec, wireguard or openvpn) to the office, but since both wlan and VPN are usually activated by Network Manager *after* login time I wonder what needs to be done to update the login information cached by sssd, esp if the user has changed his login password in the FreeIPA web interface? By now I tried kinit username sss_cache -E service restart sssd This did not help. kinit accepts the new password, of course, but it doesn't update the cache, nor do the others. Important point is that the user doesn't lose his cached entry, anyway. Coming to the office just to register his new password is not an optiom. Every helpful hint is highly appreciated Harri

3 5

DNS issues with dual boot hosts
by Sameer Gurung 03 Aug '22

03 Aug '22

Hello Everyone, I run a freeipa server that allows users to login to linux (ubuntu) hosts. These hosts also have windows 10 in them in dual boot mode. Hence I also run an active directory server, with DHCP. This windows DHCP server also provides IP addresses to the hosts when they boot into ubuntu. This setup works fine except that when the hosts are given a different IP address they do not update the IPA server's DNS with their newly acquired IP address. When installing ipa on the clients, I had added the --enable-dns-updates option and setup was smooth without any issues. Any help in this will be highly appreciated. *Sameer Kr. Gurung* -- This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Saint Mary's College, Shillong, Meghalaya, India-793003, smcs.ac.in <http://smcs.ac.in>

2 1

Freeipa in a virtual machine, host being a client
by lol lol 03 Aug '22

03 Aug '22

Hello, I'd like to run IPA server in a vm and at the same time use the host OS as an IPA client for a uniform set-up of DNS, NTP, SSO etc across the board. I have a replica but let's imagine that I don't. So I have only one IPA server running on as a guest on an IPA client host. I imagine that I would encounter issues at start-up since IPA client services should start AFTER the VM is up and running. What would be your recommendation of going about it? Should I start libvirt before IPA client services in boot chain (and what exact services?) and then sleep long enough so that VM has the time to start? Or maybe be I should just restart some IPA client services after booting? Thank you.

4 10

2025

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users August 2022