This prevents the registration of nonsecure records in DNS. The same account can be used on all your DHCP servers, thus eliminating one of the earlier issues described in the section "Security Concerning the DNSUpdateProxy Group," in reference to switching to a new DHCP server after the original one has already registered client records under its ownership. Windows Server Brain Affiliate Marketing current. EasyProfiter Software. Five Minute Profit Sites.
By default, the ACL gives Create permission to all members of the Authenticated User group, the group of all authenticated computers and users in an Active Directory forest.
This means that any authenticated user or computer can create a new object in the zone. Also by default, the creator owns the new object and is given full control of it.
Many thanks for your answer. Why are those entries not secure? That's why TechNet tells us the entry is not secured. In the lab, this works well. Just to be clear about your quoted sentence in red , and I'm nit sure if that is a misprint on your part:.
The TechNet article and your assessment are correct about the insecure records. That why you need both. And it's the way the engineers designed the product. Thanks for your responses and links provided. Was there ever an answer as to why, when using credentials, that the DNSUpdateProxy group membership is necessary? I'm trying to understand how the DNS registration process would differ with or without that group membership when DHCP is configured to use credentials.
It only applies to new leases. We usually recommend scavenging to cleanup the older records, or go through them manually, or script it using netsh. Don't be afraid of DNS Scavenging. I haven't scripted anything for DHCP yet. Maybe the following NetSH command references will help:. There is no reason to do that. Sorry Ace, no offence mate, but you are wrong regarding this matter and the initial question is answered incorrectly in this thread.
You will see that it works without any issues. I also use this set-up in production environments and it works well. The issue I am running into is that my users move around to different offices with non windows DHCP servers and the actual clients are unable to update their records since their outdated records are owned by the DHCP user account.
Unfortunately in that scenario, you must manually keep track of the records. I assume you have enabled scavenging? That will help partially. Links on this were provided in post above yours.
Secure only should only allow machines that are members of the domain update DNS, but if we are forcing all clients to be registered via DHCP credentials - wouldn't they all work? Or am I misunderstanding something? No, do NOT put the credential accounts in that group. The only thing that goes in it are the DHCP server computer objects, nothing else.
It looks as though I confused myself Please see my responses below to your checklist:. And to comment on your other reply, we do have option set to our domain name.
Does it matter if the clients can update DNS? Or should we work with the desktop team to disable DDNS on the client-side? I was originally going to just leave ddns enabled client-side but then I came across this post and it steered me in the other direction I have to agree with John here. I don't think it's reasonable to just say 'ms told us so'.
We need a technical before and answer is given. My thinking is this:. The DnsUpdateProxy group, along with configuring credentials, has to do with records ownership to eliminate duplicates.
This posting is provided AS-IS with no warranties or guarantees and confers no rights. Otherwise, the default process is outlined below, and this applies to non-Microsoft operating systems, too, but please note that non-Microsoft operating systems can't use Kerberos to authenticate to dynbamically update into a Secure Only zone, however you can configure Windows DHCP to do that for you. If that doesn't help, I highly suggest to contact Microsoft Support to get a definitive response.
If you do, I would be highly curious what they say if it's any different than what I found out from the product group mentioned earlier in this thread. And of course, if you can update what you find out, it will surely benefit others reading this thread that have the same question!
Thanks Ace, and apologies If I sounded curt which was not intentional and you are a huge contributor of valuable info here! Why is the DnsUpdateProxy group needed in conjunction with credentials? Basically, we have unsecured records. No problem, I didn't think you were curt, just upset that you don't have a definitive and black and white answer other than the TechNet articles I've posted explaining it.
Again, a call to Microsoft may be your better bet. And I hope you can post their response, if you could. I saw that we didn't need to add the servers the DnsUpdateProxy group beacause giving to much rights on DCs.
I would like to know if it's necessary to configure a service account to register dynamically dns records. For me it's not necessary but if it is can you confirm to me , do i need to configure a service account? I can't answer the question as to why you got a server for this role other than probably your company hasn't yet tested any newer operating system. You don't have to add it, if you feel it's a security concern.
That's up to you. But both are required to make this work, along with the configuration I posted above. Forces ownership to the account used in the credentials, which the DnsUpdateProxy group allowed to take ownership other than the registering client.
There's a ton of misinformation about this topic throughout the forums and Microsoft's own documentation, so I'll do what I can to clear it up:.
There's no reason to put the DHCP Server's computer account in the DnsUpdateProxy group if you're using a service account to do your dynamic updates, full stop. Note that this is a relatively new configurable property R2 and newer ; prior to its introduction, MS DNS servers just always behaved as if the property was set to 1. As you may have deduced, when you configure a DHCP server to use a service account to perform dynamic registrations, the server's computer account isn't used to authenticate the registration request to the DNS server, so there's no point whatsoever to adding that computer account to the DnsUpdateProxy group.
Finally, note that if you want your DHCP service account for DNS registration to be able to alter existing DNS records, you would need to make the service account a member of the DnsAdmins, Domain Admins, or Enterprise Admins groups, even if you put the service account in the DnsUpdateProxy group, because membership in this group does not allow a group member to bypass the existing ACL on a record.
I do not recommend that anyone do this, by the way, but if you wanted this functionality, that's the only way to do it. Ownership of the records is established when the first security principal accesses these entries. It also means that DHCP servers can update records on behalf of other servers that fail. If your DHCP server is a domain controller as those in many branch office configurations are , all the service location SRV and forward lookup A records registered when starting the Netlogon service will not be secure.
What can you do to address these concerns? To address some of these issues, a new DNS dynamic update credentials manager was created.
0コメント