Error "Your offer could not be sent" attempting to use Remote Assistance in a Windows Server 2003 Active Directory domain


You have one or more Windows Server 2003 domain controllers in your Active Directory domain. You receive the following error when a Windows 7 Expert attempts to provide an unsolicited Remote Assistance request to a Windows Vista or Windows 7 Novice:

Your offer to help could not be sent.


The Remote Assistance session is unable to start because the Expert is unable to obtain a Kerberos ticket to the computer or user account of the Novice.

This can occur after the Windows Server 2003 domain krbtgt account has been authoritatively restored and the version of the password for the krbtgt account has been increased during the restore to be greater than 255.

When an Expert attempts to offer unsolicited Remote Assistance from Windows 7, the computer first tries to obtain a Kerberos ticket for the user account on the Novice's computer. Since no service principal name (SPN) is registered on the user account, the Kerberos Key Distribution Center (KDC) service on the domain controller returns the error KDC_S_PRINCIPAL_UNKNOWN and falls back to User2User authentication. The expert gets the novice user’s ticket granting ticket (TGT) which was emitted by the Windows Server 2003 domain controller and inspects it to know if the request should be sent to the KDC or a read-only domain controller (RODC). Since the version of the krbtgt password is higher than 255, the Expert computer mistakenly attempts to find a RODC, which fails.


To resolve this issue, install the following hotfix on the Windows Server 2003 domain controllers:

939820 Events 1925, 1006, 1645, 1055, 40961 on a Windows Server 2008-based domain controller or error message: "No authority could be contacted for authentication" when you use Remote Desktop Connection

The hotfix should be installed on all Windows Server 2003 domain controllers in the environment to have consistent behavior.

A workaround for this issue is to add a SPN to the target user account.

More Information

Network traces from the Expert computer show it making a TGT request first which is successful.

Next it attempts to acquire a Kerberos ticket for the remote user account and the KDC returns KDC_ERR_S_PRINCIPAL_UNKNOWN. Since no SPN was registered on the user account, the protocol falls back to User2User authentication. The KDC reply also indicates KDC_ERR_MUST_USE_USER2USER.

Note that a Windows Server 2003 domain controller does support a User2User ticket request.

The client proceeds to build the request in memory for the User2User ticket request however this never leaves the box and goes on the wire.

This is because the client inspects the users TGT (which was emitted by the KDC) to find out if the User2User request should be sent to the KDC or a RODC. It does that by evaluating the key version number (KVNO) value of the ticket.

If the KVNO is set to be greater than 255 then the TGT is deemed to have come from a RODC.

For RODC-issued TGTs the KVNO is set to the value of the msDS-secondaryKrbTGTNumber attribute as stored on the RODC computer account. For more information on the msDS-secondaryKrbTGTNumber attribute see the following Microsoft website:

Attribute msDS-SecondaryKrbTgtNumber

For non-RODC issued TGTs the KVNO is set to the value of the replication metadata Version value of the unicodePwd attribute of the domain-wide krbtgt account.

Therefore in the case that a Windows Server 2003 domain was authoritatively restored (including the krbtgt account) for any reason and the version number of the krbtgt password increased to more than 255, the Windows 7 client will mistakenly believe that the TGT is from a RODC and look for a Windows Server 2008 domain controller. The client tries to send the User2User request to a Windows Server 2008 or later domain controller using DCLocator flag DS_DIRECTORY_SERVICE_6_REQUIRED. Since the client cannot find a Windows Server 2008 domain controller, it fails to send the User2User request.