[Samba] AD, multiple DC, some DC without DNS at all

Thu Mar 3 17:22:44 UTC 2016

2016-03-03 10:52 GMT+01:00 Rowland penny <rpenny at samba.org>:

> On 03/03/16 09:31, mathias dufresne wrote:
>
>> Hi all,
>>
>> Thank you Mark for these precisions.
>>
>> I did switch a DC to --dns-backend=NONE using samba-tool domain join. This
>> removed dns-<DCname> user for this DC and associated keytab.
>>
>> We changed /etc/resolv.conf to use another DC - one with Bind running - as
>> nameserver.
>>
>> Stopping there, running samba_dnsupdate gave error "NOTAUTH".
>>
>> As we want our DC being able to push into DNS database some changes (when
>> we move our DC from Site to Site at least) I tried to find out what is
>> needed to replace that user in a way this user can be used by several DC
>> to
>> modify AD DNS database.
>>
>> What was done to get nsupdate -g working from non-DNS-DC pushing
>> modification to bind-dlz-DC:
>> - copy of private/dns.keytab from bind-dlz-DC to non-DNS-DC
>> - generate a Kerberos ticket for user account dns-<bind-dlz-DC>
>> - run samba_dnsupdate
>> If I remember correctlly error was "NOTAUTH" too.
>>
>> - add SPN to user account dns-<bind-dlz-DC>, new SPN added were:
>> + DNS/<non-DNS-DC>.ad.domain.tld
>> + DNS/<non-DNS-DC>.ad.domain.tld at AD.DOMAIN.TLD
>>
>> - add dns-<bind-dlz-DC> user account into dnsAdmins built-in group
>>
>> Now I am able to modify AD DNS zone AD.DOMAIN.TLD using temporary files
>> generated by samba_dnsupdate (samba_dnsupdate was modified around line 408
>> to comment tmp file deletion, the unlink() function).
>> Trying to modify _msdcs.AD.DOMAIN.TLD is not working, I get error: "update
>> failed: REFUSED".
>>
>> Trying to push modification using nsupdate -g is working on both AD zones
>> when the Kerberos ticket for my session is a ticket belonging to
>> "administrator" account.
>>
>> In résumé nsupdate -g works pushing modification from non-DNS-DC to
>> bind-dlz-DC:
>> with Administrator kerberos ticket: on both DNS zones ad.domain.tld and
>> _msdcs.ad.domain.tld
>> with dns-<bind-dlz-DC> Kerberos ticket: only on DNS zone ad.domain.tl;
>> _msdcs.ad.domain.tld modification gives "update failed: REFUSED".
>>
>> So I miss something to be able to use non-administrator account to modify
>> _msdcs DNS zone. Any idea would be welcomed.
>>
>> Best regards,
>>
>> mathias
>>
>>
>>
>> 2016-03-01 20:02 GMT+01:00 Marc Muehlfeld <mmuehlfeld at samba.org>:
>>
>> Hello Mathias,
>>>
>>> Am 01.03.2016 um 11:59 schrieb mathias dufresne:
>>>
>>>> I thought there was an option for samba_dnsupgrade command to tell
>>>>
>>> "remove
>>>
>>>> all DNS service from current DC" but I don't find it anymore.
>>>>
>>> I think there's no such option (yet), but would be worth a feature
>>> request. :-)
>>>
>>>
>>>
>>>
>>> This question is because we are about to deploy an AD with 20 or more DC
>>>> and there is no need they are all DNS servers. In fact having them all
>>>>
>>> DNS
>>>
>>>> servers make design more complex and more risky. The point is to avoid
>>>> risks.
>>>>
>>> You should deploy these DCs without DNS (--dns-backend=NONE), because
>>> then they don't get
>>>    DC=ForestDnsZones,DC=samdom,DC=example,DC=com
>>>    DC=DomainDnsZones,DC=samdom,DC=example,DC=com
>>> replicated at all.
>>>
>>>
>>>
>>>
>>> How I would proceed if samba_dnsupgrade is not able to remove DNS service
>>>> automatically:
>>>> - as for BIND9_DLZ backend, I will keep into smb.conf the "-dns" for
>>>> runninf services.
>>>> - stop Bind-DLZ service on non-DNS-DC
>>>> - modify /etc/resolv.conf on non-DNS-DC for they send DNS request to
>>>> remaining DNS servers.
>>>>
>>> I think this should work, beside that those DCs still get the DNS stuff
>>> replicated.
>>>
>>> You can also switch to the internal DNS. If the IP of those DCs is not
>>> used by clients in their DNS configuration, the DNS won't be used. And
>>> if, then nothing bad should happen. :-)
>>>
>>>
>>>
>>> Regards,
>>> Marc
>>>
>>>
> It may be because you are trying to run samba_dnsupdate instead of running
> nsupdate directly.
> I run Samba AD DC, Bind9 and DHCP on the same machine, DHCP gives out an
> ipaddress, then runs a script to update Bind9. This script runs nsupdate to
> update the records in AD. All that is required is a user (with password set
> to never expire), this user should be a member of DnsAdmins, you also need
> the users keytab.
>
> Let me know if you need more info.
>
> Rowland
>
>
I'll be long but the subject seems to be fully explained (this task is
quiet complex).

As explained in my previous mails I am using nsupdate -g manually with file
generated by samba_dnsupdate. These files do have the right syntax as
samba_dnsupdate works when updating local Bind-dlz DNS server.

The question is how to update a REMOTE DNS server, running on another DC.

The goal is to remove DNS service from most of my DC as they don't need it.
They need a working (always working) DNS infrastructure with AD zones but
there is no need to have DNS service on all DC.

Another point is to understand how work these updates, what is needed into
AD (ACLs, servicePrincipalName in accounts, keytabs and which principals in
these keytabs....) to make them work and to repair AD in case it is needed.

-----------------------------

Where was I?
dc200 = SOA and FSMO owner, DNS is running on that system.
dc206 = no FSMO, no DNS running.

The goal: samba_dnsupdate runs without error on dc206, pushing updates to
dc200.

The way to try without running samba_dnsupdate:
on dc206: modify samba_dnsupdate for it does not remove temporary files,
use these temporary files directly with nsupdate. This way we chose which
update we try, there is only one update pushed, log are fewer to check.
on dc200: bind-dlz is running with -d9 to increase logs generated.

nsupdate command:
nsupdate -dD -g /tmp/tmpAb12bla

-d more logs
-D again more logs

In my last mail I explained nsupdate -g works fine on AD.DOMAIN.TLD zone
but not always on _MSDCS.AD.DOMAIN.TLD.

Administrator account is able to push modification from dc200 and dc206 on
_both_ zones.
dns-dc200 account is able to push modification on root zone
(samba.domain.tld)
dns-dc200 account is NOT able to push modification on _msdcs zone
(_msdcs.samba.domain.tld). The error is the modification is refused.

Here is an extract from nsupdate logs:
------------------------------------------------------------------------------------
send_update()
Sending update to 10.156.32.100#53
show_message()
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  21380
;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1
;; UPDATE SECTION:
_kerberos._tcp.Authentification._sites.dc._msdcs.ad.dgfip.finances.gouv.fr.
900 IN SRV 0 100 88 dc206.ad.dgfip.finances.gouv.fr.

;; TSIG PSEUDOSECTION:
4258363295.sig-dc200.ad.dgfip.finances.gouv.fr. 0 ANY TSIG gss-tsig.
1457025027 300 28 BAQE//////8AAAAADIjBZjLMlf0Ye0gbH/nzNg== 21380 NOERROR 0

Out of recvgss
update_completed()
tsig verification successful
show_message()

Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, *status: REFUSED*, id:  21380
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; ZONE SECTION:
;_msdcs.ad.dgfip.finances.gouv.fr. IN   SOA
------------------------------------------------------------------------------------

After digging a bit further I found dnsAdmins is not the group I'm
seeking: *dnsAdmins
as no right on _msdcs zone.*

Knowing that, two options: give more rights to dnsAdmins group or create
another. Modifying builtin group rights seems to me a bad idea: builtin are
meant to have default behaviour (in my mind).

I created another group (bind-dlz_admins) and modify its rights on _msdcs
zone using MS DNS console + right click on _msdcs zone + properties +
security tab + add this newly created group + modify the rights of that
group (security tab + advanced tabs).

After adding dns-dc200 to bind-dlz_admins group I was able to modify _msdcs
zone using dns-dc200, but only from dc200, not yet from dc206 where I'm
still receiving a refusal when modifying _msdcs zone.

I suspect an issue in my keytab and servicePrincipalName declared into
dns-dc200 account: the keytab does not yet contain service principal names
for dc206.

Next step I hope tomorrow.

Best regards,

mathias