Domain authentication fails on Vista to Vista RDP attempt

Here is a Vista Remote Desktop problem we are having. It affects every Vista
machine I have seen on our network. I believe this is going to be a tough
one…..

Remote machine – Vista Enterprise on Windows 2003 AD network.
Local machine – Vista, any version, domain member or not, connecting from
within the network.
When trying to complete the Remote Desktop connection using a domain
account, the user gets the following error:
“No authority could be contacted for authentication. For assistance,
contact your system administrator or technical support.�

If the local (client) machine is running XP, no problem.
If you use an account local to the remote Vista machine, no problem (not
surprisingly).

Strangest of all, if I try to make the connection from a machine outside of
our network, no problem. (Normally the firewall would block that, but I
temporarily allowed RDP from anywhere.)

Has anyone else seen this? Any explanations? Should I post to a different
NG, such as an Active Directory one?

Thanks

Does this sound like your problem?
http://support.microsoft.com/kb/939820

Have you performed an authoritative restoration of the Users container? If
so, there's a hotfix for you. If not, let us know.

---
Your question may already be answered in Windows Vista Security:
http://www.amazon.com/gp/product/047...otectyourwi-20


"Baboon" wrote:

> Here is a Vista Remote Desktop problem we are having. It affects every Vista
> machine I have seen on our network. I believe this is going to be a tough
> one…..
>
> Remote machine – Vista Enterprise on Windows 2003 AD network.
> Local machine – Vista, any version, domain member or not, connecting from
> within the network.
> When trying to complete the Remote Desktop connection using a domain
> account, the user gets the following error:
> “No authority could be contacted for authentication. For assistance,
> contact your system administrator or technical support.�
>
> If the local (client) machine is running XP, no problem.
> If you use an account local to the remote Vista machine, no problem (not
> surprisingly).
>
> Strangest of all, if I try to make the connection from a machine outside of
> our network, no problem. (Normally the firewall would block that, but I
> temporarily allowed RDP from anywhere.)
>
> Has anyone else seen this? Any explanations? Should I post to a different
> NG, such as an Active Directory one?
>
> Thanks
>

Darn! I guess I just don't know how to do a search. I didn't get anything
like that returned to my query. It sure sounds like that has to be it. I
don't know of an authoritative restore having been done, but I don't work at
that level in the organization. If it was *only* the Users container that
needed to be restored, I could have easily been unaware, since there are no
user accounts in there that represent real people (in our case).

I'll have to ask someone, which may be a wild goose chase. The only Windows
person in the organization besides me who knows AD quit a few months ago and
nobody is minding the house (for example, no WSUS update approvals done since
then.) Since title is all that really matters, they won't ask me to take
care of it. Do I sound bitter? ;-)

Thanks for the article. The only thing that bugs me about it is that it
doesn't explain why the updating of the USN for the krbtgt account causes
this problem. I still think it's bizarre that this doesn't happen when the
client is outside the network.

Thanks much and I'll let you know how it turns out....when someone gets back
to me in a few months.


"Jesper" wrote:

> Does this sound like your problem?
> http://support.microsoft.com/kb/939820
>
> Have you performed an authoritative restoration of the Users container? If
> so, there's a hotfix for you. If not, let us know.
>
> ---
> Your question may already be answered in Windows Vista Security:
> http://www.amazon.com/gp/product/047...otectyourwi-20
>
>
> "Baboon" wrote:
>

Sorry to hear about the state of your organization. I can assure you that you
are not alone though, if that helps any.

The issue in the article is a bit bizarre. I can't quite figure out why this
bug is there at all.
---
Your question may already be answered in Windows Vista Security:
http://www.amazon.com/gp/product/047...otectyourwi-20


"Baboon" wrote:

> Darn! I guess I just don't know how to do a search. I didn't get anything
> like that returned to my query. It sure sounds like that has to be it. I
> don't know of an authoritative restore having been done, but I don't work at
> that level in the organization. If it was *only* the Users container that
> needed to be restored, I could have easily been unaware, since there are no
> user accounts in there that represent real people (in our case).
>
> I'll have to ask someone, which may be a wild goose chase. The only Windows
> person in the organization besides me who knows AD quit a few months ago and
> nobody is minding the house (for example, no WSUS update approvals done since
> then.) Since title is all that really matters, they won't ask me to take
> care of it. Do I sound bitter? ;-)
>
> Thanks for the article. The only thing that bugs me about it is that it
> doesn't explain why the updating of the USN for the krbtgt account causes
> this problem. I still think it's bizarre that this doesn't happen when the
> client is outside the network.
>
> Thanks much and I'll let you know how it turns out....when someone gets back
> to me in a few months.
>
>
> "Jesper" wrote:
>

Hello Baboon,

Thank you for your post and also thank to Jesper for the useful inputting.

Yes, you can try to patch this hotfix first. If this problem remains,
please feel free to let me know. I will be always available for any further
assistance.

I look forward to your reply.

Thank you and have a nice day!

Sincerely,
George Yin
Microsoft Online Support
Microsoft Global Technical Support Center

Get Secure! - www.microsoft.com/security
================================================== ===
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ===
This posting is provided "AS IS" with no warranties, and confers no rights.

It doesn't say so in the KB article, but I discovered today that Vista with
SP1 doesn't have this problem. I tried the RDP client from 2 different
machines that had SP1 beta installed and both were successful without the
workaround. Since SP1 is so close to release, I think it's important that
people know this. Lots of administrators would gladly choose making sure SP
1 is installed on their Vista machines over installing a hotfix on their DCs.

Thanks.

"George Yin(MSFT)" wrote:

> Hello Baboon,
>
> Thank you for your post and also thank to Jesper for the useful inputting.
>
> Yes, you can try to patch this hotfix first. If this problem remains,
> please feel free to let me know. I will be always available for any further
> assistance.
>
> I look forward to your reply.
>
> Thank you and have a nice day!
>
> Sincerely,
> George Yin
> Microsoft Online Support
> Microsoft Global Technical Support Center
>
> Get Secure! - www.microsoft.com/security
> ================================================== ===
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> ================================================== ===
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>

Hello Baboon,

Thank you for the reply. Great to hear that Windows Vista SP1 will work
well. If there is anything else I can help, please feel free to let me know.

Thank you and have a nice day!

Sincerely,
George Yin
Microsoft Online Support
Microsoft Global Technical Support Center

Get Secure! - www.microsoft.com/security
================================================== ===
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ===
This posting is provided "AS IS" with no warranties, and confers no rights.