Aaaaaaand more problems... Welcome to the continuing saga of FILER. It appears that neither SOA or NS records were updated during the process of moving fsmo roles to CBADC01. SOA entries on all three active DCs point to FILER. There aren't any NS records for any of the new DCs, only FILER. In RSAT each DNS server's properties show filer.cb.cliffbells.com is the primary server. This looks at awful lot like this to me: https://lists.samba.org/archive/samba/2015-October/195352.html This process is killing me. I assume this misconfiguration is in large part responsible for authentication and share access issues I'm now experiencing (I sent a reply to my last thread on failing to join DCs to the domain but received no replies). I'm of the opinion mentioning this potential failure along with the procedure to mitigate the issue would be useful on the wiki page detailing transfer/seize fsmo roles... If I read things right if the original fsmo role holder has been demoted prior to identifying the failure samba-tool won't be able to query the original DC and manual intervention will be required? Please advise. This client is about ready to throw me off the roof and abandon the system for quill and ink by candle light. I'm considering just going with it. JS
On 3/31/2016 3:12 PM, IT Admin wrote:> Aaaaaaand more problems... Welcome to the continuing saga of FILER. > > It appears that neither SOA or NS records were updated during the process > of moving fsmo roles to CBADC01. SOA entries on all three active DCs point > to FILER. There aren't any NS records for any of the new DCs, only FILER. > In RSAT each DNS server's properties show filer.cb.cliffbells.com is the > primary server. This looks at awful lot like this to me: > https://lists.samba.org/archive/samba/2015-October/195352.html > > This process is killing me. > > I assume this misconfiguration is in large part responsible for > authentication and share access issues I'm now experiencing (I sent a reply > to my last thread on failing to join DCs to the domain but received no > replies). I'm of the opinion mentioning this potential failure along with > the procedure to mitigate the issue would be useful on the wiki page > detailing transfer/seize fsmo roles... If I read things right if the > original fsmo role holder has been demoted prior to identifying the failure > samba-tool won't be able to query the original DC and manual intervention > will be required? > > Please advise. This client is about ready to throw me off the roof and > abandon the system for quill and ink by candle light. I'm considering just > going with it. > > JSIt's been sometime since I had to seize roles, but when I did I had to recreate the SOA and NS record. Have you attempted to create the SOA and or NS record? -- -James
On 3/31/2016 3:12 PM, IT Admin wrote:> Aaaaaaand more problems... Welcome to the continuing saga of FILER. > > It appears that neither SOA or NS records were updated during the process > of moving fsmo roles to CBADC01. SOA entries on all three active DCs point > to FILER. There aren't any NS records for any of the new DCs, only FILER. > In RSAT each DNS server's properties show filer.cb.cliffbells.com is the > primary server. This looks at awful lot like this to me: > https://lists.samba.org/archive/samba/2015-October/195352.html > > This process is killing me. > > I assume this misconfiguration is in large part responsible for > authentication and share access issues I'm now experiencing (I sent a reply > to my last thread on failing to join DCs to the domain but received no > replies). I'm of the opinion mentioning this potential failure along with > the procedure to mitigate the issue would be useful on the wiki page > detailing transfer/seize fsmo roles... If I read things right if the > original fsmo role holder has been demoted prior to identifying the failure > samba-tool won't be able to query the original DC and manual intervention > will be required? > > Please advise. This client is about ready to throw me off the roof and > abandon the system for quill and ink by candle light. I'm considering just > going with it. > > JSI should mention the syntax to update the SOA if you do not know. I did this back in the Samba 4.0 days. Not sure if things have changed. samba-tool dns update SOA "fqdn_dns fqdn_email serial refresh retry expire minimumttl" -- -James
SOA means "this DNS se'rver can modify the zone". Using Bind-DLZ all DNS servers can modify the AD zones, they all reply "I am the SOA" when you ask them about SOA for AD zones. Using Internal DNS I expect all DNS servers can modify the AD zones also (that's internal stuff) but even if they can modify the AD zone locally that's is not the process chosen by Samba Team. Samba Internal DNS relies on DB content to reply to SOA query and there is only one SOA in the DB. So with internal DNS you will have always only one SOA. This is an issue because if your SOA is down and some DC has DNS updates to send, updates will fail because no SOA available. And when seizing roles because you are about to remove old FSMO, that's the same: once the FSMO is removed no more SOA to apply DNS updates on. For me, I can be wrong, this behaviour comes from the fact Samba uses "nsupdate" command to push DNS updates. nsupdate comes from Bind tools suite, as it is bind tool it follows the protocol. And the protocol says "updates can be pushed only on SOA". So nsupdate first ask the zone to be modified what is the SOA to push updates on that server. IMHO this should be managed by Samba itself rather than relying on Samba admins DNS knowledge. Samba Internal DNS should be able to push update locally and Samba internal DNS should answer "I am SOA" as they can push DNS updates locally (they have access to the DB, they can push updates, even if this needs to write some code). Or samba_dnsupdate should not use by default nsupdate from bind tools when using internal DNS but rather use "samba-tool dns ..." which pushes updates locally. 2016-04-01 19:26 GMT+02:00 lingpanda101 at gmail.com <lingpanda101 at gmail.com>:> On 3/31/2016 3:12 PM, IT Admin wrote: > >> Aaaaaaand more problems... Welcome to the continuing saga of FILER. >> >> It appears that neither SOA or NS records were updated during the process >> of moving fsmo roles to CBADC01. SOA entries on all three active DCs >> point >> to FILER. There aren't any NS records for any of the new DCs, only FILER. >> In RSAT each DNS server's properties show filer.cb.cliffbells.com is the >> primary server. This looks at awful lot like this to me: >> https://lists.samba.org/archive/samba/2015-October/195352.html >> >> This process is killing me. >> >> I assume this misconfiguration is in large part responsible for >> authentication and share access issues I'm now experiencing (I sent a >> reply >> to my last thread on failing to join DCs to the domain but received no >> replies). I'm of the opinion mentioning this potential failure along with >> the procedure to mitigate the issue would be useful on the wiki page >> detailing transfer/seize fsmo roles... If I read things right if the >> original fsmo role holder has been demoted prior to identifying the >> failure >> samba-tool won't be able to query the original DC and manual intervention >> will be required? >> >> Please advise. This client is about ready to throw me off the roof and >> abandon the system for quill and ink by candle light. I'm considering >> just >> going with it. >> >> JS >> > I should mention the syntax to update the SOA if you do not know. I did > this back in the Samba 4.0 days. Not sure if things have changed. > > samba-tool dns update SOA "fqdn_dns fqdn_email serial refresh retry expire > minimumttl" > > > > > -- > -James > > > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >