locked
IPSec - Problem accessing the "DomainHRA" webapp : unauthorized RRS feed

  • Question

  • Hi

    I've followed the step by step guide but I find myself with a strange behavior : whenever the NAP client (Windows XP SP3) requests https://servername/domainhra/hcsrvext.dll to obtain a health certificate, it gets a 401.1 error (Unauthorized). Looking into the request logs of IIS I found this : 

    POST /domainhra/hcsrvext.dll - 443 - <ip_address> - NAP+IPSec+Enforcement+v1.0 401 2 5 9
    POST /domainhra/hcsrvext.dll - 443 - <ip_address> - NAP+IPSec+Enforcement+v1.0 401 1 2148074252 0

    IIS tells the client to authenticate (the virtual directory requires Windows Authentication) but no credentials seem to be sent. Which is weird as the failed requests logs show headers like this one, which tends to prove that the client do send authentication credentials :

    Accept: */*
    Authorization: NTLM
    TIRMTVNHSJKdjfghsSJDGFE........SGFsdfgsf==


    I tried the NAP virtual lab and found out the logs look like this : 

    POST /domainhra/hcsrvext.dll - 80 - 192.168.0.3 - NAP+IPSec+Enforcement+v1.0 401 2 5
    POST /domainhra/hcsrvext.dll - 80 WOODGROVEBANK\NY-CLI-1$ 192.168.0.3 - NAP+IPSec+Enforcement+v1.0 001 0 0

    The machine name is clearly listed in the last record...

    I don't know if it's a NAP or IIS issue but any help would be greatly appreciated.


    PS :

    - I disabled SSL but got the same error.
    - The client computer is of course a member of the domain
    - I checked the effective permissions on the domainhra directory for the client computer account and everything was ok
    - Using IE, I can log in with a standard domain user account (i get a 500 error which is normal as far as I know)
    Tuesday, May 27, 2008 12:46 PM

Answers

  • Hi,

     

    Thanks for the information. Can you please try the fix described in this article:

     

    http://support.microsoft.com/kb/871179

     

    Tell me if this helps. I realize this is for IIS 6.0 and not 7.0, but I think this might help.

     

    The article notes that it also applies to IIS 7.0 if one of these conditions are true:

    Kernel Mode Authentication is disabled.
    Kernel Mode Authentication is enabled, and the useAppPoolCredentials attribute is set to TRUE.

     

    You may wish to check these settings also.

     

    -Greg

    Wednesday, May 28, 2008 4:29 PM
  • Hi,

    Sorry for the delay in answering your last question.

    Previously, there was no support for IPsec between clients and a domain controller. There is now some support for Vista. As you noted, if you don't create an exemption for the DC, XP clients will be unable to get GP updates, etc. The behavior you've seen is normal. If you want specific details about how Vista clients interact with a DC over IPsec and what options are available, I will need to contact the IPsec team. Let me know.

    Thanks,

    -Greg

    Sunday, June 22, 2008 12:13 AM

All replies

  • I did some network analysis and found out everything goes fine up to the NTLM challenge. After that the client sends a bad response :

    NTLMSSP Data :

    ...
    NTLM Response : 00
    Domain Name: NULL
    User Name: NULL
    Host Name: <client_hostname>
    ...


    If I log in using IE with a standard domain account, I get :


    NTLMSSP Data :

    ...
    NTLM Response : <response_data>
    Domain Name: <ad_domain_name>
    User Name: <username>
    Host Name: <client_hostname>
    ...

    I don't want to blame the NAP client too quickly but it seems it's the source of the problem.
    Tuesday, May 27, 2008 1:54 PM
  • Tried with a 2nd XP SP3 machine (fresh install), same bahavior. I'll try with a Vista client tomorrow.
    Tuesday, May 27, 2008 4:56 PM
  • Hi,

     

    When you say you disabled SSL, do you mean you changed the URL to HTTP, or that you un-checked require SSL in IIS? What settings are you using for SSL? You can require SSL, but you must use the "ignore" client certificates setting.

     

    Make sure that you are using the FQDN of the HRA in the URL. If this isn't done, then SSL will fail.

     

    Please check event viewer and review event #21 on the client. It will say the client failed to acquire a certificate and provide an error code. Is this code 401.1? A code of 2147954575 indicates an SSL problem (such as not using FQDN for the HRA) and a code of 2147954444 indicates that IIS is requiring a client SSL certificate.

     

    -Greg

     

    Tuesday, May 27, 2008 6:29 PM
  • Hi

    I've completely cut SSL out of the loop, that is I disabled it on IIS (no cert, no binding at all, SSL options are greyed out) and changed the URL of the trusted server group (and of course verified the GPO was correctly applied on the client machines). I don't think SSL is my problem as I get the same behavior whether it's activated or not.

    I posted the wrong lines of the log file (it was the very first lines when my SSL conf was bad), sorry about that. I should have posted theses lines :

    POST /domainhra/hcsrvext.dll - 80 - <ip_address> - NAP+IPSec+Enforcement+v1.0 401 2 5 99
    POST /domainhra/hcsrvext.dll - 80 - <ip_address> - NAP+IPSec+Enforcement+v1.0 401 1 64 59

    Now, about the event viewer, the # is actually 20 and not 21. I checked the following page but found nothing about 401 errors :

    http://technet2.microsoft.com/windowsserver2008/en/library/cb783e0e-a55b-4013-98ad-b39c56d11f471033.mspx?mfr=true


    Wednesday, May 28, 2008 11:58 AM
  • Hi,

     

    Thanks for the information. Can you please try the fix described in this article:

     

    http://support.microsoft.com/kb/871179

     

    Tell me if this helps. I realize this is for IIS 6.0 and not 7.0, but I think this might help.

     

    The article notes that it also applies to IIS 7.0 if one of these conditions are true:

    Kernel Mode Authentication is disabled.
    Kernel Mode Authentication is enabled, and the useAppPoolCredentials attribute is set to TRUE.

     

    You may wish to check these settings also.

     

    -Greg

    Wednesday, May 28, 2008 4:29 PM
  • Hi

     

    Still no luck. I've tried various IIS configuration settings (service account for the AppPool, delegation trusts, SPNs, etc.) but nothing helped. Something's bothering me : if I disable NTLM, authentication doesn't even occur whether I use IE or napagent (IE is configured to support IWA) : the clients don't seem to accept the "WWW-Authenticate: Negociate" header...

     

    I'm installing Vista right now so I'll tell you if things get better.

    Thursday, May 29, 2008 3:31 PM
  •  

    I'm SO SO SO SO LAME.... Damn French to English translation !

     

    Instead of "cscript adsutils.vbs set w3svc/1/root/NTAuthenticationProviders "NegoTiate,NTLM" I wrote "NegoCiate,NTLM". In french the word is spelled with a "C" instead of the "T"....

     

    Now everything forks fine and I do get my health certificate via Kerberos authentication. However, there still seems to be a problem with NTLM negoTiation.

     

    Thanks for help, I'll be happy to continue testing NTLM if you thing it's worth it.

     

     

    Thursday, May 29, 2008 4:28 PM
  • Hi,

     

    Fantastic to hear that this is working now. I'm interested in any data you come up with on the problem. I've not run into this before and it's interesting that this workaround was required. Please let me know of anything you find out! I'll post as well if I find out more about this problem.

     

    Thanks,

    -Greg

     

    Thursday, May 29, 2008 6:16 PM
  •  Hi

    Good news (or maybe not ?), NTLM authentication works great with the Vista client. I really think the problem comes from the XP nap client (because NTLM does work with IE XP). When I have time I'll try to trace system API calls, maybe it'll help to understand how the nap client agent handles NTLM authentication. Are you interested in the network traces I've done (XP and Vista) ?

    Another question : I've noticed network trafic between the Vista client and the DC isn't secured. It's "normal" because there's no IPSec policy on the DC, but in regards to the FW policy on the Vista client I wonder why it accepts unsecured traffic. Is it a normal behavior ? On the XP clients I had to add a security rule to allow unsecured traffic with the DC. Not as straightforward as Vista, but safer if I may say. Sure that's not really an issue because the DC will eventually have IPSec enabled, but still...

    Friday, May 30, 2008 3:09 PM
  • Hi,

    Sorry for the delay in answering your last question.

    Previously, there was no support for IPsec between clients and a domain controller. There is now some support for Vista. As you noted, if you don't create an exemption for the DC, XP clients will be unable to get GP updates, etc. The behavior you've seen is normal. If you want specific details about how Vista clients interact with a DC over IPsec and what options are available, I will need to contact the IPsec team. Let me know.

    Thanks,

    -Greg

    Sunday, June 22, 2008 12:13 AM
  • You state:
    "Previously, there was no support for IPsec between clients and a domain controller. There is now some support for Vista."
    Where did you get this information? I am trying to set up client-to-domain controller access with Vista and Windows server 2008 but are unable to find and documentation regarding this. Any comments are apreciated.

    Friday, May 22, 2009 6:08 PM
  • Have a look at http://technet.microsoft.com/en-us/library/bb878097.aspx under Using IPsec Protection for Communication with a Domain Controller.

    -Greg


    Friday, May 22, 2009 6:13 PM
  • Thanks Greg.
    So should the following work then?

    Here is my scenario:
    Vista Client at home behind a NAT-T DSL router <--> file server and domain controller behind a ISA 2006 at office. All servers have public IP addresses. I am using IPSec with Certificates. I have added Kerberos record for my domain name to publicly available DNS.

    This is what is working so far:
    I am able to open shares on the fileserver without problems. I can see the SA entries between the client and file server in advfw. All good.

    What I would like to be able to do now, while at home, is running the logon process (logon scripts gpo updates aso) as if I was logging in while at the office.

    My ISP blocks 445 and it seems like this is a problem when trying to access the domain controller? At least that is what the diagnostics message returns after the connection to the domain controller fails. How can this be? Is not 445 against domain controllers secured by IPSEC? Access to the file server passes over the same line without problems.

    Any hints is appreciated.


    Buster
    Friday, May 22, 2009 8:22 PM
  • Hi Buster,

    This question might be a little more than I can help with, but it sounds like the ISP will block port 445 regardless of any IPsec policies. Unless I misunderstand the scenario, you can't bypass the ISP firewall unless you have something like a VPN connection that drills through it. I wish I could be more help.

    I assume you've tried to connect to the DC to confirm NAT (and PAT) is working. It's a little surprising to me that your DC would have a public address.

    -Greg
    Friday, May 22, 2009 8:34 PM
  • But can the FW really see that the TCP header contains port 445? Is not the payload of the IP packet cryptic to the firewall? What is it that I do not understand here :) The 445 traffic to the file servers are going through? I thought that might be due to the payload of the IP packet being cryptic to the fw? And that some of the traffic going to the domain controller needs to be in clear?


    Buster
    Friday, May 22, 2009 8:50 PM