locked
802.1X: Control Flow RRS feed

  • Question

  • I don't completely understand the control flow of 802.1X and didn't find documentation:
    At what time is it possible to check the compliance of a client during the boot process of a machine? Is it possible to check before a user logs in or only after login or does it depend on the checks (as in Cisco NAC)? I managed to check compliance using a HCS before login, but not with 802.1X only. Can someone clarify this? Thank you.

    Friday, February 23, 2007 4:06 PM

Answers

  • While discussing with a co-working, I had somewhat of an 'aha' moment.  I'd remembered a discussion recently about an issue similar to this, and he remembered that there were (on past builds) some issues around fast-reconnect and health checks.  We did some investigations and changes around that area recently, and most likely these are not in the TAP-available builds.

    Can you tell me whether you are testing with 'fast-reconnect' enabled or not?

    My thoughts are that if you un-check the fast reconnect settings on both sides, that you will start seeing the behavior you expect to see.  Please let us know.

    -Chris

    Chris.Edson@online.microsoft.com *
    SDET, Network Access Protection
    * Remove the "online" make the address valid.
    ** This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, February 28, 2007 10:12 PM

All replies

  • 802.1x authentication (and our PEAP implementation, specifically) can be configured to perform either User authentication or Machine authentication.

    In order to complete user authentication, a user must be logged on to the machine, so that the authentication process has a set of user credentials to work with.

    If you configure the machine to perform machine authentication (by provisioning it with a machine certificate for PEAP-TLS, or by letting it use the machine's password for PEAP-MSCHAPv2), then the machine will be able to complete authentication prior to user logon.

    For Network Access Protection using 802.1x and PEAP, the health evaluation is considered a machine-level process; so you can indeed check the machine's health and make a decision for network access prior to any users logging on to the machine.  However, should anything need remediated that requires user input, then automatic remediation will not happen.

    You can set 802.1x and PEAP to utilize machine authentication by configuring the settings in Group Policy for the Wired AutoConfiguration Service or the Wireless AutoConfiguration Service, depending on which you are using.  This Group Policy would then need to be applied to the clients in question.

    -Chris

    Chris.Edson@online.microsoft.com *
    SDET, Network Access Protection
    * Remove the "online" make the address valid.
    ** This posting is provided "AS IS" with no warranties, and confers no rights.

    Saturday, February 24, 2007 12:18 AM
  • Thank you very much for your answer Chris.
    What I did so far is: I configured 802.1X authentication following mainly the Longhorn Step-by-Sep Guide "Demonstrate 802.1X ...". The settings for user authentication (PEAP with certificates). I configured the security settings in GP Wired Network Policies:
    - Protected EAP with certificates (enable quarantine checks)
    - Authentication method = user re-authentication

    System Log (Event Viewer):

    Pre-Login:

    User host/VISTACLIENT.trivadis-naplab.com was granted access.
     Fully-Qualified-User-Name = trivadis-naplab.com/IPSec Secure/VISTACLIENT
     Machine-Name = <not present>
     OS-Version = <not present>
     Fully-Qualified-Machine-Name=<undetermined>
     NAS-IP-Address = 10.0.60.1
     NAS-IPv6-Address = <not present>
     NAS-Identifier = <not present>
     Client-Friendly-Name = Switch
     Client-IP-Address = 10.0.60.1
     Client-IPv6-Address = <not present>
     Calling-Station-Identifier = 00-15-58-80-01-83
     NAS-Port-Type = Ethernet
     NAS-Port = 50012
     Proxy-Policy-Name = Require Protected EAP
     Policy-Name = Domain-Joined-Machine
     Authentication-Provider = Windows
     Authentication-Server = NPS1.trivadis-naplab.com
     Authentication-Type = PEAP
     EAP-Type = Smart Card or other certificate
     Account-Session-Identifier=<not present>
     Quarantine-State=Full Access


    Machine <not present> was given full access.
     OS-Version = <not present>
     Fully-Qualified-Machine-Name = <undetermined>
     Fully-Qualified-User-Name = trivadis-naplab.com/IPSec Secure/VISTACLIENT
     NAS-IP-Address = 10.0.60.1
     NAS-IPv6-Address = <not present>
     NAS-Identifier = <not present>
     Called-Station-Identifier = 00-19-30-74-EB-8C
     Calling-Station-Identifier = 00-15-58-80-01-83
     Account-Session-Identifier = <not present>
     Proxy-Policy-Name = Require Protected EAP
     Policy-Name = Domain-Joined-Machine
     Quarantine-Session-Identifier = <undetermined>
     Quarantine-System-Health-Result = <undetermined>


    User TRIVADIS-NAPLAB\VISTACLIENT$ was granted access.
     Fully-Qualified-User-Name = trivadis-naplab.com/IPSec Secure/VISTACLIENT
     Machine-Name = <not present>
     OS-Version = <not present>
     Fully-Qualified-Machine-Name=<undetermined>
     NAS-IP-Address = 10.0.60.1
     NAS-IPv6-Address = <not present>
     NAS-Identifier = <not present>
     Client-Friendly-Name = Switch
     Client-IP-Address = 10.0.60.1
     Client-IPv6-Address = <not present>
     Calling-Station-Identifier = 00-15-58-80-01-83
     NAS-Port-Type = Ethernet
     NAS-Port = 50012
     Proxy-Policy-Name = Require Protected EAP
     Policy-Name = Domain-Joined-Machine
     Authentication-Provider = Windows
     Authentication-Server = NPS1.trivadis-naplab.com
     Authentication-Type = PEAP
     EAP-Type = Smart Card or other certificate
     Account-Session-Identifier=<not present>
     Quarantine-State=Full Access

    Machine <not present> was given full access.
     OS-Version = <not present>
     Fully-Qualified-Machine-Name = <undetermined>
     Fully-Qualified-User-Name = trivadis-naplab.com/IPSec Secure/VISTACLIENT
     NAS-IP-Address = 10.0.60.1
     NAS-IPv6-Address = <not present>
     NAS-Identifier = <not present>
     Called-Station-Identifier = 00-19-30-74-EB-8C
     Calling-Station-Identifier = 00-15-58-80-01-83
     Account-Session-Identifier = <not present>
     Proxy-Policy-Name = Require Protected EAP
     Policy-Name = Domain-Joined-Machine
     Quarantine-Session-Identifier = <undetermined>
     Quarantine-System-Health-Result = <undetermined>


    Post-Login:




    User employee@trivadis-naplab.com was granted access.
     Fully-Qualified-User-Name = trivadis-naplab.com/Accounts/employee
     Machine-Name = VISTACLIENT.trivadis-naplab.com
     OS-Version = 6.0.6000 0.0 x86 Workstation
     Fully-Qualified-Machine-Name=TRIVADIS-NAPLAB\VISTACLIENT$
     NAS-IP-Address = 10.0.60.1
     NAS-IPv6-Address = <not present>
     NAS-Identifier = <not present>
     Client-Friendly-Name = Switch
     Client-IP-Address = 10.0.60.1
     Client-IPv6-Address = <not present>
     Calling-Station-Identifier = 00-15-58-80-01-83
     NAS-Port-Type = Ethernet
     NAS-Port = 50012
     Proxy-Policy-Name = Require Protected EAP
     Policy-Name = Compliant-Employee
     Authentication-Provider = Windows
     Authentication-Server = NPS1.trivadis-naplab.com
     Authentication-Type = PEAP
     EAP-Type = Smart Card or other certificate
     Account-Session-Identifier=<not present>
     Quarantine-State=Full Access


    Machine VISTACLIENT.trivadis-naplab.com was given full access.
     OS-Version = 6.0.6000 0.0 x86 Workstation
     Fully-Qualified-Machine-Name = TRIVADIS-NAPLAB\VISTACLIENT$
     Fully-Qualified-User-Name = trivadis-naplab.com/Accounts/employee
     NAS-IP-Address = 10.0.60.1
     NAS-IPv6-Address = <not present>
     NAS-Identifier = <not present>
     Called-Station-Identifier = 00-19-30-74-EB-8C
     Calling-Station-Identifier = 00-15-58-80-01-83
     Account-Session-Identifier = <not present>
     Proxy-Policy-Name = Require Protected EAP
     Policy-Name = Compliant-Employee
     Quarantine-Session-Identifier = {171BF986-14E5-471B-95E7-9F3DF9A7A038} - 2007-02-26 17:11:00.446Z
     Quarantine-System-Health-Result =
    Windows Security Health Validator

        Compliant
        None
        (0x0-)
        (0x0-)
        (0x0-)
        (0x0-)
        (0x0-)
        (0x0-)
        (0x0-)
        (0x0-)




    So there are two authentication steps before a user is logged in (machine authentication  with certificates)  - but without any compliance check.  If a add the condition 'Computer Health matches compliant' to the 'Domain-Joined-Machine Policy' (the policy that is matched before a user logs in), the policy doesn't match anymore. So it seems impossible to do compliance checks before user login with my settings. Is this a problem with my settings (but I can't see what I can do more than checking 'enable quarantine checks) ,with the supplicant or with the server?

    EDIT: If I use MSCHAPv2 as inner authentication method, there's no compliance check before user login either. But if I disconnect the machine and reconnect it again before user login, another authentication is performed (as expected) AND a compliance check is performed. This seems very strange to me.

    2) Is it possible to bind machine and user authentication together by doing user and machine authentication in a single 802.1X exchange or binding two EAP exchanges cryptographically together, i.e.  to have a policy that assigns a user A on a domain-joined machine to VLAN A, user B on a domain-joined machine to VLAN B and a user A/B on a non-domain-joined machine to VLAN C (where both machine and user are authenticated)?

    3) If no policy matches before user login, access is denied with my settings. After a user logs in
    there is no re-authentication. Only after disconnecting and connecting again the user gets authenticated and the machine gets access. Shouldn't the supplicant trigger a new authentication after the user is logged in?

    Thanks in advance for an explanation.





    Sunday, February 25, 2007 1:40 PM
  • My understanding is that the default 802.1x configuration will, in the absence of user data, attempt to perform machine authentication if possible.  I'm not sure what the default settings for that 'fallback' machine authentication are, however.  Perhaps I can get one of the 1x team members to take a look at this thread.

    If you configure the machine to do only machine authentication (via GP, or per client machine adapter per the instructions on this thread: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=761315&SiteID=17), then you can do health checks with all machine authentications, whether a user is logged on the machine or not.

    With respect to #3, a new user logon event >should< re-trigger authentication; I'm not sure why it isn't.  Again, I'll see if I can get one of the 1x team members to read up and perhaps provide more insight into the intricacies of 802.1x.  :)

    -Chris

    Chris.Edson@online.microsoft.com *
    SDET, Network Access Protection
    * Remove the "online" make the address valid.
    ** This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, February 27, 2007 1:29 AM
  • Thank you very much for your answer - but we're still not able to solve our problem. We tried all possible settings via GP, i.e. computer only, user authentication, user re-authentication (all with 'enable quarantine checks'). With none of them we are able to get compliance information from Windows Security Health Validator before user login. The behavior with the different settings is the following:

    1)User re-authentication:

    Before user login: no compliance check
    Re-authentication triggered by user login
    After user login there's user authentication and compliance check.

    Here the above mentioned behavior is reproducible: with MSCHAPv2 as inner authentication method, disconnecting and reconnecting of the machine before user login triggers a re-authentication including a compliance check.

    2)Computer only:

    Before Login: authentication, but no compliance check
    User login doesn't trigger re-authentication.


    3)User only:
    After Login: user authentication and compliance check.

    We would appreciate very much if someone could explain if the described behavior is correct (i.e. we somehow misunderstand the regular control flow of port authentication with Vista and have to adapt our network access policies to do compliance check only after user login) or if something is wrong with our settings.


    Thanks in advance for explanations.


    Tuesday, February 27, 2007 11:28 AM
  • Part of what you could be seeing at boot time (when you see 2 authentication attempts before login) is an artifact of the fact that the 802.1x service comes up before the NAP Agent service - so you will see 1 authentication with no health data available, followed by another authentication once the NAP Agent starts up.  So you should see health data exchanged in the second authentication if the connection is properly configured.

    So for #1 - you mention disconnecting and reconnecting - and then you get a compliance check - does this mean that it is doing machine authentication + compliance check on the authentication after you disconnect/reconnect?   As mentioned above, you should see health exchange once the NAP Agent finishes starting, and in fact the NAP Agent is what initiates the re-authentication.

    For #2 - no, user login would not re-trigger authentication, as there is no credentials change.  As for why compliance checks aren't happening - I'd have to know more about the configuration.

    Are you configuring your connection settings exclusively via Group Policy?

    -Chris

    Chris.Edson@online.microsoft.com *
    SDET, Network Access Protection
    * Remove the "online" make the address valid.
    ** This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, February 27, 2007 8:28 PM
  • I agree that there should be no re-authentication after user login in #2. I can also understand the second authentication before longin (after necessary services come up). The only thing I don't understand with the described behavior is why there is no health check before user login.

    The configuration for connection settings I do exclusively via Group Policy (but actually we tried with local settings as well before).

    ...does this mean that it is doing machine authentication + compliance check on the authentication after you disconnect/reconnect?...

    I think, yes, it does machine authentication + compliance check on the authentication after disconnect/reconnect. The only difference I can see in the NPS-Log to the authentication that happens before dis-/reconnect is that it says "Machine VISTACLIENT.trivadis-naplab.com was given full access" instead of "Machine not present...". What I can see from the NPS log is the following:

    Booting (before user login):

    User host/VISTACLIENT.trivadis-naplab.com was granted access.
    Fully-Qualified-User-Name = trivadis-naplab.com/Accounts/IPSec Secure/VISTACLIENT
    Machine-Name = <not present>
    OS-Version = <not present>
    Fully-Qualified-Machine-Name=<undetermined>
    NAS-IP-Address = 10.0.60.1
    NAS-IPv6-Address = <not present>
    NAS-Identifier = <not present>
    Client-Friendly-Name = Switch
    Client-IP-Address = 10.0.60.1
    Client-IPv6-Address = <not present>
    Calling-Station-Identifier = 00-15-58-80-01-83
    NAS-Port-Type = Ethernet
    NAS-Port = 50012
    Proxy-Policy-Name = Require Protected EAP
    Policy-Name = Unknown
    Authentication-Provider = Windows
    Authentication-Server = NPS1.trivadis-naplab.com
    Authentication-Type = PEAP
    EAP-Type = Secured password (EAP-MSCHAP v2)
    Account-Session-Identifier=<not present>
    Quarantine-State=Full Access


    Machine <not present> was given full access.
    OS-Version = <not present>
    Fully-Qualified-Machine-Name = <undetermined>
    Fully-Qualified-User-Name = trivadis-naplab.com/Accounts/IPSec Secure/VISTACLIENT
    NAS-IP-Address = 10.0.60.1
    NAS-IPv6-Address = <not present>
    NAS-Identifier = <not present>
    Called-Station-Identifier = 00-19-30-74-EB-8C
    Calling-Station-Identifier = 00-15-58-80-01-83
    Account-Session-Identifier = <not present>
    Proxy-Policy-Name = Require Protected EAP
    Policy-Name = Unknown
    Quarantine-Session-Identifier = <undetermined>
    Quarantine-System-Health-Result = <undetermined>



    User TRIVADIS-NAPLAB\VISTACLIENT$ was granted access.
    Fully-Qualified-User-Name = trivadis-naplab.com/Accounts/IPSec Secure/VISTACLIENT
    Machine-Name = <not present>
    OS-Version = <not present>
    Fully-Qualified-Machine-Name=<undetermined>
    NAS-IP-Address = 10.0.60.1
    NAS-IPv6-Address = <not present>
    NAS-Identifier = <not present>
    Client-Friendly-Name = Switch
    Client-IP-Address = 10.0.60.1
    Client-IPv6-Address = <not present>
    Calling-Station-Identifier = 00-15-58-80-01-83
    NAS-Port-Type = Ethernet
    NAS-Port = 50012
    Proxy-Policy-Name = Require Protected EAP
    Policy-Name = Unknown
    Authentication-Provider = Windows
    Authentication-Server = NPS1.trivadis-naplab.com
    Authentication-Type = PEAP
    EAP-Type = Smart Card or other certificate
    Account-Session-Identifier=<not present>
    Quarantine-State=Full Access


    Machine <not present> was given full access.
    OS-Version = <not present>
    Fully-Qualified-Machine-Name = <undetermined>
    Fully-Qualified-User-Name = trivadis-naplab.com/Accounts/IPSec Secure/VISTACLIENT
    NAS-IP-Address = 10.0.60.1
    NAS-IPv6-Address = <not present>
    NAS-Identifier = <not present>
    Called-Station-Identifier = 00-19-30-74-EB-8C
    Calling-Station-Identifier = 00-15-58-80-01-83
    Account-Session-Identifier = <not present>
    Proxy-Policy-Name = Require Protected EAP
    Policy-Name = Unknown
    Quarantine-Session-Identifier = <undetermined>
    Quarantine-System-Health-Result = <undetermined>


    After Disconnecting and reconnecting again:

    User host/VISTACLIENT.trivadis-naplab.com was granted access.
    Fully-Qualified-User-Name = trivadis-naplab.com/Accounts/IPSec Secure/VISTACLIENT
    Machine-Name = VISTACLIENT.trivadis-naplab.com
    OS-Version = 6.0.6000 0.0 x86 Workstation
    Fully-Qualified-Machine-Name=TRIVADIS-NAPLAB\VISTACLIENT$
    NAS-IP-Address = 10.0.60.1
    NAS-IPv6-Address = <not present>
    NAS-Identifier = <not present>
    Client-Friendly-Name = Switch
    Client-IP-Address = 10.0.60.1
    Client-IPv6-Address = <not present>
    Calling-Station-Identifier = 00-15-58-80-01-83
    NAS-Port-Type = Ethernet
    NAS-Port = 50012
    Proxy-Policy-Name = Require Protected EAP
    Policy-Name = Authenticated Computers
    Authentication-Provider = Windows
    Authentication-Server = NPS1.trivadis-naplab.com
    Authentication-Type = PEAP
    EAP-Type = Secured password (EAP-MSCHAP v2)
    Account-Session-Identifier=<not present>
    Quarantine-State=Full Access



    Machine VISTACLIENT.trivadis-naplab.com was given full access.
    OS-Version = 6.0.6000 0.0 x86 Workstation
    Fully-Qualified-Machine-Name = TRIVADIS-NAPLAB\VISTACLIENT$
    Fully-Qualified-User-Name = trivadis-naplab.com/Accounts/IPSec Secure/VISTACLIENT
    NAS-IP-Address = 10.0.60.1
    NAS-IPv6-Address = <not present>
    NAS-Identifier = <not present>
    Called-Station-Identifier = 00-19-30-74-EB-8C
    Calling-Station-Identifier = 00-15-58-80-01-83
    Account-Session-Identifier = <not present>
    Proxy-Policy-Name = Require Protected EAP
    Policy-Name = Authenticated Computers
    Quarantine-Session-Identifier = {171BF986-14E5-471B-95E7-9F3DF9A7A038} - 2007-02-28 09:18:09.381Z
    Quarantine-System-Health-Result =
    Windows Security Health Validator

    Compliant
    None
    (0x0-)
    (0x0-)
    (0x0-)
    (0x0-)
    (0x0-)
    (0x0-)
    (0x0-)
    (0x0-)

    After user login:

    User TRIVADIS-NAPLAB\manager was granted access.
    Fully-Qualified-User-Name = trivadis-naplab.com/Accounts/Management/Manager
    Machine-Name = VISTACLIENT.trivadis-naplab.com
    OS-Version = 6.0.6000 0.0 x86 Workstation
    Fully-Qualified-Machine-Name=TRIVADIS-NAPLAB\VISTACLIENT$
    NAS-IP-Address = 10.0.60.1
    NAS-IPv6-Address = <not present>
    NAS-Identifier = <not present>
    Client-Friendly-Name = Switch
    Client-IP-Address = 10.0.60.1
    Client-IPv6-Address = <not present>
    Calling-Station-Identifier = 00-15-58-80-01-83
    NAS-Port-Type = Ethernet
    NAS-Port = 50012
    Proxy-Policy-Name = Require Protected EAP
    Policy-Name = Compliant-Manager
    Authentication-Provider = Windows
    Authentication-Server = NPS1.trivadis-naplab.com
    Authentication-Type = PEAP
    EAP-Type = Secured password (EAP-MSCHAP v2)
    Account-Session-Identifier=<not present>
    Quarantine-State=Full Access


    Machine VISTACLIENT.trivadis-naplab.com was given full access.
    OS-Version = 6.0.6000 0.0 x86 Workstation
    Fully-Qualified-Machine-Name = TRIVADIS-NAPLAB\VISTACLIENT$
    Fully-Qualified-User-Name = trivadis-naplab.com/Accounts/Management/Manager
    NAS-IP-Address = 10.0.60.1
    NAS-IPv6-Address = <not present>
    NAS-Identifier = <not present>
    Called-Station-Identifier = 00-19-30-74-EB-8C
    Calling-Station-Identifier = 00-15-58-80-01-83
    Account-Session-Identifier = <not present>
    Proxy-Policy-Name = Require Protected EAP
    Policy-Name = Compliant-Manager
    Quarantine-Session-Identifier = {171BF986-14E5-471B-95E7-9F3DF9A7A038} - 2007-02-28 09:28:32.060Z
    Quarantine-System-Health-Result =
    Windows Security Health Validator

    Compliant
    None
    (0x0-)
    (0x0-)
    (0x0-)
    (0x0-)
    (0x0-)
    (0x0-)
    (0x0-)
    (0x0-)

    Actually, I can't see what settings I could change apart from 'enable quarantine checks' (all necessary services seem to be running - as compliance checks work after login).
    Please let me know what configuration settings for you would be helpful to analyse the problem.

    Thanks in advance for your help.



    Wednesday, February 28, 2007 9:47 AM
  • While discussing with a co-working, I had somewhat of an 'aha' moment.  I'd remembered a discussion recently about an issue similar to this, and he remembered that there were (on past builds) some issues around fast-reconnect and health checks.  We did some investigations and changes around that area recently, and most likely these are not in the TAP-available builds.

    Can you tell me whether you are testing with 'fast-reconnect' enabled or not?

    My thoughts are that if you un-check the fast reconnect settings on both sides, that you will start seeing the behavior you expect to see.  Please let us know.

    -Chris

    Chris.Edson@online.microsoft.com *
    SDET, Network Access Protection
    * Remove the "online" make the address valid.
    ** This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, February 28, 2007 10:12 PM
  • Fast Reconnect is enabled by default on the NPS Policies. I bet you're right. Can you try with this setting disabled?

     

    NAP the World in 2007,

    Jeff Sigman
    NAP Release Manager
    Jeff.Sigman@online.microsoft.com *
    http://blogs.technet.com/nap

    * Remove the "online" to actually email me.
    ** This posting is provided "AS IS" with no warranties, and confers no rights.

     

    Wednesday, February 28, 2007 10:20 PM
  • Thanks a lot for your help Chris:
    I  disabled 'fast-reconnect' on both sides and health-checks work like expected - I actually never thought that 'fast-reconnect' could have something to do with this.
    Friday, March 2, 2007 8:27 AM
  • Actually, it shouldn't have the effect you observed. 

    However, as I mentioned previously, we made some changes around how fast-reconnect and NAP health checks interact (fast-reconnect shortcuts portions of the authentication by using a token that the server passes back in the initial connect), as they weren't behaving properly in previous test builds.

    For now, leave fast-reconnect unchecked.

    -Chris

    Chris.Edson@online.microsoft.com *
    SDET, Network Access Protection
    * Remove the "online" make the address valid.
    ** This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, March 2, 2007 6:18 PM