How is the DHCP lease duration and DNS garbage collection process related?
As a preface. When communicating with colleagues, answering their questions about the joint configuration of DNS and DHCP, I often refer them to the wonderful article by Sean Ivey on Technet. Unfortunately, I did not find a similar material in Russian. Once again, when I orally translated it to a friend, I decided to issue a translation in order to be able to send to him.
Hello everyone, my name is Shawn Ivey and I am US PFE (Premier Field Engineer). My specialty is Windows and Active Directory. Simply put, I specialize in Active Directory and its associated network services. Recently, with three different clients, I helped SCCM administrators who had a problem installing the SCCM agent. In the ccm.log log, there was an error Failed to get token for current process (5) . We found that the problem was not in SCCM, but in the interaction of DNS and DHCP. As it turned out, other services also experienced related problems, simply either showed other symptoms or did not show them at all. Let's talk about why it happened and how it can be prevented!
Consider the following scenario:
So far, so good. This is a fairly typical scenario of the DHCP server and everything happens exactly as we expect. Let's add the DNS server here now.
(If, all of a sudden, you don’t know what a “cleaning zone” is, “blocking / updating interval”, then I recommend you to read my colleague’s blog . It’s awesome! Note: since you’re reading a translation of the original article, then it may be easier for you get acquainted with the Russian-language material )
Now everything is not so good. This happens more often than you might think. Now Clients A and B have DNS records that refer to the same IP address.
')
Picture 1
So, we have two different names in the DNS that refer to the same IP address. And, most likely, everything will remain like this at least another 6 days, until the intervals described above expire. What problems can this cause? Let's get a look.
I already mentioned that the symptom of this situation was the problem with installing the SCCM client, but, in fact, we can use to demonstrate a simpler example - access to a shared folder. The principle is the same.
Let's imagine that I need to access the shared folder on Client A. For example, let's take one of the administrative shared folders.
Figure 2
But this is already interesting. First, client A is not even included ... but we get a response on his behalf. And this is an authentication error! Some of you have already guessed that this happens when you send a Kerberos session key intended for one computer to another, but let's take it in order.
We see that our computer (Infra-App1) sends a request to DNS in the name client-a.corp.contoso.com. In response, he receives the IP address 10.0.0.100.
Figure 3
As far as DNS is known, it is. Client A actually has the address 10.0.0.100, but Client B. has the exact same address.
Great, now we get the Kerberos session key. But the DNS request was addressed to Client A, so the response from the Kerberos service will also be addressed to client A.
Figure 4
Figure 5
We see the request for Figure 4 and the response of the domain controller in Figure 5.
Now, having received the key, we can try to connect to what we consider to be Client A.
Figure 6
Here we see the Kerberos session key.
And finally, we see an error message from Client A. Why? Because Client A is not Client A, but Client B.
Figure 7
All this only confirms what you probably already knew. In order for Kerberos to work normally, you must contact the correct session key with the correct recipient (If you want to learn more about Kerberos, read Rob Green's blog " Kerberos for busy admins " Note: I did not find similar material in Russian, but with general information can be found here ).
Of course, everything will work fine if, instead of the FQDN of the name, we turn to the IP address. Why? Because in this case, NTLM authentication will be used instead of Kerberos. Using an IP address, we make no assumptions about which client we connect to. We simply connect to a specific IP address. Some of you might think that for the FQDN should work. In the end, getting an error when using Kerberos, we have to switch to NTLM, right? Not really. I will not go into details, but we will switch to NTLM only if we could not agree on using Kerberos. You can read more about this here . In any case, Kerberos did not return errors to us, he regularly answered us with the session key.
Now that we’ve figured out that the problem is caused by outdated DNS records, let's discuss how we can prevent this situation. There are several different ways to do this. Let's discuss each of them.
Note: I recommend reducing the cleaning interval for each of these methods to 1-3 days. The default 7-day interval allows problem logs to remain in the DNS for too long.
Try experimenting with the update and blocking intervals and the length of the DHCP lease. You may find that changing the default intervals has a beneficial effect on the performance of your network services. Short term DHCP leases are often used for wireless networks. At the same time, do not forget about the additional load that you place on the server, especially if you configure frequent (every few hours) cleaning for a very large DNS zone.
Almost all! Now we understand why this situation occurs when a problem occurs and how to prevent it. But how can we easily and quickly find such records if trouble has already happened? You can easily find such paired records in DNS using a simple PowerShell script (this is certainly not the only way).
Below is a sample output of this script:
Figure 8
The script is very simple. Consider it only as an example. It will return duplicate IP addresses registered for computer accounts in Active Directory. Remember that he will request all computer objects from the Active Directory domain and check the IP address of each of them in the DNS. If you have many computers, use the -searchbase option with the get-adcomputer command to limit the number of objects polled each time. If your computer is not included in the Active Directory domain, then you will not be able to find it with the get-adcomputer command. My script is specifically designed to get duplicate DNS records for the script I described above.
There are so many articles on configuring DHCP and DNS integration. The purpose of this is to summarize how these two services work together to make it easier for you to understand. Summarize:
I hope that the article was useful to you! Proper configuration of DNS and DHCP integration will relieve you of such problems on your network!
Hello everyone, my name is Shawn Ivey and I am US PFE (Premier Field Engineer). My specialty is Windows and Active Directory. Simply put, I specialize in Active Directory and its associated network services. Recently, with three different clients, I helped SCCM administrators who had a problem installing the SCCM agent. In the ccm.log log, there was an error Failed to get token for current process (5) . We found that the problem was not in SCCM, but in the interaction of DNS and DHCP. As it turned out, other services also experienced related problems, simply either showed other symptoms or did not show them at all. Let's talk about why it happened and how it can be prevented!
Consider the following scenario:
DHCP
- The DHCP area is configured with IP addresses, with a lease term of 8 days
- There are few free IP addresses in the DHCP area
- Client A did not renew the rental of his address for 8 days and it expired
- Client B requests a new IP address
- DHCP server gives Client B the address previously used by Client A
So far, so good. This is a fairly typical scenario of the DHCP server and everything happens exactly as we expect. Let's add the DNS server here now.
DNS
- Active Directory-integrated DNS zone with zone cleaning configured
- Clear default settings: “Block interval = 7 days” and “Update interval = 7 days”
- Server settings are also default: “Cleanup period = 7 days”
- Client A updated the DNS record 8 days ago (on the very day he received his address)
- Client A is the owner of its DNS record and it cannot be deleted by a DHCP server (with default settings)
- Client B tries to register a DNS entry with a new address that he received from a DHCP server
- This is the same IP address that Client A used!
- DNS server will not be able to clean the old record of the Client And 6 more days!
(If, all of a sudden, you don’t know what a “cleaning zone” is, “blocking / updating interval”, then I recommend you to read my colleague’s blog . It’s awesome! Note: since you’re reading a translation of the original article, then it may be easier for you get acquainted with the Russian-language material )
Now everything is not so good. This happens more often than you might think. Now Clients A and B have DNS records that refer to the same IP address.
')
Picture 1
So, we have two different names in the DNS that refer to the same IP address. And, most likely, everything will remain like this at least another 6 days, until the intervals described above expire. What problems can this cause? Let's get a look.
Problem
I already mentioned that the symptom of this situation was the problem with installing the SCCM client, but, in fact, we can use to demonstrate a simpler example - access to a shared folder. The principle is the same.
Let's imagine that I need to access the shared folder on Client A. For example, let's take one of the administrative shared folders.
Figure 2
But this is already interesting. First, client A is not even included ... but we get a response on his behalf. And this is an authentication error! Some of you have already guessed that this happens when you send a Kerberos session key intended for one computer to another, but let's take it in order.
We see that our computer (Infra-App1) sends a request to DNS in the name client-a.corp.contoso.com. In response, he receives the IP address 10.0.0.100.
Figure 3
As far as DNS is known, it is. Client A actually has the address 10.0.0.100, but Client B. has the exact same address.
Great, now we get the Kerberos session key. But the DNS request was addressed to Client A, so the response from the Kerberos service will also be addressed to client A.
Figure 4
Figure 5
We see the request for Figure 4 and the response of the domain controller in Figure 5.
Now, having received the key, we can try to connect to what we consider to be Client A.
Figure 6
Here we see the Kerberos session key.
And finally, we see an error message from Client A. Why? Because Client A is not Client A, but Client B.
Figure 7
All this only confirms what you probably already knew. In order for Kerberos to work normally, you must contact the correct session key with the correct recipient (If you want to learn more about Kerberos, read Rob Green's blog " Kerberos for busy admins " Note: I did not find similar material in Russian, but with general information can be found here ).
Of course, everything will work fine if, instead of the FQDN of the name, we turn to the IP address. Why? Because in this case, NTLM authentication will be used instead of Kerberos. Using an IP address, we make no assumptions about which client we connect to. We simply connect to a specific IP address. Some of you might think that for the FQDN should work. In the end, getting an error when using Kerberos, we have to switch to NTLM, right? Not really. I will not go into details, but we will switch to NTLM only if we could not agree on using Kerberos. You can read more about this here . In any case, Kerberos did not return errors to us, he regularly answered us with the session key.
How to prevent
Now that we’ve figured out that the problem is caused by outdated DNS records, let's discuss how we can prevent this situation. There are several different ways to do this. Let's discuss each of them.
Note: I recommend reducing the cleaning interval for each of these methods to 1-3 days. The default 7-day interval allows problem logs to remain in the DNS for too long.
- Increase the duration of the DHCP lease so that it matches the sum of the refresh and block intervals. In our example, we will increase it to 14 days.
Benefits:
- By the time DHCP can issue an address to a new client, the old DNS record may already be deleted.
- Ease of implementation
Disadvantages:
- If you already have few free IP addresses in DHCP, they can simply end.
- The moment of cleaning the zone does not necessarily coincide with the time the expiration of the update and blocking intervals (and therefore the DHCP lease time) and we can get the situation described above for a short time. To reduce the number of such problems, we can reduce the cleaning interval to 1 day.
- Reduce the update and blocking intervals so that their amount matches the length of the DHCP lease. In our example, we will reduce both intervals to 4 days.
Benefits:
- The existing DNS record will be cleared earlier. In essence, the result will be similar to the previous one.
- Ease of implementation
Disadvantages:
- The load on Active Directory replication will slightly increase (if, of course, this is an Active Directory integrated zone). This is because clients will update their DNS records more often (in our case, every 4 days instead of 7)
- The moment of cleaning the zone does not necessarily coincide with the time the expiration of the update and blocking intervals (and therefore the DHCP lease time) and we can get the situation described above for a short time. To reduce the number of such problems, we can reduce the cleaning interval to 1 day.
- Configure a DHCP server so that it registers DNS records on behalf of clients (you can read how to configure it here. Note: in Russian, here )
Benefits:
- DHCP server will delete records in DNS immediately after the lease of the IP address
- With proper setup, you will never have such problem records.
Disadvantages:
- More complex setup requires the involvement of more qualified staff.
- Setup is further complicated by the need for a service account, on behalf of which the DHCP server will work or all DHCP servers will need to be added to the DNSUpdateProxy group (a less secure option)
Try experimenting with the update and blocking intervals and the length of the DHCP lease. You may find that changing the default intervals has a beneficial effect on the performance of your network services. Short term DHCP leases are often used for wireless networks. At the same time, do not forget about the additional load that you place on the server, especially if you configure frequent (every few hours) cleaning for a very large DNS zone.
Search DNS records with the same IP address
Almost all! Now we understand why this situation occurs when a problem occurs and how to prevent it. But how can we easily and quickly find such records if trouble has already happened? You can easily find such paired records in DNS using a simple PowerShell script (this is certainly not the only way).
#Import the Active Directory Module import-module activedirectory #Define an empty array to store computers with duplicate IP address registrations in DNS $duplicate_comp = @() #Get all computers in the current Active Directory domain along with the IPv4 address #The IPv4 address is not a property on the computer account so a DNS lookup is performed #The list of computers is sorted based on IPv4 address and assigned to the variable $comp $comp = get-adcomputer -filter * -properties ipv4address | sort-object -property ipv4address #For each computer object returned, assign just a sorted list of all #of the IPv4 addresses for each computer to $sorted_ipv4 $sorted_ipv4 = $comp | foreach {$_.ipv4address} | sort-object #For each computer object returned, assign just a sorted, unique list #of all of the IPv4 addresses for each computer to $unique_ipv4 $unique_ipv4 = $comp | foreach {$_.ipv4address} | sort-object | get-unique #compare $unique_ipv4 to $sorted_ipv4 and assign just the additional #IPv4 addresses in $sorted_ipv4 to $duplicate_ipv4 $duplicate_ipv4 = Compare-object -referenceobject $unique_ipv4 -differenceobject $sorted_ipv4 | foreach {$_.inputobject} #For each instance in $duplicate_ipv4 and for each instance #in $comp, compare $duplicate_ipv4 to $comp If they are equal, assign #the computer object to array $duplicate_comp foreach ($duplicate_inst in $duplicate_ipv4) { foreach ($comp_inst in $comp) { if (!($duplicate_inst.compareto($comp_inst.ipv4address))) { $duplicate_comp = $duplicate_comp + $comp_inst } } } #Pipe all of the duplicate computers to a formatted table $duplicate_comp | ft name,ipv4address -a Below is a sample output of this script:
Figure 8
The script is very simple. Consider it only as an example. It will return duplicate IP addresses registered for computer accounts in Active Directory. Remember that he will request all computer objects from the Active Directory domain and check the IP address of each of them in the DNS. If you have many computers, use the -searchbase option with the get-adcomputer command to limit the number of objects polled each time. If your computer is not included in the Active Directory domain, then you will not be able to find it with the get-adcomputer command. My script is specifically designed to get duplicate DNS records for the script I described above.
Conclusion
There are so many articles on configuring DHCP and DNS integration. The purpose of this is to summarize how these two services work together to make it easier for you to understand. Summarize:
- Scenario
- DHCP lease address duration and default update and blocking intervals = obsolete DNS records
- Symptoms
- SCCM: “Failed to get token for current process (5)”
- Shared folders: “Logon Failure: The target account name is incorrect”
- Any other services using Kerberos can also produce various errors.
- Problem
- Correct operation of Kerberos requires that the session key be issued specifically for the computer with which we are trying to establish a connection. Outdated DNS records can lead to situations where we will access one computer with a key for another.
- Decision
- Change the refresh and blocking intervals and / or the duration of a DHCP lease
- Configuring DHCP for the server to register DNS records on behalf of clients
- Find and delete duplicate entries
I hope that the article was useful to you! Proper configuration of DNS and DHCP integration will relieve you of such problems on your network!
Source: https://habr.com/ru/post/281410/
All Articles