locked
802.1x Microsoft NPS 'ieee802Device' object group (MAC Authentication Fallback) RRS feed

  • Question

  • Hi,
    when you enable 802.1x on Cisco LAN switches, there is a feature called "MAC Authentication Bypass" that allows non-802.1x-devices to get authenticated by a RADIUS-Server. For this feature to work, you would create user accounts in AD that have the client´s MAC-Address as the username and also as the password. Unfortunately, you cannot do so if your domain has strict password enforcement policies, because passwords are not allowed to match usernames then. According to a Cisco whitepaper (http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6638/config_guide_c17-663759.pdf), one should use the 'ieee802Device' class that is build into Windows Server 2003R2 and above. I have tried to get this working (with no success...), unfortunately I did not find any guidelines on the web how to accomplish this. What I did so far was:
    - Created a new structural class"myieee802Device", based on the abstract class "ieee802Device"
    - Created a new OU "ethers" in AD
    - Created a simple objekt by means of an ldifde.exe import
    dn: CN=001b21******,OU=ethers,DC=dot1x,DC=com
    changetype: add
    objectClass: myieee802Device
    cn: 001b21******
    macAddress: 00:1b:21:**:**:**
    When I trigger 802.1x authentication at my supplicant (Windows XP), NPS does not find the device (MAC-Address) in AD.
    Has anybody got this running so far? Anybody seen a step-by-step guide? 
    steffchen
    Friday, June 10, 2011 12:33 PM

Answers

  • Update:

    I opened an official case with Microsoft Support. They worked out that the ieee802Device class can NOT be used with NPS/IAS, because the class does not contain a username attribute. The existence of the username attribute is required by NPS/IAS. This means: The Cisco document leads to the wrong direction :-( 

    Proposed solution for the problem: Use fine grained password policies (only possible if the domain is Windows 2008 level - that is where you have to 'bite the bullet'), and lower password policy for accounts that represent devices (MAC adresses).

    I'm going to test it by next week and will publish my findings here.


    Stefan

    Monday, June 27, 2011 1:37 PM
  • Update:

    Fine-Grained password policies DO work in my lab.

    So, the final solution that I am satisfied with emcompasses these steps:

    1.) Raise functional domain level to Windows 2008 (!)

    2.) Follow the step-by-step guide http://technet.microsoft.com/en-us/library/cc770842(WS.10).aspx to create a PSO which does NOT have complex password settings

    3.) Create an OU, e.g. "myMABDevices", so that 802.1X devices do not appear in the regular list of domain user accounts (some administrators may do not like to see hundreds of MAC addresses among their domain user accounts)

    4.) Create a regular group, e.g. "allMABDevices", and link the PSO to this group. This is described in the step-by-step guide, Microsoft calls it a "shaddow group". It is necessary because PSOs can't be bound to OUs directly.

    5.) Create user accounts (not computer accounts) for every 802.1X device (username = MAC address, password = MAC address). I had to do an intermediate step and had to assign a temporary, complex password because when you create the user account, it is not yet in the corresponding regular group "allMABDevices", so the default domain policy is applied at this moment. There may be ways to circumvent this, but this will done by my Active Directory colleagues :-)

     

    Stefan

     

    P.S.: If you are not able to raise to Windows 2008 functional domain level, you may consider the use of password filters (passfilt.dll) . There are commercial products for this, but I did not find any which could l o w e r password policies. They can only increment password requirements. This seems to be a native Windows restriction.

     

    Stefan

    Tuesday, June 28, 2011 3:42 PM

All replies

  • Hi steffchen,

     

    Thanks for posting here.

     

    > For this feature to work, you would create user accounts in AD that have the client´s MAC-Address as the username and also as the password.

     

    Actually you don’t have to do in this way.Adding MAC address in “Calling-Station-ID” field could also help you to achieve the goal, see the introduction in the article below:

     

    Enhance your 802.1x deployment security with MAC filtering

    http://blogs.technet.com/b/nap/archive/2006/09/08/454705.aspx

     

    Thanks.

     

    Tiger Li


    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.
    Monday, June 13, 2011 7:33 AM
  • Hi Tiger Li,

    thank's for answering my question!

     

    I tried to get it running this morning:

    Created a user account whose name was the client's (in this case: a printer) MAC address, entered the MAC-Address as "xx-xx-xx-xx-xx-xx" in tab "Dial-in => Verify Caller-ID", and set the password equal to the MAC address. This did work. And when I changed the MAC in "Verify Caller-ID" deliberately to a false value, access was denied - worked as expected!

    What did not work was changing the password to an arbitrary value. It seems that NPS persists in being both the user account name and the corresponding password equal to the MAC-Address (which is not possible when strict password policies are in place).

    So I wonder if the user object can be used for this purpose (if I understand the hints in the Cisco document mentioned above correctly, the ieee802Device class does not fall under password policy restrictions or does not even store a password at all).

     

    Stefan

    Tuesday, June 14, 2011 1:33 PM
  • Hi Stefan,

     

    Thanks for update.

     

    Just try to make it simpler, have you consider to just do machine authentication instead user account ? mean just assign MAC address for domain computers.

     

    Thanks.

     

    Tiger Li


    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 15, 2011 3:32 AM
  • Hi Tiger Li,

     

    >> have you consider to just do machine authentication instead user account ? mean just assign MAC address for domain computers.


    yes, but
     - any guides I found on the Internet that describe how to use Cisco with NPS say that the accounts should be created as user accounts (user account name = MAC = password). Unfortunately, there are no commands to tell a cisco switch to use a different password, e.g. the RADIUS shared secret, a preconfigured value, etc.
     
    - my devices are not necessarily domain computers, but also IP phones, printers, etc., with no 802.1X capabilities
    I have even tried to create a computer object that has the MAC as the account name, but NPS does not find it (probably because NPS' internal logic searches for user objects only. That's the point where I found the article from Cisco that mentions the ieee802Device class - which seems to be some kind of user object but does not fall under AD password enforcement mechanisms).
    Stefan
    Wednesday, June 15, 2011 9:22 AM
  • Update:

    I opened an official case with Microsoft Support. They worked out that the ieee802Device class can NOT be used with NPS/IAS, because the class does not contain a username attribute. The existence of the username attribute is required by NPS/IAS. This means: The Cisco document leads to the wrong direction :-( 

    Proposed solution for the problem: Use fine grained password policies (only possible if the domain is Windows 2008 level - that is where you have to 'bite the bullet'), and lower password policy for accounts that represent devices (MAC adresses).

    I'm going to test it by next week and will publish my findings here.


    Stefan

    Monday, June 27, 2011 1:37 PM
  • Update:

    Fine-Grained password policies DO work in my lab.

    So, the final solution that I am satisfied with emcompasses these steps:

    1.) Raise functional domain level to Windows 2008 (!)

    2.) Follow the step-by-step guide http://technet.microsoft.com/en-us/library/cc770842(WS.10).aspx to create a PSO which does NOT have complex password settings

    3.) Create an OU, e.g. "myMABDevices", so that 802.1X devices do not appear in the regular list of domain user accounts (some administrators may do not like to see hundreds of MAC addresses among their domain user accounts)

    4.) Create a regular group, e.g. "allMABDevices", and link the PSO to this group. This is described in the step-by-step guide, Microsoft calls it a "shaddow group". It is necessary because PSOs can't be bound to OUs directly.

    5.) Create user accounts (not computer accounts) for every 802.1X device (username = MAC address, password = MAC address). I had to do an intermediate step and had to assign a temporary, complex password because when you create the user account, it is not yet in the corresponding regular group "allMABDevices", so the default domain policy is applied at this moment. There may be ways to circumvent this, but this will done by my Active Directory colleagues :-)

     

    Stefan

     

    P.S.: If you are not able to raise to Windows 2008 functional domain level, you may consider the use of password filters (passfilt.dll) . There are commercial products for this, but I did not find any which could l o w e r password policies. They can only increment password requirements. This seems to be a native Windows restriction.

     

    Stefan

    Tuesday, June 28, 2011 3:42 PM
  • Hi!

    I am trying to add ieee802Device object to my AD but have no luck. I am using ADExplorer. When i try to create object with Class=ieee802Device, i got error with Naming Violation. What can i do with this? 

    Wednesday, August 7, 2013 10:42 AM