MAC Authentication using MAC-address as username

Question

_{Wednesday, October 8, 2008 1:29 AM}

Hi all,

I've got a situation where I'm trying to get a switch ( 3Com 5500G) to authenticate to a NPS server for basic network access ( no dynamic vlan'ing or anything special ).

In the switch config, I'm able to define whether I use a static username for all mac-authentications, or whether I simply replace the username and password variables with the mac-address of the requesting network card.

When I use the static username, I'm able to authenticate without any issues. I'm able to see the authentication request in the NPS event log in server manager and everything is great.

When I change the switch config to instead use the mac-address as the username and password, I get nothing in the event viewer at all.  I am able to see the request attempted in the NPS log file.

In the log file, I'm able to see that the fixed username is succesfully able to use the connection policy and then the network policy ( it works!).   When I switch to the mac-address as username, I'm able to see it matches the connection policy, but not the network policy. Which would lead me to believe it's the network policy, but I altered the policy to create a catch-all condition and I still wasn't able to get it to match... arg...

On the switch side, all I can see in the RADIUS debug is that the RADIUS server is rejecting the authentication attempt without any message. Not very helpfull...  : )

The only other things that I noticed here is when I use the fixed name, the logfile shows the connection attempt as the FQDN username (  [email protected]  ) but when I try to use the mac-address version, the logon attempt is formatted in a netbios (?) type name 
ie:  Domainname\username

There's nothing on the switch configuration that's adding this in, and I really can't see why it would make a difference in the authentication from a NPS side. As far as I'm aware, we can still authenticate using either username format.

Any ideas here? I found this link which details the structure of the log file 
http://technet.microsoft.com/en-us/library/cc771748.aspx

But what it doesn't do is give me any insight as to why the network policy isn't been matched by the mac-address logon attempt.

Any help would be GREATLY appreciated...

thank!

Christopher Young

All replies (6)

_{Wednesday, October 8, 2008 8:23 PM ✅Answered}

Hi Greg,

Thanks for the reply!  After spending a few hours on the phone with MS Support this morning, we found what looks like a bug in the NPS logging.  Although the server is set to log both succesful and rejected attempts, it's only logging the rejected attempts into the log file, not the event viewer.

After restarting the NPS service a few times, for no apparent reason ( no change to the NPS config, no change to the switch config ) we were suddenly able to get this working.

In the log file when it wasn't working, we were seeing a reason-code of 16 ( IAS-Auth-Failure ), when it finally started working, we would see reason-code O (succesfull)  ( and a corresponding entry in the event viewer ), and when we (for testing purposes) disabled the account we were testing with, the reason-code was a 34 ( IAS-Account-Disabled ) which is exactly what we would expect to see, but with no entry in the event viewer.

I also put together a excel spreadsheet that, when you import log file using comma-delimated for the parsing, allows you to make sense of the log file.  Feel free to e-mail me at  z3ntigger at hot mail dot com  if you'd like a copy.

It made the troubleshooting process SOOOOOOOOO much easier...

cheers,

Christopher Young

_{Wednesday, October 8, 2008 8:12 PM}

Hi Christopher,

RADIUS will reject the client if it doesn't match any network policies. It sounds like that it what is happening. Are you using the same connection request policy for both situations?

You should be able to review the server event log and also the client event logs for additional details. On the server check Custom Views\Server Roles\Network Policy and Access Services. On the client, check Applications and Services Logs\Microsoft\Windows\Wired Autoconfig.

-Greg

_{Wednesday, October 8, 2008 10:03 PM}

Thanks Christopher, the link you posted is a great resource & the spreadsheet sounds useful! That is strange that event viewer wasn't working for you, but I'm happy you got the problem resolved =)

-Greg

_{Thursday, October 9, 2008 6:31 PM}

I'm experiencing the same logging issue Christopher mentioned. I'm running two NPS servers and both are set to log successful and rejected attempts, but the only events in Custom Views\Server Roles\Network Policy and Access Services are 4400 ("A LDAP connection [...] is established" and 6273 ("Network Policy Server denied access to a user"). Hmm.
-Dan

_{Friday, October 10, 2008 8:18 AM}

Christopher,

One thing to test, can you do a standard authentication using the MAC address as both the username and password without going through the RADIUS server?  After trying that, and if possible, try a standard 802.1X authentication using the RADIUS server using the MAC address username and password and ensure it works.  If both of those scenarios work, double check that the switch is passing the MAC address in the same format as you are using to manually test with.  I know on some Cisco gear, there are three formats that it can pass the data in.

As a related question, is there any general guidance on creating a limited access account to allow only RADIUS authentication?  We're also working on using mac-auth, for non-802.1X devices, but want to ensure that the accounts can't be used for anything but accessing the MAC-auth VLAN.  A first pass solution might include changing the primary group ID  of an account to something other than Domain Users, probably a newly-created group called MAC Addresses, and then use GPO to ensure that the MAC Addresses group is denied logon locally and logon via terminal services, but I'm sure there are several gaps in this as it stands.

-abc

_{Friday, October 10, 2008 4:56 PM}

Hi Alex,

Thanks for the post... in the end we got it working just fine. In the 3Com gear, we have the ability to alter the way the mac-address is sent ( with or without dashes, upper case or lower case for the alpha characters, etc.)

For a limited access account, I think there's a few different ways you could approach that. You could create user the method you described above, except I would probably go further and make sure to implicitly deny them access to everything ( take them out of the domain users group, take them out of the everyone group, etc.) 

But again, I'm sure there are holes there... a better way might be to have the network policy created that will only apply to specific caller-id's ( mac-address usually ) and then have the NPS offload authentication to another RADIUS server ( free-radius, funk, etc.) where the user accounts will have no AD rights at all.

Alternately, you could also have the NPS server as a non-domain PC and then offload authentication for "real" users to a DC and then use local authentication on the NPS for the restricted users.

lots of possibilities here...

cheers,

Chris