Krb ap err modified

Krb ap err modified

Про АйТи и около айтишные темы

Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера

Просматривал журнал на своем рабочем компьютере с Windows 7 и наткнулся на любопытную ошибку. (у коллеги на компьютере с Windows XP таких ошибок нет)

Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера PC1$. Использовалось конечное имя cifs/PC2.domain.ru. Это означает, что конечному серверу не удалось расшифровать билет, предоставленный клиентом. Это может быть из-за того, что имя участника службы конечного сервера (SPN) зарегистрировано на учетной записи, отличной от учетной записи, используемой конечной службой. Убедитесь, что конечное имя SPN зарегистрировано только на учетной записи, используемой сервером.

Причиной этой ошибки может быть еще и то, что конечная служба использует другой пароль для учетной записи конечной службы, отличный от пароля центра распределения ключей Kerberos (KDC) для учетной записи конечной службы. Убедитесь, что и служба на сервере, и KDC обновлены, чтобы использовать текущий пароль. Если имя сервера задано не полностью и конечный домен (DOMAIN.RU) отличен от домена клиента (DOMAIN.RU), проверьте, нет ли серверных учетных записей с таким же именем в этих двух доменах, или используйте полное имя для идентификации сервера.

Самое интересное, что PC1 и PC2 находятся в другой подсети и почему эта ошибка отобразилась в моем журнале – непонятно!

В интернете пишут, что ошибка возникает из-за DNS, в котором могут быть прописаны разные узлы с одним и тем же IP-адресом. Но у меня в DNS было все нормально, записей с одним IP не было.

Решил глянуть, что происходит в WINS. Мысль оказалась верной. При поиске по IP адресу, вылезло сразу 3 машины на один айпи. Потер все совпадающие записи с сервера WINS и надеюсь, что ошибки пропадут.

Нашли опечатку в тексте? Пожалуйста, выделите ее и нажмите Ctrl+Enter! Спасибо!

Хотите поблагодарить автора за эту заметку? Вы можете это сделать!

Rob here. 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 “FABRIKAMAdministrator” and the password, they again get prompted for user name and password.

After the 3 rd 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.

Читайте также:  Альфа ос alfa os

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 FabrikamKerbSvc, 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 FABRIKAMKerbSvc 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.

KRB_AP_ERR_MODIFIED is a common Kerberos failure message. This means some encrypted Kerberos authentication data sent by the client did not decrypt properly at the server.

When a Kerberos client requests a ticket for a specific service, the service is actually identified by its SPN. The KDC grants the client a service ticket that is encrypted using service’s secret key. Basically, the AD account password that that matches the SPN requested.

Читайте также:  Excel подбор слагаемых для нужной суммы

Under some scenarios, KDC may generate a service ticket that encrypted with password of a wrong account (or not expected one). Then, when client provide that ticket to the service for authentication, the service can’t decrypt it and authentication failed with KRB_AP_ERR_MODIFED.

In short, this happens because KDC issued a ticket encrypted using password of account A, but on the service side, it tries to decrypt this using the password of account B.

Common cause for this are duplicated SPN, wrong DNS settings, two computers in different domains have the same name, client requests wrong SPN. And from IIS 7, it may due to the wrong setting of IIS (kernel/user mode authentication).

Collect data and identify the cause of Kerberos failure

Tools Used to collect data

  1. 1. Registry Editor(build in tool)
  2. 2. KList(build in for Windows 2008+)

Steps to collect data

  1. 1. Enable Kerberos log on both client machine.

262177 How to enable Kerberos event logging

  1. 2. Open a command console with elevated privilege, and run “klist purge” to clear cached Kerberos tickets.
  2. 3. Run “ipconfig /flushdns” to clear DNS cache.
  3. 4. Run Network monitor on both client and web server.
  4. 5. Reproduce the problem.
  5. 1. Network Monitor Trace

Identify the Kerberos error

By expanding the authenticate field in the HTTP response header returned by IIS, we could locate the reason for Kerberos authentication error.

— Http: Response, HTTP/1.1, Status: Unauthorized, URL: / , Using GSS-API Authentication

StatusCode: 401, Unauthorized

— Authenticate: Negotiate oWwwaqADCgEBomMEYWBfBgkqhkiG9xIBAg >

TokId: Krb5Error (0x300)

— Error: KRB_ERROR (30)

+ ErrorCode: KRB_AP_ERR_MODIFIED (41)

+ Realm: TEST.COM

+ Sname: contososvc

Date: Fri, 14 Oct 2011 05:10:14 GMT

It would be more straightforward using Wireshark.

  1. 2. From the system event log of client side, follow event will be logged.

Log Name: System

Date: 10/13/2011 10:10:05 PM

Task Category: None

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server contososvc. The target name used was HTTP/iis01.test.com. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Please ensure that the target SPN is registered on, and only registered on, the account used by the server. This error can also happen when the target service is using a different password for the target service account than what the Kerberos Key Distribution Center (KDC) has for the target service account. Please ensure that the service on the server and the KDC are both updated to use the current password. If the server name is not fully qualified, and the target domain (TEST.COM) is different from the client domain (TEST.COM), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

In this event, the SPN used is HTTP/iis01.test.com, and the account used to decrypt the ticket is contososvc. This happens because the account account used to encrypt the ticket is not contososvc.

Scenario 1: Duplicated SPN

In the case of a duplicated SPN, the same SPN was registered on at least two accounts. For example, a SPN was registered on two accounts: A and B. What happens is that KDC will generate a service ticket that may be encrypted with password of account A. Then, when the client sends that ticket to the service during authentication, the service may try to decrypt this using account B.

Detect duplicated SPN using setspn

On Windows 2008 and later, detect duplicated SPN is easier. Since Windows Server 2008, the setspn itself includes a feature to search SPNs.

Besides HTTP/ SPN, please remember to check HOST/ SPN as well. HOST/ SPN will be used as a failover/alternative if HTTP/ SPN does not exist. In case of this scenario, wrong HOST/ SPN will result in Kerberos failure as well.

Here is a sample output of setspn on Windows Server 2008 SP2. For more details about this tool, please reference this document.

Читайте также:  M5a78l m lx3 обновить bios

Find duplicated SPN using ldifde

For Windows 2003 and XP, we can use another tool named ldifde to search duplicated SPN. Here is a sample query for HTTP/contoso. Please remember, don’t forget HOST/ SPN as well.

Here is an example output of ldifde, for more details about this tool, please reference follow document.

The SPN is forest-wide object, it has to be unique inside the whole domain. For a complex environment, using follow command to search the entire forest, like this:

Ldifde -s GCName -t 3268 -f d:spn.ldf -d “dc=test, dc=com” –l ServicePrincipleName –r “(ServicePrincipalName=HTTP/contoso)”

In addition, we can use a wild card search like this:

Ldifde -s GCName -t 3268 –f d:spn.ldf -d “dc=test, dc=com” -l servicePrincipalName -r (servicePrincipalName=*contoso*)

Scenario 2: Internet Explorer (or other client) requested ticket for wrong SPN

This is a specific scenario which most related to the behavior of client. This problem occurs if the Web site uses a CNAME resource record in the Domain Name System (DNS). For example, the DNS setting looks like this:

Contoso CNAME iis01.test.com

iis01.test.com A 10.0.5.2

When you use Internet Explorer to access the Web site, Internet Explorer uses the host name of the server ((IIS01)) instead of the CNAME resource record(Contoso) to contact the server. The authentication may fail with KRB_AP_ERR_MODIFIED.

HTTP/Contoso.test.com Registered on testcontososvc

HOST/IIS01.test.com Registered on testiis01(machine account)

Identify this scenario from Network Monitor trace.

  1. 1. IE sends request to http://contoso , and a DNS query for contoso was sent.

+ Ipv4: Src = 10.0.5.3, Dest = 10.0.5.1, Next Protocol = UDP, Packet >

+ Udp: SrcPort = 64506, DstPort = DNS(53), Length = 42

  1. 2. DNS response for contoso

+ Ipv4: Src = 10.0.5.1, Dest = 10.0.5.3, Next Protocol = UDP, Packet >

+ Udp: SrcPort = DNS(53), DstPort = 64506, Length = 78

QueryIdentifier: 19377 (0x4BB1)

— ARecord: contoso.test.com of type CNAME on class Internet: iis01.test.com

— ARecord: iis01.test.com of type Host Addr on class Internet: 10.0.5.2

  1. 3. TGS ticket request, IE requests SPN for : HTTP/iis01.test.com instead of expected HTTP/contoso.test.com

+ Ipv4: Src = 10.0.5.3, Dest = 10.0.5.1, Next Protocol = TCP, Packet >

+ Tcp: Flags=. AP. SrcPort=50044, DstPort=Kerberos(88), PayloadLen=1488, Seq=4106960882 — 4106962370, Ack=354586390, Win=513 (scale factor 0x8) = 131328

— Kerberos: TGS Request Realm: TEST.COM Sname: HTTP/iis01.test.com

Solutions for CName

  1. 1. If the client is IE, KB 911149 described the solution for this problem.

Error message in Internet Explorer when you try to access a Web site that requires Kerberos authentication on a Windows XP-based computer: "HTTP Error 401 — Unauthorized: Access is denied due to invalid credentials"

  1. 2. If the client is an application uses System.Net.HttpWebRequest, using CustomTargetNameDictionary.
  1. 3. On DNS server side, configure the IIS server to a host record (A) instead of Alias(CNAME).

Scenario 3: SPN set to unexpected account (Wrong IIS 7+ authentication settings)

Internet Information Services (IIS) 7.0 enables kernel mode authentication by default. Kernel mode authentication runs under the machine account no matter what account is used to run the application pool. The machine account is used to decrypt the Kerberos ticket.

However, there are some scenarios you need to use a domain service account for authentication process instead of machine account. For example, a web arm scenario.

For this scenario, Instead of disabling kernel mode authentication in IIS, you can configure IIS to use the Web application pool’s ).

For IIS 7+, we have 3 Windows authentication configuration. Different scenario requires register SPN on different accounts. In the scenario of improper SPN and IIS 7 configuration, it may result in authentication failure with KRB_AP_ERR_MODIFIED if the SPN was set to unexpected account.

  • · Kernel mode authentication disabled
  • · Kernel mode authentication enabled, useAppPoolCredentials
  • · Kernel mode authentication enabled

NOTE: Machine account includes all accounts can represent the machine on network including Network Service, Local System, Local Service and ApplicationPoolIdentity for IIS 7+. Service accounts means a domain account used as the application pool identity.

Here, I listed couple of scenarios which can result in Kerberos authentication failed with KRB_AP_ERR_MODIFIED.

Ссылка на основную публикацию
Adblock detector