locked
NAP IPsec - Accept only health certificates RRS feed

  • Question

  • Hello, I am having a small issue with getting NAP via IPsec working.  All systems are Windows Server 2008 R2 or Windows 7/Vista (so no Windows Server 2003 or XP related issues here).  I have a root CA that handles day to day certificate requests (including giving a standard Computer Certificate to all systems, plus IIS certificates, etc.).  After that, I have two subordinate PKI's/HRA/NPS servers for handling NAP requests (two are redundency).  To achive redundency in the configuration, I have configured my IPsec First Authentication to be Computer Ceritifcate, type Root CA, pointing to my root CA, but with the "Accept only health certificates" box checked.  From what I can tell, that checkbox isn't fully working.  I am working with two clients, both clients are set to Require in, request out, but when client one goes non-compliant it gets wierd.  With client one not-compliant, the health certificate is revoked, and client one cannot talk to client two (as expected).  However, for some wierd reason, client two can still communicate to client one just fine.  What is happening is, client two is establishing a trust with client one based on client one's standard computer certificate (NOT a health certificate) from the root CA.  That is what should not be happening.  Again, client one is configured to require inbound communication, so without the health certificate, communication should fail.  If I delete the standard computer certificate on client one, THEN inbound communication is finally blocked while the machine is non-compliant (as it now as no certificates of any kind).  That is where the issue.

    To summerize, it appears the "accept only health certificates" feature is not fully working.  It works as expected when client one (who is not-compliant) is attempting to communicate out to client two, it fails (and it does NOT allow it to use the standard computer certificate, which is good).  However, client two can connect to client one inbound via IPsec using client one's standard computer certificate (which is bad).  Any thoughts to why this is happening?  Thanks!

    Tuesday, September 14, 2010 1:23 PM

Answers

  • Hi,

    If you have the policy of require in/require out then there must be a valid health cert on both sides. However, if your policy is only requesting health for outgoing communications, then the healthy computer will allow itself to send packets to an unhealthy computer, assuming that it first initiated the communication.

    Both computers have the same policy applied all the time and this never changes. The only thing that changes is that when one of the computers loses a health certificate then it can no longer initiate communications because all the other computers on the network require that it authenticate with a health certificate when they see inbound communications from it. Since it has no certificate, this fails.

    When the unhealthy computer sees an inbound communication request from a healthy computer, it again requires authentication with a health certificate. This succeeds because the computer sending packets has a health certificate. The healthy computer also requested a health certificate on the other side of the (outbound) connection, but it will allow the communication even though this fails because it was only a request and not a demand.

    I hope this makes sense. I know it is confusing.

    -Greg

    Tuesday, September 14, 2010 8:08 PM
  • Hi,

    This is a good question. I am afraid the answer may not be as logical this time though. 

    Keep in mind that when the behavior was first designed (for XP SP3 and Vista with no service pack) it did not allow the communication whether the unhealthy computer had a computer certificate or no certificate at all. Both cases were denied. This then changed with Vista SP1.

    With this fact in mind, we have to conclude that it cannot be a logical rule. Otherwise, it would work the same for all operating systems and service packs. After all, there is nothing in the rule that specifies service pack.

    So, the answer is simply that this is the behavior that was encoded. Based only on how the rule is written, the communication should still be allowed when the destination has no certificate at all. However, a decision was made that this should only be allowed for domain member computers (with a computer certificate). So, the rule in this case doesn't work exactly as you would expect.

    -Greg

    Tuesday, September 14, 2010 8:49 PM

All replies

  • Hi,

    I am not sure if I understand the problem based on your description. It sounds like things are working correctly.

    Require in, request out means that if client1 has no health cert and client2 does have a health cert, then client1 will not refuse a communication from client1 - because the incoming request comes from a computer that has a health cert. The only thing that should fail is when client1 initiates the communication.

    Client1 (no cert) ---> Client2 (health cert) is not allowed.

    Client2 (health cert) ---> Client1 (no cert) is allowed.

    This is what is happening, right? In a nutshell, an unhealthy computer will not refuse all communications. It will allow communication if it is initiated from a healthy computer. There is a table here: http://technet.microsoft.com/en-us/library/dd125389(WS.10).aspx that is slightly out of date because it was written to describe XP and Vista only, but Windows7 should be the same as Vista SP1

    Note on the table that it says that if the source has a health cert and the destination has a computer cert, the communication is allowed.

    -Greg

    Tuesday, September 14, 2010 7:34 PM
  • By the way, you will see the superscript B on that particular line of the table. This is because the behavior is different for this particular case depending on the OS you use and the service packs installed.

    Windows 7 will behave like Vista SP1.

    Vista with no service packs and XP behave the same (differently than Windows 7 or Vista SP1).

    If you were attempting the test described in your post with XP computers or Vista without a service pack, it would fail. This behavior was changed on purpose starting with Vista SP1.

    Tuesday, September 14, 2010 7:39 PM
  • Greg, thanks for the reply!  It was my understanding that in order for IPsec to work with certificate based authenication, there has to be a valid certificate on both sides of the communication.  Is that correct?  If so, shouldn't a health certificate be required on both sides with require set on inbound communication?  What I am seeing is similar to what you are saying.  I am running Vista SP2 and 7, so they should behave the same.

    Client1 (no cert) --> Client2 (health cert) is not allowed

    Client2 (health cert) --> Client1 (nocert) is not allowed

    Client2 (health cert) --> Client1 (no health cert, but does contain a standard computer certificate (machine template)) is allowed.  (this is the part I thought would be denied since i am only accepting health certificates?)

    Client1 (no health cert, but does contain a standard computer certificate (machine template) --> Client2 (health cert) is not allowed

    If Client1 is requiring inbound communction, but has it's health certificate revoked, then it can't make an IPsec connection with Client2, is that correct?

    Does that make sense?  Let me know, thanks!

    Tuesday, September 14, 2010 7:55 PM
  • Hi,

    If you have the policy of require in/require out then there must be a valid health cert on both sides. However, if your policy is only requesting health for outgoing communications, then the healthy computer will allow itself to send packets to an unhealthy computer, assuming that it first initiated the communication.

    Both computers have the same policy applied all the time and this never changes. The only thing that changes is that when one of the computers loses a health certificate then it can no longer initiate communications because all the other computers on the network require that it authenticate with a health certificate when they see inbound communications from it. Since it has no certificate, this fails.

    When the unhealthy computer sees an inbound communication request from a healthy computer, it again requires authentication with a health certificate. This succeeds because the computer sending packets has a health certificate. The healthy computer also requested a health certificate on the other side of the (outbound) connection, but it will allow the communication even though this fails because it was only a request and not a demand.

    I hope this makes sense. I know it is confusing.

    -Greg

    Tuesday, September 14, 2010 8:08 PM
  • Greg, that makes a lot of sense (and is very helpful), thanks.  I do still have an anomaly however, assuming everything you mentioned above, why does this happen: Client2 (health cert) --> Client1 (nocert) is not allowed.  Client2 is only able to talk to Client1 while it is non-compliant (with no health certificate) if Client1 has an additional standard non-health computer (machine) certificate.  Why is this happening?  With my require in/request out, based on your info above, Client2 has a health cert, so it should be able to initiate a connection to client1 (who has no certificates), but it is unable to do that.  It sounds to me, it shouldn't matter whether or not client1 has a standard computer (non-health) certificate or not.  That certificate should not be useable in IPsec and should play no factor, but that doesn't appear to be the case.  Thoughts?

    Tuesday, September 14, 2010 8:22 PM
  • Hi,

    This is a good question. I am afraid the answer may not be as logical this time though. 

    Keep in mind that when the behavior was first designed (for XP SP3 and Vista with no service pack) it did not allow the communication whether the unhealthy computer had a computer certificate or no certificate at all. Both cases were denied. This then changed with Vista SP1.

    With this fact in mind, we have to conclude that it cannot be a logical rule. Otherwise, it would work the same for all operating systems and service packs. After all, there is nothing in the rule that specifies service pack.

    So, the answer is simply that this is the behavior that was encoded. Based only on how the rule is written, the communication should still be allowed when the destination has no certificate at all. However, a decision was made that this should only be allowed for domain member computers (with a computer certificate). So, the rule in this case doesn't work exactly as you would expect.

    -Greg

    Tuesday, September 14, 2010 8:49 PM
  • Greg, thanks for the information!  I feel a lot better now knowing that it is working the way it is suppose to.  Not knowing the information you provided left gaps and made me think I had some problems since it doesn't work exactly as I would expect.  It all makes sense now, thanks a lot!
    Tuesday, September 14, 2010 9:08 PM