November 2018 - FreeIPA-users - Fedora mailing-lists

Abstracted NTP server configuration
by Rob Crittenden 15 Jan '19

15 Jan '19

A PR to support multiple NTP servers was submitted in https://github.com/freeipa/freeipa/pull/2169 This spawned a design at https://www.freeipa.org/page/V4/NTP_Servers_Configuration We need to discuss the design. rob

5 15

FreeIPA containerization status
by Jan Pazdziora 23 Dec '18

23 Dec '18

Hello, in the past couple of week I've pushed multiple changes to the https://github.com/freeipa/freeipa-container repository, fixing and enabling Fedora 28 and Fedora 29 Dockerfiles, adding Travis CI configuration where we currently test IPA master and replica setups in images of Fedoras from 23 to rawhide and on CentOS 7: https://travis-ci.org/freeipa/freeipa-container/branches Testing on Travis' Ubuntus allowed me to reproduce and fix some issues that people have observed on non-RHEL/CentOS/Fedora docker hosts. One of the results is that docker run's --privileged or --cap-add SYS_ADMIN options should not be needed anymore, making things more confined and more secure. In fact, it's quite likely that running the FreeIPA server containers as privileged will result in https://github.com/freeipa/freeipa-container/issues/254 ... so just don't do it. Another focus of the effort was to make it possible to run the containers as read-only (docker run --read-only), making all the changes that are done during the initial ipa-server-install or during runtime properly confined to the /data volume, or pointed to discardable /tmp. While things pass in my local read-only tests, in Travis CI the initial ipa-server-install phase runs fine but starting the read-only container afterwars seems to hang: https://travis-ci.org/adelton/freeipa-container/builds/459418370 Any help with investigating why this is happening would be appreciated. -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, Red Hat

2 4

Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket expired)
by lune voo 22 Dec '18

22 Dec '18

Hello ! I contact you because I have a random problem with my 3.0.0.47 FreeIPA server. Sometimes, suddenly, I cannot use anymore the REST API and I got the following errors when I try things like ipa user-show <myuser> : Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket expired)] traceback : <traceback object at 0x3b917a0> The kinit works fine, klist also. My ticket is valid until the day after so no problem from there. The datetime is the same between the IPA server and the IPA client. When I check the httpd logs on the IPA server, as long as this error lasts, I don't see any logs at all. For example, today, the problem occured at 12:06:39 and in the HTTPD error logs : [Wed Oct 31 12:05:23 2018] [error] ipa: INFO: aPrincipal@MYREALM: user_show(u'anotherPincipal', rights=False, all=True, raw=False, version=u'2.49', no_members=False): SUCCESS [Wed Oct 31 12:07:23 2018] [error] ipa: INFO: aPrincipal@MYREALM: user_find(u'PrincipalPattern_', sizelimit=1000, whoami=False, all=False, raw=False, version=u'2.49', no_members=False, pkey_only=False): SUCCESS There is nothing in the dirsrv error logs at this time and around this time. Nothing neither in the PKI CA logs. When I check the logs in cli.log, I find this kind of lines : 2018-10-31T12:06:39Z 1933 MainThread ipa.ipalib.rpc.xmlclient INFO trying https://<IPA-MASTER>/ipa/xml 2018-10-31T12:06:39Z 1933 MainThread ipa.ipalib.rpc.xmlclient INFO Forwarding 'user_show' to server u'https://<IPA-MASTER>/ipa/xml' 2018-10-31T12:06:39Z 1947 MainThread ipa.ipalib.rpc.xmlclient INFO trying https://<IPA-MASTER>/ipa/xml 2018-10-31T12:06:39Z 1947 MainThread ipa.ipalib.rpc.xmlclient INFO Forwarding 'user_show' to server u'https://<IPA-MASTER>/ipa/xml' 2018-10-31T12:06:40Z 1961 MainThread ipa.ipalib.rpc.xmlclient INFO trying https://<IPA-MASTER>/ipa/xml 2018-10-31T12:06:40Z 1961 MainThread ipa.ipalib.rpc.xmlclient INFO Forwarding 'user_show' to server u'https://<IPA-MASTER>/ipa/xml' 2018-10-31T12:06:40Z 1975 MainThread ipa.ipalib.rpc.xmlclient INFO trying https://<IPA-MASTER>/ipa/xml 2018-10-31T12:06:40Z 1975 MainThread ipa.ipalib.rpc.xmlclient INFO Forwarding 'user_show' to server u'https://<IPA-MASTER>/ipa/xml' 2018-10-31T12:07:27Z 2159 MainThread ipa INFO The ipactl command was successful 2018-10-31T12:07:27Z 2160 MainThread ipa INFO The ipactl command was successful I cannot see anything special in the krb5kdc.log neither for this time. The only line corresponding to the IP of the client are the followings : Oct 31 12:06:24 <IPA-MASTER> krb5kdc[137188](info): AS_REQ (4 etypes {18 17 16 23}) <IP CLIENT>: NEEDED_PREAUTH: <MYUSER>@<MYREALM> for krbtgt/<MYREALM>@<MYREALM>, Additional pre-authentication required Oct 31 12:06:24 <IPA-MASTER> krb5kdc[137188](info): AS_REQ (4 etypes {18 17 16 23}) <IP CLIENT>: NEEDED_PREAUTH: <MYUSER>@<MYREALM> for krbtgt/<MYREALM>@<MYREALM>, Additional pre-authentication required Oct 31 12:06:24 <IPA-MASTER> krb5kdc[137188](info): closing down fd 10 Oct 31 12:06:24 <IPA-MASTER> krb5kdc[137188](info): closing down fd 10 Oct 31 12:06:24 <IPA-MASTER> krb5kdc[137181](info): AS_REQ (4 etypes {18 17 16 23}) <IP CLIENT>: ISSUE: authtime 1540983984, etypes {rep=18 tkt=18 ses=18}, <MYUSER>@<MYREALM> for krbtgt/<MYREALM>@<MYREALM> Oct 31 12:06:24 <IPA-MASTER> krb5kdc[137181](info): AS_REQ (4 etypes {18 17 16 23}) <IP CLIENT>: ISSUE: authtime 1540983984, etypes {rep=18 tkt=18 ses=18}, <MYUSER>@<MYREALM> for krbtgt/<MYREALM>@<MYREALM> Oct 31 12:06:24 <IPA-MASTER> krb5kdc[137181](info): closing down fd 10 Oct 31 12:06:24 <IPA-MASTER> krb5kdc[137181](info): closing down fd 10 We are multiple users connecting to the same server with SSH and using root. But each one of us use a different KRB5CCNAME to take a kerberos ticket. (we take different ticket, me for example I take an admin ticket, a colleague takes another principal ticket). I tried using the ipa user-show with the -d flag : ipa -d user-show <myuser> and I compared the result between one which failed and one which was successfull. The difference came at this step : When it failed : ipa: DEBUG: approved_usage = SSL Server intended_usage = SSL Server ipa: DEBUG: cert valid True for "CN=<IPA-MASTER>,O=<MYREALM>" ipa: DEBUG: handshake complete, peer = <IP>:443 ipa: DEBUG: Protocol: TLS1.2 ipa: DEBUG: Cipher: TLS_RSA_WITH_AES_128_CBC_SHA ipa: DEBUG: Caught fault 2100 from server https://<IPA-MASTER>/ipa/session/xml: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket expired) ipa: DEBUG: Destroyed connection context.xmlclient ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket expired) When it succeeds : ipa: DEBUG: approved_usage = SSL Server intended_usage = SSL Server ipa: DEBUG: cert valid True for "CN=<IPA-MASTER>,O=<MYREALM>" ipa: DEBUG: handshake complete, peer = <IP>:<PORT> ipa: DEBUG: Protocol: TLS1.2 ipa: DEBUG: Cipher: TLS_RSA_WITH_AES_128_CBC_SHA ipa: DEBUG: received Set-Cookie 'ipa_session=385454761d74afed915a24124ba5ef25; Domain=<IPA-MASTER>; Path=/ipa; Expires=Wed, 31 Oct 2018 15:57:45 GMT; Secure; HttpOnly' ipa: DEBUG: storing cookie 'ipa_session=385454761d74afed915a24124ba5ef25; Domain=<IPA-MASTER>; Path=/ipa; Expires=Wed, 31 Oct 2018 15:57:45 GMT; Secure; HttpOnly' for principal <myPrincipal>@<MYREALM> ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:<myPrincipal>@<MYREALM> ipa: DEBUG: stdout=485338998 ipa: DEBUG: stderr= ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:<myPrincipal>@<MYREALM> ipa: DEBUG: stdout=485338998 ipa: DEBUG: stderr= ipa: DEBUG: args=keyctl pupdate 485338998 ipa: DEBUG: stdout= ipa: DEBUG: stderr= ipa: DEBUG: Destroyed connection context.xmlclient So when it works, it sets a session cookie ? Some information about FreeIPA and cookies : https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/ May you help me please ? As a note, I found a workaround for that. I need to destroy my ticket with kdestroy and then to disconnect from the server. Then when I connect back to the server, I take a kerberos ticket and I can use the rest api. This problem is really strange, thank you in advance for your help guys. Lune

3 6

Vault feature for AD users
by Ronald Wimmer 20 Dec '18

20 Dec '18

Is there any possibility to use the vault feature for external (AD) users?

2 2

client ldap issue
by Jaroslav Shejbal 11 Dec '18

11 Dec '18

Hi everyone, I am pretty new to freeipa and i like it a lot but I have one problem which I cannot solve I am using ipa-server (freeipa-server) on ubuntu 18.10 and ipa-clients debian 9, so I am not using ipa-client package only nscd & sssd and configuration. All clients are successfully enrolled provided with keytab file. Some clients works fine and it looks like this (in /var/log/auth.log): Nov 26 17:54:02 ipa krb5kdc[1345]: AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) AA.BB.CC.DD: NEEDED_PREAUTH: host/some-working-host.domain.com(a)DOMAIN.COM for krbtgt/DOMAIN.COM(a)DOMAIN.COM, Additional pre-authentication required Nov 26 17:54:02 ipa krb5kdc[1345]: AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) AA.BB.CC.DD: ISSUE: authtime 1543254842, etypes {rep=18 tkt=18 ses=18}, host/some-working-host.domain.com(a)DOMAIN.COM for krbtgt/DOMAIN.COM(a)DOMAIN.COM Nov 26 17:54:02 ipa krb5kdc[1345]: TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) AA.BB.CC.DD: ISSUE: authtime 1543254842, etypes {rep=18 tkt=18 ses=18}, host/some-working-host.domain.com(a)DOMAIN.COM for ldap/ipa.domain.com(a)DOMAIN.COM and some are not provided with the ldap line: Nov 26 18:12:51 ipa krb5kdc[1345]: AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) AA.BB.CC.DD: NEEDED_PREAUTH: host/some-not-working-host.domain.com(a)DOMAIN.COM for krbtgt/DOMAIN.COM(a)DOMAIN.COM, Additional pre-authentication required Nov 26 18:12:51 ipa krb5kdc[1345]: AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) AA.BB.CC.DD: ISSUE: authtime 1543255971, etypes {rep=18 tkt=18 ses=18}, host/some-not-working-host.domain.com(a)DOMAIN.COM for krbtgt/DOMAIN.COM(a)DOMAIN.COM (lines with "closing down fd 12" was omitted, also hostnames IPs and domains was replaced) I've checked DNS settings, time difference and various logs but with no success. I've also try to remove rm -f /var/lib/sss/db/* and reinstall client packages. Do you have any idea where and what should I look for regarding this issue?

2 3

Issue setting up FreeIPA and Samba
by Robert Byrne 05 Dec '18

05 Dec '18

Hi, I am trying to setup FreeIPA to authenticate users logging into Linux systems, but would also like to use this to authenticate users accessing Samba shares from Windows clients. The problem is that I cannot access the shares at all from Windows clients and when I try to access a share from a Linux client, the following error message is printed: robert@workstation 14:13:09 > smbclient //192.168.0.xx/samba -U robert WARNING: The "syslog" option is deprecated krb5_init_context failed (Invalid argument) smb_krb5_context_init_basic failed (Invalid argument) Enter WORKGROUP\robert's password: krb5_init_context failed (Invalid argument) smb_krb5_context_init_basic failed (Invalid argument) session setup failed: NT_STATUS_LOGON_FAILURE Information regarding the setup: - The FreeIPA + Samba server (samba.linux.company.local) is a VM running CentOS 7. The FreeIPA version is "VERSION: 4.5.4, API_VERSION: 2.228". The Samba version is 4.7.1. - The firewalls on the server, VM host and clients are turned off for debugging purposes. - SELINUX is also turned off. - This was a fresh install and FreeIPA was setup with the following commands: sudo yum install ipa-server sudo ipa-server-install Do you want to configure integrated DNS (BIND)? [no]: no Server host name [ipa.company.local]: samba.linux.company.local Please confirm the domain name [company.local]: samba.linux.company.local Please provide a realm name [SAMBA.COMPANY.LOCAL]: SAMBA.LINUX.COMPANY.LOCAL - The users can log into the Linux workstations that have been enrolled, suggesting that the setup is at least partly correct. The Windows clients are not enrolled into the FreeIPA domain and are instead in the domain company.local. I followed the instructions here (https://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA…) with the following options: yum install ipa-server-trust-ad sudo ipa-adtrust-install Enable trusted domains support in slapi-nis? [no]: no NetBIOS domain name [LINUX]: LINUX Do you want to run the ipa-sidgen task? [no]: yes Followed by: sudo mkdir /samba sudo chmod 777 /samba sudo net conf addshare samba /samba writeable=y guest_ok=n sudo systemctl restart smb Running sudo net conf list produces the following output: [global] workgroup = LINUX netbios name = SAMBA realm = LINUX.COMPANY.LOCAL kerberos method = dedicated keytab dedicated keytab file = /etc/samba/samba.keytab create krb5 conf = no security = user domain master = yes domain logons = yes log level = 1 max log size = 100000 log file = /var/log/samba/log.%m passdb backend = ipasam:ldapi://%2fvar%2frun%2fslapd-LINUX-COMPANY-LOCAL.socket disable spoolss = yes ldapsam:trusted = yes ldap ssl = off ldap suffix = dc=linux,dc=company,dc=local ldap user suffix = cn=users,cn=accounts ldap group suffix = cn=groups,cn=accounts ldap machine suffix = cn=computers,cn=accounts rpc_server:epmapper = external rpc_server:lsarpc = external rpc_server:lsass = external rpc_server:lsasd = external rpc_server:samr = external rpc_server:netlogon = external rpc_server:tcpip = yes rpc_daemon:epmd = fork rpc_daemon:lsasd = fork [samba] path = /samba guest ok = yes read only = no When I try to mount the share on Windows clients (either with \\192.168.0.xx\samba or \\samba.linux.company.local in Explorer) it states that 'The user name or password is incorrect.' I am not convinced that this is the case, however, since the same message is displayed even if the share is created with the option 'guest_ok=y'. If I try to mount the 'guest_ok=y' share from a Linux client in the FreeIPA realm, I at least get an error message: robert@workstation 14:13:09 > smbclient //192.168.0.xx/samba -U username WARNING: The "syslog" option is deprecated krb5_init_context failed (Invalid argument) smb_krb5_context_init_basic failed (Invalid argument) Enter LINUX\robert's password: krb5_init_context failed (Invalid argument) smb_krb5_context_init_basic failed (Invalid argument) session setup failed: NT_STATUS_LOGON_FAILURE Under both Windows and Linux I have tried all combinations of domain (LINUX, SAMBA, WORKGROUP) and various user that I can think of, but with no success. Does anyone have an idea what the issue might be? I previously created the above setup on a pair of VMs and everything worked as expected, but am having difficulty reproducing it here.... Many thanks in advance for any help and suggestions! Please let me know if you need any more information. Rob

3 4

yubikey csr not working
by Natxo Asenjo 04 Dec '18

04 Dec '18

hi, I am testing smartcard authentication with a yubikey neo like described in https://frasertweedale.github.io/blog-redhat/posts/2016-08-12-yubikey-sc-lo… I successfully generated a key using the yubico-piv-tool, and with that a csr. yubico-piv-tool -a verify-pin -a request-certificate -s 9e -S "/CN=user50/" Enter PIN: Successfully verified PIN. -----BEGIN CERTIFICATE REQUEST----- MIICVjCCAT4CAQAwETEPMA0GA1UEAwwGdXNlcjUwMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAkWjUxl0qInlYB4TiZ7GkJkgBdomTTzk5GfK76ZizbsGV 4xyPmUgf+7eEO3GEvkGiBPJxk0NVJuamuEJTIXtn7h7Wgz6ghCE0uCCupjAJqa57 Hdm3h3GvofwWuE442YIRHvXydaSkrCAGsL/M3g4tVi7Xn+jTaWrzKsAeqJxQVRPD h4R9bN4BIzXL+62qGI9jriM8dJEWCrGFzg6viCujRlybkhQhiLxCGvS8lO3HQ7tF lDRZN6Ey/nvFxIC1MtGZgrN3nj/Z37nIBWF4s20CcJau8mfalJQEFjqLkjMh7X8K hWKrSdNj43nBTlO0So3qezs4roLkZFSN1hQnCG/pCQIDAQABoAAwDQYJKoZIhvcN AQELBQADggEBAH22PLW7Tuc6y5VxIpnaqdsborbp+Twr/kPoDnibJPjV8JBYqC4G iQCHDJn+uuJSpiBxTUtYX45CscOiwD8kiDoYIH/DCXUqPAhRudsBpJWDn9TKeFC5 b0PrwuN5cDo+yKYZW590eLL8/xdjtb9p/M3AU5tSJTbG3dCA5Rp4MdgE97pOYkPg 3kUHR19YjH/GnZHeuv8Af+WIJVMvDVGKF+MvJEImSjg/ZQUV6hzBI+oAWr9Hj21q KABjiO5AhMyo+uC6WXajkltzUP30cbBlNl0Z34Dw452Ym5uILWAF+ZmlT0sp0Mg4 lwNPSwst5mhUtQL7AmNHYHg7cAAgXx9Xql0= -----END CERTIFICATE REQUEST----- Successfully generated a certificate request. With this csr I try generating a certificate but it fails: $ ipa cert-request user50.csr --principal user50 --raw ipa: ERROR: Request failed with status 500: Non-2xx response from CA REST API: 500. Invalid Request In the pki logs I only see this error. 192.168.5.10 - ipara [08/Nov/2018:22:37:12 +0100] "GET /ca/rest/authorities/edb13864-3c75-4c7d-b5b8-dd4322789437/cert HTTP/1.1" 200 920 192.168.5.10 - ipara [08/Nov/2018:22:37:12 +0100] "GET /ca/rest/account/logout HTTP/1.1" 204 - 192.168.5.10 - - [08/Nov/2018:22:37:13 +0100] "POST /ca/rest/certrequests?issuer-id=edb13864-3c75-4c7d-b5b8-dd4322789437 HTTP/1.1" 500 123 Any ideas as to what is going wrong? Thanks! -- Groeten, natxo

3 5

Manage public DNS using FreeIPA, when FreeIPA is on internal network/IPs?
by Jonathan Vaughn 30 Nov '18

30 Nov '18

If I set up FreeIPA on 10.x.x.x internal IP, and have it manage company.net, it seems to want to set the NS record to it's FQDN that only will be reachable internally. The internal IP is SNAT mapped to an external IP (vs using DMZ), so DNS requests can reach the server via the external IP. Other than assigning a public IP to FreeIPA server instead (and placing that IP in DMZ vs how our firewall/router is currently set up with SNAT), is there a way to serve public zones managed by FreeIPA functionally ? Is it safe to just edit the NS/A records such that they're using externally resolvable addresses? Or will that break something?

4 11

Problem with dnskeysincd
by Aljaž Srebrnič 30 Nov '18

30 Nov '18

Hello everyone! So, this probably originated with me experimenting with DNSSEC. Things didn’t really work out, so I disabled it following these instructions [1]. Now every couple of minutes I see in my logs ipa-dnskeysync-replica crash on both replicas: replica1: > ipa-dnskeysync-replica: DEBUG Got TGT > ipa-dnskeysync-replica: DEBUG Connecting to LDAP > ipa-dnskeysync-replica: DEBUG Connected > ipapython.ipaldap: DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-HQ-MITTELAB-ORG.socket conn=<ldap.ldapobject.SimpleLDAPObject object at 0x7fe957f6e8d0> > ipa-dnskeysync-replica: DEBUG master keys in local HSM: {’<hex code 1>'} > ipa-dnskeysync-replica: DEBUG master keys in LDAP HSM: {’<hex code 2>', '<hex code 1>'} > ipa-dnskeysync-replica: DEBUG new master keys in LDAP HSM: {'<hex code 2>'} > Traceback (most recent call last): > File "/usr/libexec/ipa/ipa-dnskeysync-replica", line 181, in <module> > ldap2replica_master_keys_sync(ldapkeydb, localhsm) > File "/usr/libexec/ipa/ipa-dnskeysync-replica", line 90, in ldap2replica_master_keys_sync > "for master key 0x%s" % str_hexlify(mkey_id) > ValueError: Local HSM does not contain suitable unwrapping key for master key <hex code 1> Replica2: > ipa-dnskeysync-replica: DEBUG Got TGT > ipa-dnskeysync-replica: DEBUG Connecting to LDAP > ipa-dnskeysync-replica: DEBUG Connected > ipapython.ipaldap: DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-HQ-MITTELAB-ORG.socket conn=<ldap.ldapobject.SimpleLDAPObject object at 0x7f7f3bc2f860> > ipa-dnskeysync-replica: DEBUG master keys in local HSM: {’<hex code 2>'} > ipa-dnskeysync-replica: DEBUG master keys in LDAP HSM: {'<hex code 1>', '<hex code 2>'} > ipa-dnskeysync-replica: DEBUG new master keys in LDAP HSM: {'<hex code 1>'} > Traceback (most recent call last): > File "/usr/libexec/ipa/ipa-dnskeysync-replica", line 181, in <module> > ldap2replica_master_keys_sync(ldapkeydb, localhsm) > File "/usr/libexec/ipa/ipa-dnskeysync-replica", line 78, in ldap2replica_master_keys_sync > str_hexlify(mkey_id) > ValueError: Master key <hex code 1> in LDAP is missing key material referenced by ipaSecretKeyRefObject attribute Is this a leftover from the DNSSEC configuration? Can I clean that out? Thanks, Aljaž [1]: https://www.freeipa.org/page/Howto/DNSSEC#Disable_current_DNSSEC_key_master -- Aljaž Srebrnič a.k.a g5pw My public key: https://g5pw.me/key Key fingerprint = 2109 8131 60CA 01AF 75EC 01BF E140 E1EE A54E E677

1 0

Changing allow-recursion in named.conf - issues / gotchas ?
by Jonathan Vaughn 29 Nov '18

29 Nov '18

We have a use case for letting the FreeIPA named instances handle public DNS for some zones, but we don't want them to allow anyone to use it as a recursive resolver (DOS attacks and such). I tested simply changing 'any' to 'none' for the allow-recursion setting in /etc/named.conf and that worked as expected - the next step being to actually set it like we have our existing non-IPA servers configured to allow only internal/known public subnets to perform recrusion, which I expect will work as well (using a named ACL instead of none/any). Is there a nice UI way (or command line) to change the allow-recursion setting in way that is more in line with the usual management of settings for FreeIPA, and would ensure it wouldn't get overwritten at some point by FreeIPA? Is that even a concern, or should we expect that /etc/named.conf is going to be safe from changes due to anything like adding/removing replicas and so on (looks like that may all be in LDAP)?

1 1

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users November 2018