locked
Direct Access IP-HTTPS not working with Intermediate CA for remote clients, possible UAG config bug RRS feed

  • Question

  • Hi,

    i have UAG Direct Access configured. Everything works perfect except IP-HTTPS. When running netsh interface httpstunnel show interface I receive no usable certificate(s) found.

    I walked over the troubleshooting guide, and Tom Shinder's article but everything seems to be OK.

    I've checked client has certificate according to the DNS name of the machine. On the server side, HTTPS interface is configured with proper certificate. CRL is available from outside.

    We have Offline Root CA and Intermediate CA. When configuring DA in UAG Console I have selected that remote clients are chaining to Intermediate CA. But when I walk over the summary before applying the policies, UAG writes it will verify against the Root CA.

    Is this normal summary screen?

    Any suggestions where the problem could be?

    Best regards,

    Petko Stoyanov

    Thursday, April 8, 2010 5:20 PM

Answers

  • Hi Petko,

    This is not a bug, but most likely an issue with computer certificate mapping for the DA clients. When the DA client creates an IP-HTTPS connection with the UAG DirectAccess server, there is mutual certificate authentication. If the computer account doesn't belong to the same domain as the UAG DirectAccess server, then the computer side of the mutual authentication will fail.  The computer accounts need to belong to the domain that the UAG DA server belongs to because of this. The users and resources can belong to any domain or forest for which there is a bidirectional trust.

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Friday, July 9, 2010 1:22 PM

All replies

  • Why not choose to verify against your Root CA using the "use root CA" option?
    Jason Jones | Forefront MVP | Silversands Ltd
    Thursday, April 8, 2010 11:06 PM
  • Why not choose to verify against your Root CA using the "use root CA" option?
    Jason Jones | Forefront MVP | Silversands Ltd
    Thursday, April 8, 2010 11:06 PM
  • Hi,

    I have changed to use root CA, but still no success.

    Client sais: no usable certificate(s) found.

    Both DA Server IP-HTTPS certificate and DA Client Machine certificates are valid. Share same root CA. CRL is accessible.

    When I try from IE on client the url of the DA Server: https://da.xxx.net:443/IPHTTPS i reveive HTTP 403 Forbidden, when I try https://da.xxx.i-net:443/any i receive 404 - file or directory not found, with valid certificate for da.xxx.net.

    Any idea how to troubleshoot the case?

    Best regards,

    Petko

     

    Friday, April 9, 2010 5:16 PM
  • Have a look here:

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

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd
    Friday, April 9, 2010 11:43 PM
  • I have followed this troubleshooter. Everything seems to be allright. Still no success :-(.

    Petko

    Saturday, April 10, 2010 8:18 AM
  • Nothing in Tom's article seems similar?
    Jason Jones | Forefront MVP | Silversands Ltd
    Saturday, April 10, 2010 11:10 PM
  • Monday, April 12, 2010 1:53 PM
  • Hi Tom,

    I read once again your article. I still have the problem, but I suspect what it may be.

    I have Forest A and Forest B, two way trust. UAG is in forest A, PCs and Users are in B.

    I have configured UAG DA serving both domains and 6to4 and Teredo are working fine.

    However IP-HTTPS is not, no mather all certificates and CRL are OK. Client replys: no usable certificate.

    Tom, do you think the problem is that UAG verifies certificate against his own AD (DS Mapper Usage in your article), but not the trusted ones?

    Regards,

    Petko

    Wednesday, April 14, 2010 6:34 PM
  • Hi Petko,

    I know that there is an issue if there are certificates used that were not issued by the enterprise CA in the UAG DA server forest, even when there is a two-way trust.

    I have put together a Proof of Concept lab guide for those who would like to put the UAG-DA server in its own forest, but the issuing CA and any intermediates are in the UAG DA server's forest, not the "production" or "resource" forest.

    While it might be an issue with the DS mapper usage issue, I can't say for sure. I'll see what I can find out.

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Wednesday, April 14, 2010 7:33 PM
  • Hi Tom,

    I have Offline Root CA and Operational CA in forest A (where the UAG DA server is). I am using Windows 2008 R2 Cross-Forest Autoenrollment (as per Microsoft Whitepaper) for forest B. My idea was to have a core forest with CA, UAG DA and other services and several other resource forests for PCs and Users.

    Is there a way to disable DS mapper feature ot UAG, so I can debug the issue?

    Petko

    Wednesday, April 14, 2010 8:00 PM
  • Hi Petko,

    Here's the information I've received:

    You need to ensure that the root CA certificates from the CA’s in the user account forest are in the NTAUTH store of the UAG DA forest.  From some previous mail threads CA’s from external forests are considered “third-party” from the forest security boundary.

    See http://support.microsoft.com/kb/295663

    Also, keep in mind that this is the case when the computer accounts are in a different forest than the DA server.

    HTH,

    Tom  


    MS ISDUA/UAG DA Anywhere Access Team
    Wednesday, April 14, 2010 10:41 PM
  • Hi Tom,

    Sorry, still no success.

    I have added a workstation in UAG DA server forest and IP-HTTPS works fine. So I'm sure now the problem is somewhere in the two forest scenario.

    My both Root and Operational CA are in the UAG DA forest. The computer accounts are in the other forest. (Forest A: Root CA, Operational CA, UAG DA, Forest B: Computers and Users).

    I read http://support.microsoft.com/kb/295663 and I think this is not the case. I checked the configuration and both CA certificates are in the NTAUTH store (adsi and regedit) of the DA forest and the Computers forest

    I have cross forest autoenrollment configured and working. Computer certificates are issued from the Operational CA in the UAG DA forest.

    Where is the "no usable certificate(s) found" evaluated? On the PC according to the DA certificate or by DA server? Maybe the Computer is not "happy" with Operational CA from the UAG DA forest?

    Regards,

    Petko

     

    Thursday, April 15, 2010 11:18 AM
  • I think it's more related to computer certificate mapping, as discussed in my Edge Man blog post, thought I can't say for sure.

    This is a supported scenario, as it doesn't fall outside our support boundaries statement, but it is an untested one. Given that the CA certificates are in the NTAUTH store on both sides of the trust, it makes me think it might be related to the mapping.

    Might be worth calling CSS on this one and logging a ticket.

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Friday, April 16, 2010 1:40 PM
  • Hi Tom,

    I found where the problem is and I think this is a BUG.

    Summary of the configuration:

    1. I have 2 Domains A and B in 2 Forests. A contains a UAG server and the CA, while B contans the users and computers.

    2. UAG is configured to support B domain clients for Direct Access.

    The problem:

    Direct Access HTTPS connection is not working for B member PCs, while all other methods Teredo and 6to4 work fine.

    Evaluation:

    1. I installed a computer named PC in domain A, it got certificate with cn=PC.A. HTTPS is working fine. (UAG reports in Iphlpsvc LOG that PC.A is connected)

    2. I moved PC from A to B (PC account in domain A is NOT disabled), it got certificate with cn=PC.B. HTTPS is working fine. (UAG reports in Iphlpsvc LOG that PC.A is connected)

    3. I renamed PC to WS, it got certificate with cn=WS.B. HTTPS keeps working. (UAG reports in Iphlpsvc LOG that PC.A is connected)

    4. I delete certificate PC.A from computer store and !!! HTTPS stoped working. (no usable certificate found).

    An other scenario is when instead of step 4, I disable the computer account of PC in domain A.HTTPS stops working.


    Conclusion:
    It appears that in this scenarion, UAG and DA Client are unable to target the right AD and that's why HTTPS is not working.
    Do you think this is a BUG or I am missing something?

    Best regards,
    Petko

     

    Thursday, July 8, 2010 5:09 PM
  • Hi Petko,

    This is not a bug, but most likely an issue with computer certificate mapping for the DA clients. When the DA client creates an IP-HTTPS connection with the UAG DirectAccess server, there is mutual certificate authentication. If the computer account doesn't belong to the same domain as the UAG DirectAccess server, then the computer side of the mutual authentication will fail.  The computer accounts need to belong to the domain that the UAG DA server belongs to because of this. The users and resources can belong to any domain or forest for which there is a bidirectional trust.

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Friday, July 9, 2010 1:22 PM
  • Hi Petko,

    This is not a bug, but most likely an issue with computer certificate mapping for the DA clients. When the DA client creates an IP-HTTPS connection with the UAG DirectAccess server, there is mutual certificate authentication. If the computer account doesn't belong to the same domain as the UAG DirectAccess server, then the computer side of the mutual authentication will fail.  The computer accounts need to belong to the domain that the UAG DA server belongs to because of this. The users and resources can belong to any domain or forest for which there is a bidirectional trust.

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team


    Hi Petko,

    OK, here's some more information I received:

    "I don't think there is any problem using cross-forest accounts as long as the UPN can be found in a trusted forest.  There is a flag which must be set to make GC query non-local forest but I don't think that is the issue.  More likely the certificate does not have correct UPN set for the computer account.  They need to check this (can dump the certificate using certutil) and also verify that the UPN listed works for cross-forest authentication.  They should be able to log into a Forest A machine using a Forest B UPN ("UserX.domainB.ForestB.local" not "domain\UserX")."

    Can you do a dump of the certficate using:

    certutil -store my

    Also, do you see authentication errors when trying to using IP-HTTPS in the Event Viewer in Domain A or B?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Monday, July 12, 2010 2:51 PM
  • Hi,

    I've dumped "certutil -story my" in the other thread.

    Yes, UPN is routed across the trust and works fine.

    No, I don't see any authentication errors on UAG or PC

    Petko

    Tuesday, July 13, 2010 3:04 PM
  • OK, thanks.

    Let's keep the rest of the discussion in the other thread so that when we figure it out, the answer will be there :)

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Wednesday, July 14, 2010 2:45 PM