Kerberos Authentication problems – Service Principal Name (SPN) issues

[patris1]

http://blogs.technet.com/askds/archive/2008/05/29/kerberos-authentication-problems-service-principal-name-spn-issues-part-1.aspx

PART-1


Hi Rob here again. I hope that you found the first blog on troubleshooting Kerberos Authentication problems caused by name resolution informative and learned something about how to review network captures as well as how the SMB protocol works at a high level when reviewing a network trace. This time we are going to focus on problems that arise when Service Principal Names are not configured properly to support Kerberos Authentication. We will use a web site having authentication problems to show you network captures and explain at a high level how the HTTP protocol works. There are other ways to troubleshoot Kerberos; one could just read Kerberos event logging outlined in KB 262177. Although you could rely on this method, it will take a longer to resolve the issue and you will be taking an educated guess without a network trace.
I am going to layout my lab configuration in case you want to reproduce the problem and look at the network traces on your own


Problem scenario:
We want to use Kerberos authentication with a web application. The web application is running on IIS 6.0. The web application is using a web application pool. This web application pools Identity is running as a domain user account (FABRIKAM\KerbSvc) because at a future time they will be front ending the web servers with a network load balancer.
When the users visit the website with an Internet Explorer client they are using NTLM and not Kerberos.
Eventually the user name password dialog stops popping up and they get a message within IE stating “You are not authorized to view this page”
We have a website that makes determining web site authentication easier to troubleshoot. As you can see we authenticated using NTLM.

If “Audit Logon Events” auditing was enabled for “Success” on the IIS Server would see the following event that would also prove we are authenticating using NTLM.

You can see that the Logon Type is “3” (Which means “network logon”) and the Authentication Package was “NTLM”. This proves that we authenticated using NTLM and not Kerberos.
When you troubleshoot using network captures, you want to install the network capture utility on both ends of the communications to make sure that there are no network devices (routers, switches, VPN appliances, etc) that are manipulating the packet in between the two systems. We call this taking a double-sided trace. In support we will typically request a double-sided network capture be taken.
Since my lab does not have any routers in the mix (both systems are on the same subnet) I am only going to trace on the source Windows XP client machine.
So what is the best way to get the network capture?
1. Make sure that there are no Internet Explorer windows open, and in general close down as many applications as possible so that your network traces are as clean as possible.
2. Start the network capture utility.
3. Clear all name resolution cache as well as all cached Kerberos tickets.

• To clear DNS name cache you type in: IPConfig /FlushDNS
• To clear NetBIOS name cache you type in: NBTStat –R
• To clear Kerberos tickets will need KList.exe: KList purge

4. Launch Internet Explorer and go to the web site.
5. Once the website comes up or error messages are being displayed, go ahead and stop the network capture.
Reviewing the network capture:
If you are using Wireshark to view the trace, the filter is simple: “dns || Kerberos || ip.addr==<IP Address of Target machine>”. Basically, this filter means “Show me all packets sent to or from the target machine, all DNS name queries and responses, and all Kerberos authentication.”
It should look similar to this:

Once you have the network capture, you should see all DNS, Kerberos Authentication (as well as packets that have Kerberos tickets in them), and anything destined for the remote system from the Windows XP client.
Before we go over the capture too much, we should probably cover at a high level the steps taken to connect to a website.

1. Resolve the host name for the target system to an IP Address.

a. Look in HOSTS file.
b. Query DNS.
c. Look in LMHOSTS file.
d. Query WINS / NBNS.

2. Client connects to the website anonymously using “HTTP GET”

3. If the website allows anonymous access then it is done. However if it does not, it responds back to the client with a list of authentication protocols it supports in the HTTP header.

4. Client attempts to get a Kerberos ticket for the website (from a domain controller) if the website supports Negotiate authentication.

5. Client then connects to the website and passes its credentials in the HTTP header.

Step 1 - resolve the name:

Remember, we did “IPConfig /FlushDNS” so that we can see name resolution on the wire. Frame 10 & 11 is the query and response for FAB-RT-DC1 (DC). In frame 46 and 47 is a query and response for the website name of webapp.fabrikam.com and response with a “A” or HOST record back of IP Address 10.10.200.105.
Step 2 – Client connects to the website anonymously:

So as we can see from the trace, the client does a HTTP GET request to the website and does not pass any user credentials. You can also notice that we are using HTTP 1.1 when we connect to the site.
Step 3 – Web Server responds with support authentication protocols:

Here we see that the website must require authentication to access the site because the web server responded back with a “401 Unauthorized”. We can also see that the web server supports the authentication types of: “WWW-Authenticate: Negotiate”, and “WWW-Authenticate: NTLM”.
In order for Kerberos authentication to work with IIS we must see Negotiate as an authentication method. If you do not see this you will need to enable this on the IIS web server or web site.
215383 How to configure IIS to support both the Kerberos protocol and the NTLM protocol for network authentication (How to configure IIS to support both the Kerberos protocol and the NTLM protocol for network authentication)
Step 4 - Request a Kerberos ticket for the website:

Alright, now to the meat of Kerberos authentication and viewing it in a network trace. If you remember we used KList Purge command to clear out all tickets on the system. That means that the server has to get a TGT first and this is why you are seeing the AS-REQ and AS-REP frames (frames 58 and 59). If Kerberos ticketing is new to you, I would suggest reviewing the blog on how Kerberos works.
Next, we see the TGS-REQ in Frame 60; let’s take a closer look at this packet in the details pane.

You can see that the user’s TGT is handed to the KDC under “padata: PA-TGS-REQ” section, and requesting a ticket for server “http/webapp.fabrikam.com” in the FABRIKAM realm (Windows Domain) under “KDC_REQ_BODY” section.
OK, since we now know that we are requesting a Kerberos ticket for “http/webapp.fabrikam.com” in the fabrikam.com domain and the KDC (domain controller) responds to the Kerberos ticket request with KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN this would tell us that the SPN for “http/webapp.fabrikam.com” is missing or possibly that there are multiple accounts with the same Service Principal Name defined on them within the Active Directory Forest.
Step 5 – Client connects and passes Credentials:

So we see in the following Frames:

• Frame 75 there is another HTTP GET command and it wants to connect using NTLMSSP_NEGOTIATE.
• Frame 77 since credentials were not passed in frame 62 the web server responds again with a 401 Unauthorized, but this time it also sends a NTLMSSP_CHALLENGE response.
• Frame 79 there is HTTP GET with NTLM_AUTH and we see that the account attempting to authenticate is FABRIKAM\Administrator.
• Frame 80 the web server responds with a 200 OK.

You can see in the detail pane that I have highlighted packet 79; where the Authorization data is provided; and NLTM credentials that are being passed are domain of FABRIKAM and user account of Administrator from Host XPPRO02.
In frame 80 the website responded back with an HTTP 200 OK message which basically means that it accepted the authentication.
So, now the question become how do we fix the problem?
Well, we now know what the Service Principal Name is that we are requesting (review Step 4, frame 60). The next step is within IIS 6, we need to know what account is running the Application Pool for the website in question. Once we know this information, we can validate / add the proper Service Principal Name to that account. How do you get it?

1. Open up IIS Manager.
2. Find the web site that has the application pool defined, right-click on it and select properties.
3. On the “Home Directory” / “Virtual Directory” tab find the Application Pool field. This is the application pool that we need to find out what identity is being used on.

4. Now we can expand the Application Pools folder in IIS Manager and find the Application Pool.
5. Right click and select properties on the Application Pool name, and select the “Identity” tab.

6. As you can see we are using a domain account called “FABRIKAM\KerbSvc” to run the web application pool.
7. The next thing that should be done, is to make sure that the SPN “http/webapp.fabrikam.com” is not currently being used by any other accounts within the Active Directory forest. This can be accomplished in several different ways.

• You could use LIDFDE to search for the SPN within all domains of the forest.
• You could use LDP to search for the SPN within all domains of the forest.
• You could use querySPN.vbs.

You can review the following KB article on how to use each of these tools: KB321044 for more detailed information on how to use these tools. The best method is to use querySPN.vbs, with this tool if you target a Global Catalog it can search through the entire domain tree. If you have multiple domain trees in the forest or you have multiple Forest Trusts, you will need to specify each domain tree root individually and search this way.
So here is what we find when I use querySPN.vbs searching for http/webapp*

This is good; this tells us that there are no accounts that have that Service Principal Name in the forest. So if we add the SPN to the “FABRIKAM\KerbSvc” account we will not create a duplicate entry.
8. Once you have validated that you are not going to create a duplicate SPN, you can use SetSPN.exe to set the Service Principal Name of “http/webapp.fabrikam.com” and “http/webapp” on the “FABRIKAM\KerbSvc” user account. Next, you should always verify that the SPN’s have been added by using SetSPN to list the Service Principal Names on the account. You can look at the below screen shot for how the commands were ran:

Notice that I have added the Netbios name for the site as well as the FQDN of the website. It is good practice to add both to the account. Applications may ask for SPN’s in either name format and it may not be clear which will be requested in every case.

Now we can test to verify it is working by attempting to access the website again.

That worked. Now I know what you guys are starting to ask: how does this look in a network trace? Let’s find out.

• In the Security Event log on the IIS server we find that “FABRIKAM\Administrator” did authenticate using Kerberos:

• Looking at the network capture we see the entire ticketing process with the domain controller and it responds with a TGS-REP as shown in the below capture:

This validates what the application is telling us: we authenticated to the web application using Kerberos Authentication.
For those of you who would like to see the Kerberos Service Ticket being passed to the Web Server here is a screen shot of that functionality.

We can see that the web server accepted the authentication. We can also see that a Kerberos ticket was sent in the HTTP header by looking at the KRB5_Blob tag, and that Internet Explorer sent a Kerberos ticket for “http/webapp.fabrikam.com”
Service Principal Name troubleshooting is usually a problem when you are setting up the application to support Kerberos. Typically once the application has been up and running for a while there are not too many SPN problems once the application is working unless the Service Principal Names are changing.
Summary
I hope that you have learned a few new things:

• How to search for duplicate Service Principal Names as well as how to add Service Principal Names.
• How to easily filter network traces to confidently determine where Kerberos authentication is failing.
• How the HTTP protocol works with authentication so that you can determine how you authenticated to the web site.

This blog post is the first in a three-part series that will cover the most common misconfigurations as they relate to Service Principal Name. So if I have not yet covered one of your current issues please check back soon. We will be covering issues like Duplicate SPN’s or the Service Principal Name being configured on the wrong account.
- Robert Greene

---

موضوعات مشابه:

• Potential for Kerberos Issues When Using a Cisco VPN/ASA with Win2003 or later DC’s
• RRAS Service fails to start on ISA Server 2006 when enabling RADIUS Authentication for VPN Users
• RRAS Service fails to start on ISA Server 2006 when enabling RADIUS Authentication for VPN Users
• Using Kerberos for SharePoint Authentication
• internet authentication service

---

[patris1]

http://blogs.technet.com/askds/archive/2008/06/09/kerberos-authentication-problems-service-principal-name-spn-issues-part-2.aspx

PART-2


So, we saw in Part 1 what kind of error you could expect when there is no Service Principal Name defined for the Kerberos ticket the application is requesting. The next part I would like to show you is what might be the error message you would get if there were multiple accounts with the same SPN defined on them.
We are not going to cover the basics of how to capture a network trace and how to review it this time so this part should be fairly quick. We are going to be using the same configuration as the previous blog post.
Again, we notice that the website shows that we are authenticating with NTLM and the web server’s auditing log also shows that we authenticated using NTLM.


Now when we look at the network trace, we see the following:

1. We see proper name resolution, for webapp.fabrikam.com and the DNS server response back with the IP address of 10.10.200.105 (frames 11 & 12)
2. The machine then makes an http connection to the web server, and gets “401 Unauthorized” (frames 18 -21). Note, I am showing you in the detail pane that the web server responded back with “WWW-Authenticate: Negotiate” and “WWW-Authenticate: NTLM” to let you see that the web server is configured properly to support Kerberos Authentication.
3. The machine then goes to the domain controller and gets its TGT (see the AS-REQ and AS-REP frames 23 & 24) then it does a TGS-REQ request but the domain controller responds back again with KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN (frames 25 & 26). As you can see below, the machine was asking for a Kerberos ticket of HTTP/webapp.fabrikam.com.

If you read the previous blog posting, your first thought might be to just add the Service Principal Name to the KerbSvc account and call it a day. If you did this, you would be wrong! If we look at the domain controllers System Event log we will see this really nice Event log entry.

This event log basically is stating that there are multiple computer or user accounts that have a Service Principal Name of HTTP/webapp.fabrikam.com within the Active Directory Forest. You can use LDP, LDIFDE or QuerySPN.vbs to find where the SPN's are registered. When you use these tools to search for duplicate SPN’s you should always start at the forest root and target a global catalog server. I prefer to use the queryspn.vbs and use wildcards in my statement. Review KB321044 if these tools are new to you. Just because the event shows that the FQDN is duplicated, you might be surprised by a duplicate SPN of the NetBIOS name HTTP/webapp too.

As you can see from this output, the account FAB-RT-MEM1 (Computer Account) and the account “Kerberos Service” (User Account) both have “http/webapp” and “http/webapp.fabrikam.com” assigned to them. No wonder the domain controller reported the KDC 11 event.
The resolution to this issue is fairly simple. If you remember from the previous blog, the web application is running in a Web Application Pool that is running under the context of the KerbSvc account. So in this instance we would want to use SetSPN to delete the HTTP SPN's from the computer account FAB-RT-MEM1.

Now, when we test the application, we can see that Kerberos authentication is used to access the website.

I am not going to show the network traces of it working again. If you would like to review what a working trace looks like please review Part 1.
Summary
In support we see duplicate Service Principal Name issues quite frequently. Usually this is when the Administrator has used the SetSPN on different accounts in an effort to get Kerberos Authentication to work. One great example of this is MS SQL. If you install MS SQL as an Administrator of the domain, it will add the MSSQLSVC SPN to the SQL Server’s computer account; later an Administrator changes the SQL Service startup account from Local System to a domain account and Kerberos Authentication starts to fail. Usually we will find that the MSSQLSVC SPN is configured on both the computer account as well as the domain user account that is used to run the service.
I hope that you have learned something new on how to troubleshoot a Kerberos Service Principal Name issue and that you’re starting to feel more comfortable using network traces to determine why Kerberos Authentication might be failing. Stay tuned for Part 3 where we will cover some more ways in which Kerberos Authentication can fail when Service Principal Names are not correctly configured.


- Robert Greene

[patris1]

http://blogs.technet.com/askds/archive/2008/06/11/kerberos-authentication-problems-service-principal-name-spn-issues-part-3.aspx

PART-3


Now we have seen what it looks like when there is no Service Principal Name defined, and when the Service Principal Name is not unique in the forest. We will now cover what things look like when the Service Principal Name is NOT added to the correct account.
We are still using the same setup as part 1 with all the same computer account names. So we will not go over the setup or cover how to take proper network traces. We will not go into much detail on most of the network trace data since this has already been covered.
When the user attempts to go to the site http://webapp.fabrikam.com/webapp they are being prompted for user name and password.

When they type in the user name of “FABRIKAM\Administrator” and the password, they again get prompted for user name and password.
After the 3rd attempt to enter in the credentials and we see the below:

If you have Kerberos Event logging enabled (KB262177) we see the following event listed here.

So, we now know that the error we are getting back from the Kerberos Authentication attempt is KRB_AP_ERR_MODIFIED (some network analysis tools show this as KRB5KRB_AP_ERR_MODIFIED). Basically this is stating that the Account that is running the service (in this case the IIS Web Application Pool account) could not decrypt the Kerberos ticket that the KDC gave to the client. This can happen for several reasons, but the most common are listed below:

• There is an account with the same SPN within the forest (Keep in mind in a multi-domain forest you need to search all domains to include other domain trees in the forest). As shown in the previous blog posting the KDC will give an error back of KRB_S_PRINCIPAL_UNKNOWN, but there are instances where it will give a Kerberos ticket that the service cannot decrypt and thus get a KRB5KRB_AP_ERR_MODIFIED.
• The Service Principal Name is on the wrong Active Directory account (Computer or User).
• The Active Directory account that is running the service has updated / changed its password and you are experiencing the problem because of an Active Directory Replication Latency or Active Directory Replication problem.

So now let’s look at the network trace of this attempt.

1. We see proper name resolution, for webapp.fabrikam.com and the DNS server response back with the IP Address of 10.10.200.105 (frames 3 & 4)
2. The machine then makes an http connection to the web server, and gets “401 Unauthorized” (frames 7 -14).
3. The machine then gets a TGT from the domain controller (see the AS-REQ and AS-REP) (frames 15 & 16)
4. The machine then requests and gets a Service Ticket for http/webapp.fabrikam.com (frames 17 & 18). As you can see below, the machine was asking for a Kerberos ticket of HTTP/webapp.fabrikam.com.

5. The machine then goes back to the web server and attempts to authenticate to the http://webapp.fabrikam.com/webapp site using the Kerberos ticket that it just got from the domain controller (frames 19-22). During the authentication the web server responds back with KRB5KRB_AP_ERR_MODIFIED (frames 23-24).

6. The machine then attempts to get a service ticket (TGS-REQ / TGS_REP) from the domain controller two more times in the trace, but each time the web server reports the same error of KRB5KRB_AP_ERR_MODIFIED (frames 15-18, 25-26, 34-37). The reason why you are seeing three different TGS-REQ / TGS_REP) requests to the domain controller is because you were prompted three times for user name and password when attempting to access the site before you got the 401.1 unauthorized error from the web server.

We need to do more investigation when you get the KRB5KRB_AP_ERR_MODIFIED. Keep in mind that this error really just means that the Service you are attempting to connect to could not decrypt the Kerberos ticket using its password Hash.
The first thing that we will test is to see if the Service Principal Name is registered to the correct account. If you remember from the previous blog the Web Application pool account that is running the website is Fabrikam\KerbSvc, as shown below:

So we will use the QuerySPN.vbs script again to find out what account(s) have the http/webapp or http/webapp.fabrikam.com SPN defined. Review KB321044 if these tools are new to you.

As you can see the SPN is on the Web Server computer account. Well, this will just not work; we will need to take it off of this account and add it to the FABRIKAM\KerbSvc account using SetSPN.

Now we see that we are able to access the website, and authenticating to the website using Kerberos Authentication.

NOTE: If we would have found that there were no duplicate SPN’s and that the only SPN registered in the Active Directory forest was correct we would have looked into a possible Active Directory Replication problem that might be causing the issue. You might be asking how could AD replication be causing the issue?
Let’s think about that. When a user, or Service Account, or computer password gets changed one domain controller in the environment accepts the password change. Through normal AD replication all domain controllers in the domain get the updated password. If you remember the Kerberos service ticket (the TGS) is encrypted with the service’s password hash. When the service decrypts the ticket it is going to use its current password hash to decrypt the ticket. So if the Kerberos service ticket was generated by a KDC (Domain Controller) that has not received the latest password for the service account then it will encrypt the ticket with the wrong password hash and thus the service will not be able to decrypt the ticket; you then get the KRB5KRB_AP_ERR_MODIFIED message.
Well, this is the last blog for Service Principal Name problems. I hope that you have enjoyed learning how to troubleshoot Kerberos authentication using network trace analysis to help find the cause of the failures.




- Robert "The SPN Doctor" Greene

[patris1]

http://blogs.technet.com/askds/archive/2008/05/14/troubleshooting-kerberos-authentication-problems-name-resolution-issues.aspx

Hi Rob here. I thought I would show you how we in Microsoft Commercial Technical Support typically troubleshoot Kerberos authentication issues. This discussion should do much to get you more comfortable viewing network traces for Kerberos authentication problems. There are other ways to troubleshoot Kerberos; one could use the Kerberos event logging outlined in KB 262177. Although you could rely on this method, it will take longer to resolve the issue and involves making some educated guesses without the network trace.
I am going to layout my lab configuration in case you want to reproduce the problem and look at the network traces on your own.
Forest layout:

The root domain litwareinc.com has one domain controller in the domain, and one member server



Network based troubleshooting (network captures) is the fastest way to determine the problem, and by learning a few short filters you can effectively troubleshoot most Kerberos-related problems.
You can use any network capture utility that you feel comfortable with. I prefer Netmon, nmcap (part of Netmon 3.x) or netcap (XP and 2003 support tools) to collect the network trace, and I use Wireshark to view the network capture. This is in no way an endorsement of Wireshark – feel free to use Ethereal, Packetyzer, etc.
Problem scenario:
There is a service running on LTWRE-RT-MEM1 server that runs starts /runs as “LocalSystem” account. This service connects to a file share on LTWRE-CHD-MEM1 named “AppShare” to access some files. The Service is failing to retrieve the files and is giving you an error of “Access is denied”. When you attempt to access the share as a domain user account on LTWRE-RT-MEM1 you are able to access the share.
Auditing for Logon/Logoff was enabled on LTWRE-CHD-MEM1, so you start by examining the security event log.
When the LITWAREINC\Administrator attempts to access the share we get the following Audit Event:

Notice how the user that authenticated to the server is the “LITWAREINC\Administrator” account. It used NTLM authentication and the source machine name is LTWRE-RT-MEM1.
When the Service attempts to access the share we get the following Audit Event:

Notice that when the service attempts to authenticate to the server it is doing it anonymously.
Hey, why is the computer authenticating to the other machine using NTLM authentication?
I thought we were in the 21st century with Kerberos authentication?
As it turns out, starting with Windows XP and Windows Server 2003 a computer cannot not use NTLM authentication when accessing a remote resource. If it does, it will use Anonymous Logon credentials and typically fail.
That means we have to figure out why Kerberos authentication is failing on LTWRE-RT-MEM1 when accessing a share on LTWRE-CHD-MEM1.
Typically when you troubleshoot using network captures, you want to install the network capture utility on both ends of the communications to make sure that there are no network devices (firewalls, routers, switches, VPN appliances, etc.) that are manipulating the packet in between the two systems. We call this taking a double-sided trace.
When working with a customer, we will typically request a double-sided network capture be taken. In this scenario I would start with installing the network capture utility on the source and destination server to see what is going on.
So the next question I guess becomes what are the steps to taking a good network capture?
Well, we want to see all name resolution, and we will also want to ensure that we see the Kerberos tickets (Authentication) in the capture. We also want to make sure that we can reproduce this problem at will to see this problem for ourselves.
So, how can we reproduce the problem?
1. Get a command prompt as the “SYSTEM” and attempt to access the remote system.


On Windows 2000, Windows XP, and Windows Server 2003 we can use the AT command to get a command prompt as the “SYSTEM” account by type the following command:
AT <Military Time in Future> /Interactive “cmd.exe”
i.e. if the time is currently 7:04 PM you would type in: AT 19:06 /Interactive “cmd.exe”
Then at 7:06 PM you should see a command prompt pop up


NOTE: You have to do this while logged into the console session. If you are RDP’ed in you need to start the RDP session with the /console switch otherwise you will never see the command window start.
2. Start the network capture utility.
3. Clear all name resolution cache as well as all cached Kerberos tickets.

• To clear DNS name cache you type in: IPConfig /FlushDNS
• To clear NetBIOS name cache you type in: NBTStat –R
• To clear Kerberos tickets will need KList.exe: KList purge

The above commands need to be done in the command prompt that came up for “SYSTEM”

4. Now you need to run a command that will require authentication to the target server. Either of the following will do:

• Net View \\LTWRE-CHD-MEM1
• Dir \\ltwre-chd-mem1\AppShare

5. Once you get the error message, stop and save the network captures.
Reviewing the network capture:
If you are using Wireshark to view the trace, the Filter is simple: “dns || Kerberos || ip.addr==<IP Address of Target machine>”. Basically, this filter means “Show me all packets sent to or from the target machine, all DNS name queries and responses, and all Kerberos authentication.”
It should look similar to this:

Once you have the network capture, you should see all DNS, Kerberos Authentication (As well as Packets that have Kerberos tickets in them), and anything destined for the remote system.
Before we go over the capture too much, we should probably cover at a high level the steps taken to connect to a remote file share.
1. Resolve the host name for the target system to an IP address.

a. Look in the HOSTS file.
b. Query DNS.
c. Look in the LMHOSTS file.
d. Query WINS / NBNS.

2. Ping the remote system.
3. Negotiate an Authentication protocol. Kerberos is preferred for Windows hosts.
4. Request a Kerberos Ticket.
5. Perform an SMB “Session Setup and AndX request” request and send authentication data (Kerberos ticket or NTLM response).
Let’s look at those steps in more detail.
Step 1 - resolve the name:

Remember, we did “IPConfig /FlushDNS” so that we can see name resolution on the wire. Frame 1 is the query out. Hmm, this looks kind of funny: querying for LTWRE-CHD-MEM1.litwareinc.com. Well, that part should be fine, I suppose, since the DNS server should not find the record. But wait Frame 6 shows that the DNS Server responded to the query with 10.10.200.21, and sure enough that is the correct IP Address for the target server.
Step 2 - ping the remote system:

Yep, the remote system is ping able. See the Echo request and reply. So the system is up and available.
Step 3 - Negotiate Authentication:

So now we negotiate the authentication protocol and the remote system responded; the response is the more important part of the packet. We see that it supports MS KRB5, KRB5, and NTLMSSP; it even gave us the principal name of the system.

Step 4 - Request a Kerberos ticket:

Alright, now to the meat of Kerberos authentication and viewing it in a network trace. If you remember, we used KList Purge command to clear out all tickets on the system. That means that the server has to get a Ticket Granting Ticket (TGT) first, and this is why you are seeing the AS-REQ and AS-REP frames. If Kerberos ticketing is new to you, I would suggest reviewing the blog on how Kerberos works.
Next, we see the TGS-REQ in Frame 18; let’s take a closer look at this packet in the details pane.

You can see that the system is handing its TGT to the Kerberos Key Distribution Center (KDC) under “padata: PA-TGS-REQ” section, and requesting a ticket for server “cifs/LTWRE-CHD-MEM1.litwareinc.com” in the LITWAREINC.COM realm (Windows Domain) under “KDC_REQ_BODY” section.
OK, since we now know that we are requesting a Kerberos ticket for “cifs/LTWRE-CHD-MEM1.litwareinc.com” in the litwareinc.com domain. This will not work since the remote system actually lives in the “litwareinc-chld.litwareinc.com” domain. So you see why the KDC responded back with KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN. Again, if you do not understand this please review the blog on how Kerberos works.
Step 5 - Perform a SMB “Session Setup AndX request”:

So we see in the following Frames:

• Frame 20 shows that, since Kerberos failed due to an unknown service principal name, the NTLMSSP_NEGOTIATE authentication package is selected. Frame 21 shows that the remote system sending the NTLMSSP_CHALLENGE (this is typical) back.
• Frame 22 shows that the system sent no NTLM credentials to the remote system. It is authenticating as NT AUTHORITY\Anonymous.
• Frame 23 shows that the remote system allowed the session to be created.
• Frame 24 & 25 shows that we do a Tree connect to the IPC$ share and get a response.
• Frame 26 & 27 shows that we connect the SRVSVC named pipe and get STATUS_ACCESS_DENIED back.

So where do you think things start to go wrong here in the trace?

If you answered DNS name resolution you would be correct. If name resolution is not working properly in the environment it will cause the application requesting a Kerberos ticket to actually request a Service ticket for the wrong service principal name. So if you remember the remote file server I am attempting to connect to “ltwre-chd-mem1.chd.litwareinc.com”, however the DNS Server found a record for “ltwre-chd-mem1.litware.com”. Since we found the remote file server in the “litwareinc.com” domain the Kerberos client requests a service ticket for “cifs/ltwre-chd-mem1.litwareinc.com” as noted in the Kerberos ticket request, and the KDC responds with KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN.

I did another net view specifying the FQDN of LTWRE-CHD-MEM1 and WOW, look at the output:

That actually worked! So, how can we fix this problem?
Actually, there are several different ways to “fix” the problem:
a. Find out why DNS is resolving the machine name incorrectly.

i. Is there a HOST or CNAME record for this name?
ii. Did you configure the DNS Zone for WINS lookup?

b. Configure your application to use the FQDN of the system instead of NetBIOS name.
c. We could add an Service Principal Name to LTWRE-CHD-MEM1 for “CIFS/LTWRE-CHD-MEM1.litwareinc.com”
The best way to “Fix” the problem is to actually fix DNS name resolution. By the way, the lab was configured with “WINS Lookup” enabled on the litwareinc.com DNS Zone. If you are failing to use Kerberos authentication using the LocalSystem account, you are more than likely failing to use Kerberos authentication when users are going to the remote system. However, they are not getting “Access is denied” because user accounts, unlike machine accounts, can fail over to NTLM and authenticate with credentials rather than as Anonymous.
If you find that fixing the DNS problem is not possible, then the next best solution would be to make the application use the FQDN of the server. Keep in mind that the application vendor would need to be involved to use this fix.
The least favorite method to resolve the issue would be to add the SPN to the destination server using the SetSPN.exe tool. This is the least favorite because you are adding another name to the machine account in another domain. What would happen if in the future you bring up a new computer in the root domain with the same name? Now you have a duplicate SPN and this will lead to other Kerberos authentication problems.
Well, I hope that you have learned a few new things like:

• How name resolution problems could cause Kerberos authentication to fail.
• How to easily filter network traces to confidently determine where Kerberos authentication is failing.
• How the SMB protocol and authentication look in a network trace.

Please keep in mind that there are several other ways that name resolution could cause Kerberos authentication to fail. You could have static WINS entries in the database, or you could have wrong entries in HOSTS / LMHOSTS files. You could be failing because of a CNAME / “A” (HOST) record within your DNS zone, or simply because of the DNS Zone is configured for “WINS Lookup”.




Robert Greene