I have this problem from time to time and had just assumed it was
something relating to my setup. Yesterday it happened but found the '0
master zones' line that I hadn't noticed before. Digging on that I
found this thread from 2016:
https://www.redhat.com/archives/freeipa-users/2016-November/msg00114.html
Indeed, in mine, and it appears in your output of 'ipa privilege-show
'DNS Servers' --all --raw' that your host does not show up. I haven't
dug deeply yet but I do not know why those credentials disappeared.
You should just be able to re-add them from any of your servers and it
should all come back to life (I don't recall if I restarted named or
not after, but that's trivial).
ipa privilege-mod 'DNS Servers'
--addattr=member=krbprincipalname=DNS/ipa-001.example.net(a)EXAMPLE.NET,cn=services,cn=accounts,dc=example,dc=net
ipa privilege-mod 'DNS Servers'
--addattr=member=krbprincipalname=ipa-dnskeysyncd/ipa-001.example.net(a)EXAMPLE.NET,cn=services,cn=accounts,dc=example,dc=net
(of course, change back to your domain name)
--
John Duino
jduino(a)oblong.com
On Wed, May 2, 2018 at 8:26 AM, Rob Crittenden via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org> wrote:
> Matt Ungaro wrote:
>>
>> Thank you for the quick reply, Rob. I'm assuming this entry right here is
>> the one you're looking at:
>>
>> # servers + 79ae4ffe-6b7211e7-9fb996c1-641091b3, dns,
example.net
>> <
http://example.net>
>> dn:
>> cn=servers+nsuniqueid=79ae4ffe-6b7211e7-9fb996c1-641091b3,cn=dns,dc=example
>> ,dc=net
>> cn: servers
>> objectClass: nsContainer
>> objectClass: top
>>
>> Any pointers on how to resolve that replication conflict? I've read
>> documents that point towards deleting that entry, but to be honest feeling a
>> little wary of deleting anything out of LDAP.
>
>
> I think in this case deleting it is the right thing to do.
>
> rob
>
>>
>> On Wed, May 2, 2018 at 8:09 AM Rob Crittenden <rcritten(a)redhat.com
>> <mailto:rcritten@redhat.com>> wrote:
>>
>> Matt Ungaro via FreeIPA-users wrote:
>> > Hello there,
>> >
>> > Having an issue with named on one of our IPA servers. Our IPA
>> server
>> > gets the following messages in named.run when it starts:
>> > 0 master zones from LDAP instance 'ipa' loaded (0 zones
defined, 0
>> > inactive, 0 failed to load)
>> > 0 master zones is suspicious number, please check access control
>> > instructions on LDAP server
>> >
>> >
>> > We have been rolling through and upgrading our IPA
>> infrastructure, and
>> > it looks like DNS privileges were lost for this host during the
>> upgrade,
>> > and the issue was exposed on a restart of named. We're looking to
>> get
>> > this server back into the proper pbac group so that it can read in
>> > authoritative zones. Any assistance is greatly appreciated!
>> >
>> >
>> > Host information:
>> > Upgraded from 4.2.0-15 to 4.5.0-22
>> > OS Version: CentOS 7.2.1511
>> >
>> >
>> > Issue description:
>> >
>> > named starts, but cannot get authoritative zones from LDAP.
>> Kerberos
>> > authentication is functioning (Tested using the named.keytab and
>> > ldapsearch as shown below), but the host does not have DNS Server
>> > privileges. Followed troubleshooting steps located at:
>> >
https://docs.pagure.org/bind-dyndb-ldap/BIND9/NamedCannotStart.html
>> >
>> > Domain name has been scrubbed, but host names are intact. I
>> assure you,
>> > we are not
example.net <
http://example.net>
<
http://example.net>.
>> :)
>> >
>> > In any of this output we are looking for
ipa-002.example.net
>> <
http://ipa-002.example.net>
>> > <
http://ipa-002.example.net>.
>> >
>> > From the non-functioning host (FreeIPA version 4.5):
>> >
>> > > kinit -kt /etc/named.keytab
DNS/ipa-002.example.net
>> <
http://ipa-002.example.net>
>> > <
http://ipa-002.example.net>
>> > > ldapsearch -H
>> 'ldapi://%2fvar%2frun%2fslapd-EXAMPLE-NET.socket' -Y
>> > GSSAPI -b 'cn=dns,dc=example,dc=net'
>> > SASL/GSSAPI authentication started
>> > SASL username: DNS/ipa-002.example.net(a)EXAMPLE.NET
>> <mailto:ipa-002.example.net@EXAMPLE.NET>
>> > <mailto:ipa-002.example.net@EXAMPLE.NET
>> <mailto:ipa-002.example.net@EXAMPLE.NET>>
>> > SASL SSF: 56
>> > SASL data security layer installed.
>> > # extended LDIF
>> > #
>> > # LDAPv3
>> > # base <cn=dns,dc=example,dc=net> with scope subtree
>> > # filter: (objectclass=*)
>> > # requesting: ALL
>> > #
>> >
>> > # dns,
example.net <
http://example.net>
<
http://example.net>
>> > dn: cn=dns,dc=example,dc=net
>> > cn: dns
>> > objectClass: idnsConfigObject
>> > objectClass: nsContainer
>> > objectClass: ipaConfigObject
>> > objectClass: top
>> > objectClass: ipadnscontainer
>> >
>> > # sec, dns,
example.net <
http://example.net>
<
http://example.net>
>> > dn: cn=sec,cn=dns,dc=example,dc=net
>> > cn: sec
>> > objectClass: nsContainer
>> > objectClass: top
>> >
>> > # keys, sec, dns,
example.net <
http://example.net>
>> <
http://example.net>
>> > dn: cn=keys,cn=sec,cn=dns,dc=example,dc=net
>> > cn: keys
>> > objectClass: nsContainer
>> > objectClass: top
>> >
>> > # servers, dns,
example.net <
http://example.net>
>> <
http://example.net>
>> > dn: cn=servers,cn=dns,dc=example,dc=net
>> > cn: servers
>> > objectClass: nsContainer
>> > objectClass: top
>> >
>> > # servers + 79ae4ffe-6b7211e7-9fb996c1-641091b3, dns,
example.net
>> <
http://example.net>
>> > <
http://example.net>
>> > dn:
>> >
>>
>> cn=servers+nsuniqueid=79ae4ffe-6b7211e7-9fb996c1-641091b3,cn=dns,dc=example
>> > ,dc=net
>> > cn: servers
>> > objectClass: nsContainer
>> > objectClass: top
>>
>> Try resolving this replication conflict entry and that may help.
>>
>> rob
>>
>> --
>> Matt Ungaro (mungaro(a)armsbusinesssolutions.com
>> <mailto:mungaro@armsbusinesssolutions.com>)
>> Phone: 608-616-5367
>> Engineer 3
>> ARMS Business Solutions
>>
>> IMPORTANT: This e-mail (including any attachments) is intended for the use
>> of the individual or entity to which it is addressed and may contain
>> information that is classified, private, or confidential. If the reader of
>> this message is not the intended recipient, or the employee or agent
>> responsible for delivering the message to the intended recipient, you are
>> hereby notified that any dissemination, distribution, or copying of this
>> communication is prohibited. If you have received this communication in
>> error, please notify us immediately by replying to this e-mail. Thank you.
>>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org