This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(176, 72%, 27%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAS%3C/text%3E%3C/svg%3E)
Hi everyone! It's a pleasure to write one more time, after many years.
We have come across a problem regarding DCHP & DNS Dynamic Update. I'm postig here, because we think the solution relies on Active Directory Group Nesting.
Here is the thing: Our Forest has 3 domains: A, B, C. Every Domain has a two-way trust relationship with the others. Domain A has DHCP A, Domain B has DHCP B and Domain C has DHCP C.
After solving some problems with DNS Aging and Scavenging in Domain A (our principal Site), we need DHCP B and C to have the requiered permissions to make Dynamic Updates in DNSs zones of Domain A. So we created a service account DomainB\dhcp_service and DomainC\dhcp_service & configured DNS Dynamic update to happen always from the DHCP Server, not the client. So we need the service accounts DomainC\dhcp_service and DomainB\dhcp_service to be members of DomainA\DnsUpdateProxy, but this group has a scope of Global.
I can't find the nesting strategy to have those users as member of this group. Not with Global Scope. Is it possible to change-it to Universal and then to Domain Local to be able to add users from another domain? I don't know if theese built-in things are made to be changeable. I don't want to have problems running further active directory updates or extensions or functional levels...
Maybe there are another way to solve this and we are trying to solve this in a dirty or wrong way. But i cannot think of another way...
Any help will be appreciated.
Regards,
A.
But normally, the client should be able to register it's own records in the DNS, why do you need to force the DHCP to register on behalf of the client computer ?
And what is the issue you had with the aging / scavenging in domain A ?
Hi @cthivierge ,
You are right. Normally client should be able to register it's own records in the DNS. But the thing is that there was a big delay with user's notebooks when they change from one site to another. Plus, some users always shutdown the laptps, others just suspend it or put it in hybernation.
Our solution for Internet Access, Fortinet SSO Agent, relies heavily in DNS resolution. These updates, when done by clients, start to take some time to happen, so in the meantime, users where unable to connect to Internet when moving. It is for this reason that we were looking for a way to make the update to happen more quickly. The issue whith the ACLs and what account owns the record was the reason that leads us to the docs referenced above.
Any thoughs on this?
Regards,
A.
So we need the service accounts DomainC\dhcp_service and DomainB\dhcp_service to be members of DomainA\DnsUpdateProxy
Isn't the solution to use the same account on all DHCP servers? Then there are no permissions issues.
Hi @Pierre Audonnet - MSFT . No is not. Here is why:
If we configure DHCP B, to make dynamic updates as DomainA\dhcp_service, then we need to make DomainA\dhcp_service member of DomainB\DnsUpdateProxy in orden to update DomainB DNSs Zones. And this is the same problem. DomainB\DnsUpdateProxy is a Global Group and cannot have user accounts from other domains.
So... we need to solve the same problem again, but from DomainB perspective.
Regards,
A.
Incorrect, the DnsUpdateProxy group isn't designed for this purpose (anymore). Back in Windows 2000 Server era, we couldn't use a service account for DNS dynamic updates on a DHCP server. The option just wasn't there. So when two different DHCP servers were serving the same scope of machines, if one server was owning one record the second couldn't update it as it didn't have the ownership. To solve that issue, the DNSUpdateProxy group was introduced. The workaround was then to put the computer accounts of the DHCP servers into that group and all records created by the account member of that group would be unprotected. That way, the next account doing the update would own the record. Allowing a machine to take control back. And if the next account doing an update was also member of the group, then the record would stay unprotected.
But essentially this introduces a situation where all records created by the DHCP servers were unprotected (as if the zone was allowing unsecure dynamic updates). So starting Windows Server 2003, the DHCP server gained the possibility to set a service account for dynamic updates. This way, no need to use the DNSUpdateProxy group, but instead we set the same account on all DHCP server. Even if another DHCP server was trying to modify a records, it would look like the same account from an authorization perspective.
You do not need to be a member of this group to create and modify records. Any user account in AD can create DNS record. This group was really just a way to circumvent the fact we couldn't use a service account back in Windows 2000 Server days.
And as long as the domains are trusted, you can use the same account. You might need to do some re-ACLing just for the transition, to make sure the one and only new dedicated account has the proper permissions to control what already exists, but that's a one time operation.
And DNSUpdateProxy group is not a built-in group. It has a Relative Identifier (RID) > 1000.
Built-in groups have RID < 1000 as their scope is only the system where the group exists (so only the DCs in the case of AD built-in groups - and those SID are filtered out).
Built-in groups scopes cannot be changed.
You are correct, the DNSUpdateProxy group is not a built-in group because of the SID which is higher than 1000.
Also, as you mentioned, it's impossible to change the group type of a Built-in group. All buttons are greyed-out compare to a standard group (like the DNSUpdateProxy) where it's possible to change the type.
But this documentation mention the opposite about the DNSUpdateProxyGroup. The link mentioned Windows 2003 but on the top of the page it also apply to Windows 2012 R2 / 2016 / 2019
https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-dns-dynamic-updates-windows-server-2003#use-the-dnsupdateproxy-security-group
"To solve this problem, a built-in security group named DnsUpdateProxy is provided..."
I think an update of this document should be done to clarify is the DNSUpdateProxy group is a Built-in group or not.
Fair point. I guess they used it as a colloquial term in that, it comes with the service, you don't need to create it hence "built-in". This article was a bit confusing about that too: https://learn.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups but was corrected since. The idea that "a default group" was a "built-in group". Which still isn't true for the DNSUpdateProxy group as it gets created only if you have installed a DNS service on a domain controller. The type of group is a technicality (although it is crucial since built-in groups get filtered by the SID filtering process). It is not a built-in group in a technical sense of it. The point is that the proper way to manage DNS dynamic updates from a DHCP server is to configure a common service account.
Note that this article doesn't contradict the aforementionned explanation though. It actually says it:
Also, objects that are created by the members of the DnsUpdateProxy group are not secure.
At best the following phrasing is ambiguous:
To help protect against nonsecure records or to enable members of the DnsUpdateProxy group to register records in zones that enable only secured dynamic updates
But it doens't contradict the previous statement either. It is a bit weird I would agree that the article mentions "or to enable members of the DnsUpdateProxy group" whereas the steps that follow are not doing anything connected to that:
Create a dedicated user account.
Configure DHCP servers to perform DNS dynamic updates with the user account credentials. (These credentials are the user name, the password, and the domain.)
This part has nothing to do with the DnsUpdateProxy group at all. But even if you follow them, you don't end up with the service accounts in that group. I guess the KB could use some polish, but the steps are still technically correct. Note that you can still see the old version here: https://web.archive.org/web/20041211045707/http://support.microsoft.com/kb/317590/EN-US/
Hi guys. Thanks for all your answers. This is scalating quickly. Too many knowledge and AD Magic over here .
So, you are rigth! DnsProxyUpdate is not a built-in group. I totally forget about the <1000 SIDs. Besides, this DnsProxyUpdate is in Users container, not the built-in. I should have noted this.
I think the confusion comes from the article mentioned above. We are currently facing problems with ACLs of DNS. This is the issue and the reason for which we were thinking about add dhcp_service accounts to this group: the fact that records added by members of this groups are not secured.
In adition to Windows DHCPs servers, there are others DHCPs: Some OpenVPNs Servers and some Fortinet VPN SSL VPNs. So clients can receive DHCP address from the site (when they are there), from another site (whenthey travel to other site) and from VPNs (Fortinet or OpenVPN). So, when clients are connected to VPN, we cannot rely on Dynamic Updates. Here is why in this situation, we need the client to be able to register DNS even if the dhcp_service owns the record.
We will continue to work on this and will provide feedback with results!
Hi @Andres Soncini ,
I don't a have an environment to confirm this but changing the scope of the group shouldn't impact the DNS update process, and as the group already exists in the domain, future updates are unlikely to be impacted, but as always, you can't 100% sure.
To confirm this, if you look at the permissions of a record that has been added by the DHCP service account, the account is probably the owner of the record and the DNSUpdateProxy group should also have been assigned permissions on the record. As the permissions are assigned based on the group SID, changing the group scope should not impact the permissions assigned.
Another option if you don't want to change the group scope, is change the delegated permissions on the DNS zones and add a domain local group that has permissions to add\delete and update DNS records and add the DHCP service accounts to that group. The only down side to this approach is that the group will have permissions to update all the records in the domain, including DC records.
Gary.
Hi @GaryReynolds-8098. Thanks for your answer. I think that one downside to this approach is also that i have multiple reverse zones in DNSs. So thoose manual delegated permissions needs to be maintained there too. I know that changing the group scope does not alter ACEs in ACLs, but i am not sure if doing this can lead to some error when upgrading functional levels, extending schemma or some other AD Operations. Hence the question.