After having firewall ports opened to access a UNC path, I ran into an issue where I could not access the share using the fully qualified domain name. When accessing the site, I received the below error.
My initial thought was that the name was not resolving, but the error would seem to indicate a connection was being made. I decided to remove host name resolution by adding the entry to the hosts file on the client system. When I tried the connection again, I received the same message.
At this point, I decided to look at what was occurring, so I fired up WireShark. I used the following following filter to view only what I thought interesting.
- ip.addr == x.x.x.x || dns || kerberos || cldap
Where x.x.x.x is the ip of the server where the share was created.
Now, I won’t list the packet data here, I don’t want to leak any information :-), however, below is a screenshot of the protocols and a bit of the information. Take a look and we will go through it below.
- The first three packets are the TCP handshake between my client and the server hosting the share.
- Following are two SMB protocol packets where the client and server are determining the authentication mechanisms supported and negotiating which to use.
- Then comes the KRB5 packets. There are 10 of them.
- the first 4 are obtaining a TGT from the KDC and are not relevant to the issue here, just know that I was able to obtain a TGT from the KDC.
- The remaining 6 KRB5 packets are three request response pairs. The response is the important part. Each one adds a piece of the servers windows domain. In my case I have a domain of company.com and two subdomain. So to determine the domain to which i need to authenticate, it takes three passes each returning more of the domain.
- once we have the domain to which we need to authenticate, we look it up via DNS. The 6 DNS packets are the traversal of the Microsoft DNS tree determining a domain controller in the servers domain for authentication purposes.
- After resolving the DNS name of the DC in the servers domain, we issue a RootDSE query for the Netlogon attribute.
I blocked out irrelevant packets and if you look at the bottom of the graphic, you will notice that there are three (3) RootDSE query requests.
If you were not aware, most applications will try a request three times before abandoning the connection. This means the likely culprit in this case is that the CLDAP protocol UDP port 389 needs to be opened between my client pc and the domain controllers for sub1.subdomain.com.
Open port 389 between the source computer and the domain controllers in the domain to which the destination server resides.