locked
Remote Desktop and Terminal Services No Longer Working - An authentication error has occurred (Code: 0x80090327)

    Question

  • Hello

    I recently set up a Windows 2008 R2 Server in order to be able to test the new terminal services features and everything was working really well except that if the RemoteApps were hosted on a seperate server people had to log in twice. 

    In an attempt to enable Single Sign-On on the rdweb site I have inadvertantly done something to stop RemoteApp and Remote Desktop working at all now.

    When I try a standard remote desktop connection externally I now get:
    An authentication error has occurred (Code: 0x80090327).

    I also receive this error when trying to launch a remote app so cannot access the server at all now.

    I have tried to undo the settings I changed however I still cannot clear the error.

    Internally Remote Desktop and RemoteApp still work but not externally due to the above error.

    After Bing'ing it seems that it is something to do with the certificate or possibly smart cards but I have added the ca cert into the trusted root certification authority on the external machines and the common name on the certificates is now *.domain.
    I believe the connection does go through the rd gateway which is www.domain and the apps are accessed as computer.domain so a certificate of *.domain should work. Also I do not use smart cards.

    As I said I had all this working before but must have changed something to stop it working. I tested it externally on Windows XP and Windows 7 and it worked before but not now.

    Thanks for any help with this.
    Robin
    Robin Wilson
    Tuesday, August 18, 2009 9:34 AM

Answers

All replies

  • I forgot to mention that the error is actually different if I try to connect from Windows 7 than it is if I try to connect with XP.

    The error is as follows:
    "Your remote desktop connection failed becuase the remote computer cannot be authenticated

    The remote computer could not be authenticated due to problems with its security certificate. It may be unsafe to proceed.

    Certificate name: Name in the certificate from the remote computer:
    computer.domain

    Certificate errors
    The following errors were encountered while validating the remote computer's certificate:

    A revocation check could not be performed for the certificate.

    You may not proceed due to the severity of the certificate errors."

    It has a view certificate button which if I press it shows the certificate as being valid.

    Can you not use certificates from an internal CA even if you add them to the Trusted Root Certification Authorities?

    Thanks
    Robin

    EDIT: This URL shows the errors I am receiving:
    http://blogs.infosupport.com/blogs/martijnv/archive/2009/03/04/Remote-Desktop-with-NLA-_1320_-Code-0x80090327.aspx
    • Edited by robinwilson16 Tuesday, August 18, 2009 12:06 PM Found URL describing issue
    Tuesday, August 18, 2009 11:24 AM
  • Hi Robin,

    According to the error message, I suspect that the client computers cannot access the CDP locations. Please add the latest CRL to the local store and check if the issue goes away:


    1.   
    Copy the latest CRL to the client machines.

    Default CA Certificate and CRL Storage
    http://technet.microsoft.com/en-us/library/cc786344(WS.10).aspx

    2. Run the command Certutil –addstore CA mycrl.crl.

    Note: Please replace the mycrl with the exact name of the CRL file.

    Thanks.

    Joson Zhou

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com



    This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, August 19, 2009 7:17 AM
    Moderator
  • Hi Joson,
    With respect Joson, your workaround doesn't resolve the issue. If we have hundreds of users with this problem we can't go around manually copying crl files. I am seeing the same problem on some computers and not on others. I have the problem on several computers (we are doing a pre-deployment pilot of RDS on R2) and after some investigation found that the crl wasn't being replicated* to the public published location - and was therefore out-of-date. I fixed that and the Windows 7 computer refreshed itself and resumed normal operation. The XP Pro SP3 computers are not refreshing and therefore continue to fail - even though the crl is now fresh and available at the public location.

    *other people will run into this. Upgrading a CA to Windows 2008 breaks replication if you are using FRS to replicate crls to a publishing location.

    Joson: I realise this is all geeky PKI stuff but I believe there is something missing on the XP Pro client-side. Can you ask one of the PKI experts to try and replicate this problem? I suppose upgrading to Vista or Win7 is going to be the answer but a bit of effort from Microsoft would help - a script to have the client go find the crl and refresh would help.

    Thanks in advance, Anthony Murfet
    Anthony Murfet
    Wednesday, August 19, 2009 3:18 PM
  • Thanks Joson and Anthony for your replies.

    I was hoping that external clients would not need to do a lot of stuff before being able to connect as I'm wanting to provide people with an easy way to connect from unmanaged PCs.
    How do I replicate my certificates to a public location which can be accessed externally and tell clients where to go to? I did not know I had to do this which may be why it's not working!

    I will try copying the ctrl using Joson's suggestion and report back whether it fixed the issue.

    Just to clarify this does work internally and did briefly work externally until I started getting these revocation errors.

    UPDATE:
    I tried the certutil command and it seems to have fixed the issue with an external Windows 7 PC but I tried it with an XP machine but it couldn't find the certutil command. I searched the hard drive just in case it was not in the path. I tried adding it to the Trusted Root Certification Authorities as well but that didn't help. Does XP have a similar command?

    Thanks for the help.
    Robin
    • Edited by robinwilson16 Wednesday, August 19, 2009 7:42 PM Tried CertUtil Command
    Wednesday, August 19, 2009 6:41 PM
  • I'm thinking this may be something that is new to Server 2008 R2 as if I go to the CA and right-click on Certifiicate Templates and choose manage, under the server tab for the web server certificate it says "Do not include revocation information in issued certificates (Applicable only for Windows Server 2008 R2 and above)" - this is not ticked by default.

    How do I specify where the crl is? Apparently I can host it on the web server over http but would need to specifty the url of the crl as a distribution point.

    EDIT
    I've worked it out - right-click on the CA and choose properties. Click the extensions tab and under CRL Distribution Point (CDP) I've added http://domain/CertEnroll/filename.crl. I then ticked the "Include in the CDP extension of issued certificates.
    I copied the CertEnroll folder to the wwwroot folder on the web server so I'm hoping this is right.
    I then regenerated all the certificates so that they would include this CDP.

    I cannot try it on another computer until the morning though so I'll see if this has fixed it.
    Does that sub-directory need any special permissions?

    Is this right or am I going in totally the wrong direction with this?

    Thanks
    Robin
    Wednesday, August 19, 2009 10:35 PM
  • Hi Anthony,

     

    Thanks for your information.

     

    My steps are just used to identify the cause of the issue. J

     

    Regarding the problem you encounter, I suggest that you post to the Security forum. Please initial a new thread there with the detailed information in order that we can reproduce and analyze the issue.

     

    Thanks.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, August 20, 2009 10:37 AM
    Moderator
  • Hi Robin,

     

    According to your description, the steps are correct. Are all the external client computers able to access the RD Web now?

     

    You may also refer to the following article for more information about CDP configuration

     

    Configure CDP and AIA Extensions

    http://technet.microsoft.com/en-us/library/cc776904(WS.10).aspx

     

    Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure

    http://technet.microsoft.com/en-us/library/cc772670(WS.10).aspx

     

    Thanks.

     

    Joson Zhou

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, August 20, 2009 10:38 AM
    Moderator
  • Hello Joson

    Thanks for the links.
    I've just got someone to try from an external pc again using XP and they still get:
    An authentication error has occurred (Code: 0x80090327).

    A Windows 7 one is no longer giving the revocation error which it was before and is connecting but this is actually an internal domain pc but I simulated an external environment by putting a second router in and logging in locally and modifying the hosts file to point the www domain to the incoming port on the second router. So maybe some other factor is making this one work.

    Apparently the certutil utility for XP can be installed from the Server 2003 adminpak, but this shouldn't be necessary now should it if the revocation info is available online should it?

    There is a .asp file in the CertEnroll folder but if I go to http://domain/CertEnroll/longfilename.asp it gives the 500 Server Error message. Is this normal or does this indicate some problem.

    Is there a way to check what the revocation is in a certificate and if it is accessing it successfully?
    Are any special permissions required on the CertEnroll directory.

    I feel this is starting to get a bit over my head!
    Robin
    Robin Wilson
    Thursday, August 20, 2009 11:33 AM
  • Hi Robin,
    I've initiated a support call with Microsoft Professional Support. If I find out anything useful I'll post back here.

    Cheers, Tony.
    Anthony Murfet
    Thursday, August 20, 2009 2:04 PM
  • Hello Tony

    Ok thanks, hope you get the problem sorted!

    After setting up the certificate revocation this now seems to make it work with Windows 7 externally without even having to run the certutil command which is good.
    However external XP machines are still displaying the same error and are unable to connect.

    I found out that to get the certutil command on XP you have to install the Server 2003 Administration Tools (adminpak). I did this and ran the command, however XP still gave the same error after this.

    What do I need to change to get this working with XP clients?

    It fails internally and externally with XP whereas it now works both internally and externally with Windows 7.
    It did work previously with XP clients as well. The problem is I just don't know what has changed.

    Thanks
    Robin
    Robin Wilson
    Thursday, August 20, 2009 7:30 PM
  • Hi Robin,

     

    Please open Internet Explorer on the Windows XP computer, type http://domain/CertEnroll/filename.crl and confirm if you can download the CRL file. If you can download a valid CRL file from the URL, please collect the following information for further research:

     

    1.    Please export the certificate from the server and save as a .cer file.

    2.    Please copy the .cer file to the Windows XP computer, and run certutil –verify –urlfetch certificate.cer > file.txt on the computer.

    3.    Please perform the following steps on the Windows XP computer and a Windows 7 computer to capture the network traffic:

    1) Download and Install the Netmon3.3 on the computers:

    Microsoft Network Monitor 3.3

    http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=983b941d-06cb-4658-b7f6-3088333d062f

    2) Log onto the machines, right-click the Netmon icon and select Run as Administrator to launch NetMon3.3.
    3) In the Microsoft Network Monitor 3.3 window, click Create a new capture tab.
    4) In the new tab, select all the Network Adapters in the Select Networks window.
    5) Press F10 to start NetMon.
    6) Access the RD Web server to reproduce the issue.
    7) After that, go back to the NetMon window and press F11 to stop the NetMon.
    8) Press Ctrl+S to save the Netmon files.

    Note: Please also let me know the IP address of the RD Web Server.

    4.    Please zip the files (.cer file, file.txt, and the Netmon files) and upload to the following space:

    https://sftasia.one.microsoft.com/choosetransfer.aspx?key=fa375933-4794-42b9-967b-77e49d71ad26
    Password: Xt)Lk7MG3ch3n

    By the way, can we access the RD Web server from the Internet?

     

    I look forward to your response.

     

    Joson Zhou

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, August 21, 2009 9:47 AM
    Moderator
  • Hello Joson

    After experimenting further with this I have identified the cause.

    How it was previously:
    Windows 7 internal and external working - still no SSO though
    Windows XP and Vista internal and external - not working and no SSO either (I don't believe SSO will work on these platforms anyway until RDP7 is out). Gives the error: An authentication error has occurred (Code: 0x80090327).

    To fix it:
    Go to Remote Desktop Session Host Configuration
    Double-click on the RDP-Tcp connection
    On the general tab press the <Default> button to use an auto-generated certificate instead of the proper domain one
    Press Ok

    Connections to XP and Vista machines both internal and external now work.

    I did try this previously but it did not work last time, possibly due to the certificate revocation not also being set up at the time??

    Would you still find it helpful to have the netmonitor files? Should I put it back how it was first?

    Although I have fixed it, SSO is still not working and I have had to replace the proper certificate with an auto-generated one which would seem less secure. Is this due to a lack of support in XP and Vista clients? Do you think the rdp7 client will fix this?

    And yes I can access the RD web server from the internet.
    Thanks for all the help.

    Robin


    Robin Wilson
    Friday, August 21, 2009 12:00 PM
  • This solution is not ideal now as from an external Windows 7 machine I now get a warning about the certificate not being from a trusted root certification authority and that it might not be safe to continue due to me changing it from one generated from the CA to a self-signed one to make the Vista and XP machines happy and for it to work at all with those clients.

    After restarting all the servers again single signon seems to work internally with Windows 7 clients but still fails to work externally with the added certificate warning now.

    Is there anything else I can do?
    If I could at least avoid people having to enter the domain name the second time they are asked to authenticate it would help. Otherwise I see this causing lots of confusion due to the fact that people don't have to enter the domain name anywhere else.

    Thanks
    Robin
    Robin Wilson
    Saturday, August 22, 2009 11:54 AM
  • I decided that maybe the reason why the certificate did not work on the older machines was because I was using a generic one (*.domain) so I tried changing it from the self-signed one which was working to server.domain generated by the CA but now it is back to the revocation error message I was getting previously and no clients will connect including Windows 7. However if I view the certificate and look at the CRL Distribution Points it lists the second URL as my websever and if I copy and paste the address into IE it askes me if I want to save the crl file so that proves it works I suppose?

    I copied over the CertEnroll directory from the CA share to the CertEnroll folder on the web server in case it had changed but I still get this error. Is it a time issue?

    Also there are two CRL files, one has a plus (+) sign on the end of it. I was linking to the one without the plus, is that right? The one with the plus sign has a modified date of today.

    As well under CRL Distribution Points the second URL is the correct one with the first one being an LDAP link which would not work externally so should that be removed and all the certificates regenerated?

    Robin
    Robin Wilson
    Saturday, August 22, 2009 12:41 PM
  • Hi Robin,

     

    Please check my answers:

     

    Q: I copied over the CertEnroll directory from the CA share to the CertEnroll folder on the web server in case it had changed but I still get this error. Is it a time issue?

    A: We don’t need to copy the .asp file. Please perform the steps 1 and 2 in my previous reply to collect the information for further research.

     


    Q: Also there are two CRL files, one has a plus (+) sign on the end of it. I was linking to the one without the plus, is that right? The one with the plus sign has a modified date of today.

    A: The CRL file with a plus (+) sign is Delta CRL file. We need to copy it to the Web server as well.

     


    Q: As well under CRL Distribution Points the second URL is the correct one with the first one being an LDAP link which would not work externally so should that be removed and all the certificates regenerated?

     

    A: If it is an Enterprise CA, you’d better not remove the LDAP distribution point. To provide multiple access protocol methods for CRL retrieval, different distribution points are provided to facilitate heterogeneous environments.

     

    Thanks.

     

    Joson Zhou

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, August 26, 2009 10:58 AM
    Moderator
  • https://connect.microsoft.com/windows7/feedback/ViewFeedback.aspx?FeedbackID=483392

    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    Thursday, September 3, 2009 1:44 PM
  • Hello Joson

    I will try this over the weekend and get back to you.
    Sorry I've just seen the date on your post, I do not remember getting the notification that there had been a new post.

    Am I right in assuming that the contents of the CertEnroll directory would only be updated when  a certificate was revoked? So I'm not going to have to keep copying this directory to the web server.

    Thanks
    Robin
    Robin Wilson
    Friday, September 4, 2009 9:32 PM
  • Hi Robin,

     

    You need to update the contents of the CertEnroll directory based on the CRL publish period. Otherwise, certificates are treated as invalid if the CRL is expired. The CRL is published by default in the folder systemroot\system32\CertSrv\CertEnroll\.

     

    For more information, please refer to the following articles:

     

    Revoking certificates and publishing CRLs

    http://technet.microsoft.com/en-us/library/cc782162(WS.10).aspx

     

    Schedule the publication of the certificate revocation list

    http://technet.microsoft.com/en-us/library/cc781735(WS.10).aspx

     

    Thanks.

     

    Joson Zhou

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, September 7, 2009 2:03 AM
    Moderator
  • Ok thanks for that. I will keep that in mind and might set up a distributed share for it which syncronises or something like that.

    I still haven't had a chance to come back to this and try again but as soon as I do I will try what you have suggested and let you know the outcome.

    Thanks
    Robin


    Robin Wilson
    Thursday, September 10, 2009 7:44 PM
  • Hi,

     

    Yes, you can synchronize the folders by using DFSR.

     

    If you need further assistance, please feel free to respond back.

     

    Thanks.

     

    Joson Zhou

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, September 11, 2009 6:48 AM
    Moderator
  • Every week I have to re-dowload the crl from my CA and re-install on remote workstations for RDP with SSL to work. Is there something I am missing or is this a bug? My CA is a Windows 2008 Ent. Server. I have to go back to the certsrv website and redownload the base crl to each station running Windows 7. Please help. Thanks in advance.

    This only occurs with Windows 7 Remote Desktop Connection any version of Windows 7. VISTA, XP, Server 2003, Server 2008 No Problems and have not need to re-install the CRL from the CA since the first day of use...

    Tuesday, April 6, 2010 7:00 PM
  • Hello loki258

    I think from what I have learned in trying to fix my issue you need to copy everything from the CertEnroll folder to a folder within your internet-facing site and then create a new certificate template which specifies the URL to the CRL.

    This way the certificate will use the remote CRL rather than the local CRL which will no longer be valid once the CRL publishing period has expired.

    You can then use DFS to syncronise the HTTP CRL with the CertEnroll directory (or possibly just create a virtual directory which points to that location.

    The reason you may only be seeing this issue with Windows 7 computers is that if you have the security set to negotiated then the highest supported security level will be used which with RDP7 is higher so may require a valid CRL (just a guess).

    If the Remote Session Host certificate is what is causing the problem then you can just set it to an auto-generated one which is what I did and I never did get the single signon working externally but according to articles I have read it is not possible externally which is a shame. Although it does work internally.

    Hope it helps.

    Robin


    Robin Wilson
    • Proposed as answer by loki258 Monday, May 10, 2010 2:38 PM
    Thursday, April 8, 2010 10:01 PM