locked
windows visa with wired autoconfig service turned off NOT reported as Non-Nap capable. RRS feed

  • Question

  • As we were in the process of making MAC address exclusion for guest desktops. We tried to stop the wired autoconfig service on existing vista desktop and we found that it is not comming into any rule group and not reported in NAP text log file and/or events. however computer is landed into quarantine zone without the processing of NPS server.

    Switch actually leads the desktop to quarantine zone having it remained unauthenticated from NPS server.

    Turning the service off should render it as non nap capable ?

    Is there something wrong with the config ? we found that we have only one type of authentication configured in connection request policy and that is "PEAP". should we try to tick on allow devices with no authentication method negotiated or what ? or allow machine health check only ?

     

    PLZ dont' direct us to documenation we know each piece of it already. Kindly provide specific answer to above and that would be apprecaited.


    Shahid Roofi
    Tuesday, June 7, 2011 4:21 PM

All replies

  • Hi SHahid,

     

    Thanks for posting here.

     

    > Turning the service off should render it as non nap capable ?

    It seems that you are using 802.1x wired authentication enforcement in this environment right now. If in this case , the wired autoconfig service should never be stopped. Otherwise, client computer will unable to pass the authentication and will also be quarantined as a no-capable computer by the network enforcement.

     

    Wired AutoConfig service

    The Wired AutoConfig service (dot3svc) is responsible for connectivity and the client-side components of Layer Two authentication over Ethernet connections. The Wired AutoConfig service listens for 802.3 media connectivity and identifies whether Layer Two authentication is required. When Layer Two authentication is required, 802.1X authentication is performed on the specified Ethernet interface

     

    Not sure if you have read ,but a workaround you may try is that creating a new policy and setting Calling-Station-ID attribute for redirecting the computers which has the defined MAC address to the guest or proper VLAN:

     

    MAC Address Authorization

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

     

    Thanks.

     

    Tiger Li

     

    TechNet Subscriber Support in forum

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


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Wednesday, June 8, 2011 4:08 AM
  • Hi Shahid,

    Please feel free to let us know if the information was helpful to you.

    Thanks,

    Tiger Li

    TechNet Subscriber Support in forum
    If you have any feedback on our support, please contact tngfb@microsoft.com


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Friday, June 10, 2011 9:03 AM

  • ------------------------------------------------------------  What you've written  

    > Turning the service off should render it as non nap capable ?

    It seems that you are using 802.1x wired authentication enforcement in this environment right now. If in this case , the wired autoconfig service should never be stopped. Otherwise, client computer will unable to pass the authentication and will also be quarantined as a no-capable computer by the network enforcement.

    ----------------------------------------------

     

      Thanx for repeating my question brother now both of us agree that client computer will unable to pass the authentication and will also be quarantined as a no-capable. But the question originally was beyond that, in our scenario why this is not happening. check my subject line of thread.

     

     Machine with wiredautoconfig off, keeps itself stuck at connection policy with PEAP authentication and keep retrying to connect through PEAP. It never falls to next connection policy where i have defined to goto quarantine zone unauthenticated, provided machine/device is not dot1x capable.

     

     If the MAC Address is excluded, that is one thing.

     

     But i am simly unable to put any guest laptop directly to any quest VLAN without exempting his MAC address.

     

     That is the problem.

     

     Kindly provide something specific to this problem.


    Shahid Roofi
    Thursday, June 16, 2011 4:33 PM
  • Hi,

    I think there is a basic concept here that isn't getting explained or understood.

    The wired autoconfig service is what creates and sends the network connection request. NPS policies evaluate these requests. If there is no service, and no request, then NPS will not display any events. NPS will be unable to determine anything about the computer because the request for network access is never sent.

    In your scenario (with wiired autoconfig service off), the computer is getting quarantined by the switch, not by NPS.

    -Greg


    Sunday, July 24, 2011 6:07 AM
  • Thank you Greg for taking your time out to shed light on the frustrating scenario we were once stuck at.

    However there are updates on what happened lately with us on this topic.

    On the switch end we simply had what is called: security 'securelogin-or-mac' (3com term) which means the authentication is tried with whatever method possible and even if authenticated through MAC dot1x is attempted and preferred at priority. In cisco world this is called 'MAB' mac adddres bypass which also is same thing i-e it tries dot1x first then failting dot1x it attempts mac based athenitcation.

    Realistic dot1.x rollout does reqiure above feature otherwise port level exceptions to devices need to be considered at switch port level (enabling mac authenticaiton on port level for printers/thin clients/other devices) and enabling dot1x on others. This is administrative chaoas because such ports need to be documented and then switch replacement would be a frustrating.

    We could not have the chance to confirm the behaviour in cisco but in 3com what happens with 'securelogin-or-mac' nothing goes beyond PEAP authenication connection request policy and nothing is logged either. As soon as attempt to dot1x authentcation is started with EAPOL-start it stucks at PEAP connection request policy and never detects that dot1x is not possible and move forward to another rule with mac authenticaiton ( that's a bug and need to be address by NAP team for realistic NAP deployments. Not sure if it is only specific to 3COM only).

    However luckily we happen to had a solution to above. That is with extension dll on top of NPS. extension dll simply check if the authenication is through mac address and mac address is only one listed in AD then it sets the authentication to success and that works well. PEAP authenitcation as well works whever end points supports. simple solution for all type of end points.

    Having achieved that we went on further to achieve another wish with us ( to put all devices which fails both dot1x as well mac authentication into a separate VLAN called guest wtih furhter li


    Shahid Roofi
    Sunday, July 24, 2011 2:16 PM
  • Thank you Greg for taking your time out to shed light on the frustrating scenario we were once stuck at.

    From your above response it means that we need to have different type of security (mac authentication) configured for non dot1x capable devices and selectively enabling dot1x for devices that can.

     Can you imagine the efforts being offloaded to switches? Ports need to remembered, documented and each replacement of switch would require reconfiguration remembering those ports.

    However there are updates on what happened lately with us on this topic. Switches already turned out be intelligent on this and have features to address this.

    On the switch end we simply had what is called: port-security 'securelogin-or-mac' (3com term) which means the authentication is tried with whatever method possible and even if authenticated through MAC dot1x is attempted and preferred at priority. In cisco world this is called 'MAB' mac adddres bypass which also is same thing i-e it tries dot1x first then failting dot1x it attempts mac based athenitcation.

    Realistic dot1.x rollout does reqiure above feature otherwise port level exceptions to devices need to be considered at switch port level (enabling mac authenticaiton on port level for printers/thin clients/other devices) and enabling dot1x on others. This is administrative chaoas because such ports need to be documented and then switch replacement would be a frustrating.

    We could not have the chance to confirm the behaviour in cisco but in 3com what happens with 'securelogin-or-mac' is that nothing goes beyond PEAP authenication connection request policy and nothing is logged either. As soon as attempt to dot1x authentcation is started with EAPOL-start it stucks at PEAP connection request policy and never detects that dot1x is not possible and move forward to another rule with mac authenticaiton ( that's a bug and need to be address by NAP team for realistic NAP deployments. Not sure if it is only specific to 3COM only).

     However luckily we happen to had a solution to above. That is with extension dll on top of NPS. extension dll  we coded to simply check if the authenication is through mac address and mac address is only one listed in AD then it sets the authentication to success and that works well. PEAP authenitcation as well works whever end points supports. simple solution for all type of end points.

    Having achieved that we went on further to achieve another wish with us ( to put all devices which fails both dot1x as well mac authentication into a separate VLAN called guest wtih furhter limited access). That was also not simply possible in NPS as well (another bug). Any authenication that fails in NPS console there is no way to control that end points, request is outright rejected with no attributes to pass ( only hope is to check switch capability and 3com have no guest VLAN in the type of security we are using. We came across this by another dll named authorization dll in which we are simply giving complete access to whoever failing authentication i-e simply checking if the request is failing authentication we revert it to success as last thing to be done in connection request processing. And then 'secureloging-or-mac' setting turned out to be intelligent it while successfully authetating through mac still tries for dot1x which made our solution seamless for end point that support dotx1 as well as with those that do not.

     Our only concern is about NPS inflexibiliyt. Such simply settings should be possible right away in NPS console without this much of code and testing that we had to get through. At least should be addressed in next version of NPS or hotfix. NPS solution should be flexible as in its current state it can be a good sounding feature but not realistic to implement.

    I hope my above comments would be addressed and incorporated into product.


    Shahid Roofi
    Sunday, July 24, 2011 2:26 PM
  • Hi Shadid,

    I believe NPS supports MAC address Authorization although I haven't tried this personally, see http://technet.microsoft.com/en-us/library/dd197535(WS.10).aspx. It does seem to be difficult to implement.

    The guest VLAN feature is fairly common on switches so I am not sure why this didn't work for you.

    I'll forward your feedback to the NPS team, and I'm glad you were able to find a solution!

    -Greg

    Sunday, July 24, 2011 3:58 PM
  • thanx you sir
    Shahid Roofi
    Monday, July 25, 2011 7:58 AM