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. :)
In any of this output we are looking for ipa-002.example.net.
From the non-functioning host (FreeIPA version 4.5):
kinit -kt /etc/named.keytab DNS/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@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 dn: cn=dns,dc=example,dc=net cn: dns objectClass: idnsConfigObject objectClass: nsContainer objectClass: ipaConfigObject objectClass: top objectClass: ipadnscontainer
# sec, dns, example.net dn: cn=sec,cn=dns,dc=example,dc=net cn: sec objectClass: nsContainer objectClass: top
# keys, sec, dns, example.net dn: cn=keys,cn=sec,cn=dns,dc=example,dc=net cn: keys objectClass: nsContainer objectClass: top
# servers, dns, 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 dn: cn=servers+nsuniqueid=79ae4ffe-6b7211e7-9fb996c1-641091b3,cn=dns,dc=example ,dc=net cn: servers objectClass: nsContainer objectClass: top
# search result search: 4 result: 0 Success
# numResponses: 6 # numEntries: 5
ipa privilege-show 'DNS Servers' --all --raw
dn: cn=DNS Servers,cn=privileges,cn=pbac,dc=example,dc=net cn: DNS Servers description: DNS Servers member: krbprincipalname=DNS/ipa-001.example.net@EXAMPLE.NET ,cn=services,cn=accounts,dc=example,dc=net member: krbprincipalname=ipa-dnskeysyncd/ipa-001.example.net@EXAMPLE.NET ,cn=services,cn=accounts,dc=example,dc=net member: krbprincipalname=DNS/eu-ipa-02.example.net@EXAMPLE.NET ,cn=services,cn=accounts,dc=example,dc=net member: krbprincipalname=ipa-dnskeysyncd/eu-ipa-02.example.net@EXAMPLE.NET ,cn=services,cn=accounts,dc=example,dc=net member: krbprincipalname=DNS/eu-ipa-01.example.net@EXAMPLE.NET ,cn=services,cn=accounts,dc=example,dc=net member: krbprincipalname=ipa-dnskeysyncd/eu-ipa-01.example.net@EXAMPLE.NET ,cn=services,cn=accounts,dc=example,dc=net member: krbprincipalname=DNS/dev-ipa-01.mgmt.example.net@EXAMPLE.NET ,cn=services,cn=accounts,dc=example,dc=net member: krbprincipalname=ipa-dnskeysyncd/ dev-ipa-01.mgmt.example.net@EXAMPLE.NET ,cn=services,cn=accounts,dc=example,dc=net member: krbprincipalname=DNS/rslon-ipa-01.mgmt.example.net@EXAMPLE.NET ,cn=services,cn=accounts,dc=example,dc=net member: krbprincipalname=ipa-dnskeysyncd/ rslon-ipa-01.mgmt.example.net@EXAMPLE.NET ,cn=services,cn=accounts,dc=example,dc=net member: krbprincipalname=DNS/rslon-ipa-02.mgmt.example.net@EXAMPLE.NET ,cn=services,cn=accounts,dc=example,dc=net member: krbprincipalname=ipa-dnskeysyncd/ rslon-ipa-02.mgmt.example.net@EXAMPLE.NET ,cn=services,cn=accounts,dc=example,dc=net member: krbprincipalname=DNS/rsiad-ipa-02.mgmt.example.net@EXAMPLE.NET ,cn=services,cn=accounts,dc=example,dc=net member: krbprincipalname=ipa-dnskeysyncd/ rsiad-ipa-02.mgmt.example.net@EXAMPLE.NET ,cn=services,cn=accounts,dc=example,dc=net member: krbprincipalname=DNS/rsiad-ipa-01.mgmt.example.net@EXAMPLE.NET ,cn=services,cn=accounts,dc=example,dc=net member: krbprincipalname=ipa-dnskeysyncd/ rsiad-ipa-01.mgmt.example.net@EXAMPLE.NET ,cn=services,cn=accounts,dc=example,dc=net member: krbprincipalname=DNS/rsdfw-ipa-01.mgmt.example.net@EXAMPLE.NET ,cn=services,cn=accounts,dc=example,dc=net member: krbprincipalname=ipa-dnskeysyncd/ rsdfw-ipa-01.mgmt.example.net@EXAMPLE.NET ,cn=services,cn=accounts,dc=example,dc=net member: krbprincipalname=DNS/rsdfw-ipa-02.mgmt.example.net@EXAMPLE.NET ,cn=services,cn=accounts,dc=example,dc=net member: krbprincipalname=ipa-dnskeysyncd/ rsdfw-ipa-02.mgmt.example.net@EXAMPLE.NET ,cn=services,cn=accounts,dc=example,dc=net member: krbprincipalname=DNS/prod-ipa-01.mgmt.example.net@EXAMPLE.NET ,cn=services,cn=accounts,dc=example,dc=net member: krbprincipalname=ipa-dnskeysyncd/ prod-ipa-01.mgmt.example.net@EXAMPLE.NET ,cn=services,cn=accounts,dc=example,dc=net memberof: cn=System: Read DNS Configuration,cn=permissions,cn=pbac,dc=example,dc=net memberof: cn=System: Write DNS Configuration,cn=permissions,cn=pbac,dc=example,dc=net memberof: cn=System: Add DNS Entries,cn=permissions,cn=pbac,dc=example,dc=net memberof: cn=System: Manage DNSSEC keys,cn=permissions,cn=pbac,dc=example,dc=net memberof: cn=System: Manage DNSSEC metadata,cn=permissions,cn=pbac,dc=example,dc=net memberof: cn=System: Read DNS Entries,cn=permissions,cn=pbac,dc=example,dc=net memberof: cn=System: Remove DNS Entries,cn=permissions,cn=pbac,dc=example,dc=net memberof: cn=System: Update DNS Entries,cn=permissions,cn=pbac,dc=example,dc=net memberof: cn=System: Read DNS Servers Configuration,cn=permissions,cn=pbac,dc=example,dc=net objectClass: top objectClass: groupofnames objectClass: nestedgroup
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. :)
In any of this output we are looking for 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
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@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 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 dn: cn=sec,cn=dns,dc=example,dc=net cn: sec objectClass: nsContainer objectClass: top
# keys, sec, dns, 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 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 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
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 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.
On Wed, May 2, 2018 at 8:09 AM Rob Crittenden 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. :)
In any of this output we are looking for 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
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@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 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 dn: cn=sec,cn=dns,dc=example,dc=net cn: sec objectClass: nsContainer objectClass: top
# keys, sec, dns, 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 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 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 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@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@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@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.
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@EXAMPLE.NET,cn=services,cn=accounts,dc=example,dc=net ipa privilege-mod 'DNS Servers' --addattr=member=krbprincipalname=ipa-dnskeysyncd/ipa-001.example.net@EXAMPLE.NET,cn=services,cn=accounts,dc=example,dc=net
(of course, change back to your domain name) -- John Duino jduino@oblong.com
On Wed, May 2, 2018 at 8:26 AM, Rob Crittenden via FreeIPA-users freeipa-users@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@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 IPAserver > 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@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@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@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Thank you, John! That did the trick! named properly starts and grabs all authoritative zones from LDAP now. Appreciate the assistance!
On Wed, May 2, 2018 at 3:19 PM John Duino jduino@oblong.com wrote:
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@EXAMPLE.NET ,cn=services,cn=accounts,dc=example,dc=net ipa privilege-mod 'DNS Servers' --addattr=member=krbprincipalname=ipa-dnskeysyncd/ ipa-001.example.net@EXAMPLE.NET,cn=services,cn=accounts,dc=example,dc=net
(of course, change back to your domain name)
John Duino jduino@oblong.com
On Wed, May 2, 2018 at 8:26 AM, Rob Crittenden via FreeIPA-users freeipa-users@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@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 IPAserver > 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 readin
> 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@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@armsbusinesssolutions.com mailto:mungaro@armsbusinesssolutions.com) Phone: 608-616-5367 <(608)%20616-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@lists.fedorahosted.org To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
freeipa-users@lists.fedorahosted.org
-
John Duino -
Matt Ungaro -
Rob Crittenden