Security

Hi,

 

I'm trying to setup a RAP-2WG so that a we can use the e0/1 port for wired access on our LAN.

 

I have successfully configured the relevant profiles so that this can be done without a AAA Profile.

 

I now want to get the client to authenticate itself before any access is allowed. And this is where I'm having the problems.

 

Were using Microsoft NPS for the RADIUS server. Its the same server that authenticates our wireless users.

 

I've setup a new Connection Request Policy and a Network Policy.

 

The Connection Policy has a condition of NAS Port Type - VPN or Ethernet

 

The Network Policy has a condition of NAS Port Type - VPN or Ethernet and Windows Groups - Domain user or Domain computers.

 

Authentication method is Microsoft PEAP with EAP or MS-CHAP v2.

 

I have set up the profiles for AAA. I have a AAA profile called "Wired" and in that I have a 802.1x profile called "Wired" along with the 802.1x server group named "Wired".

 

The server group has the server "Wired" which points to the IP of the NPS server.

 

The 802.1x profile is pretty much default only I have set termination parameters to enabled and selected eap-peap and eap-mschapv2. (if this isnt selected then the NPS server doesnt even see the requests)

 

I have then assigned the AAA profile to the ethernet interface port 1 configuration in the AP group that the RAP is located in.

 

My client always fails to authenticate. The client is set to PEAP, remember credentials, EAP-MSCHAPv2, enable fast reconnect and ticked, automatically use windows logon if any. In advanced, computer authentication is specified.

 

This is the output from the Aruba controller and the debug below that

Aug 22 11:12:57  station-up             *  2c:76:8a:db:65:10  01:80:c2:00:00:03        -    -   open system
Aug 22 11:12:57  station-up             *  2c:76:8a:db:65:10  01:80:c2:00:00:03        -    -   wired station
Aug 22 11:12:57  station-term-start     *  2c:76:8a:db:65:10  01:80:c2:00:00:03        101  -
Aug 22 11:12:57  eap-term-start        ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  -    -
Aug 22 11:12:57  station-term-start     *  2c:76:8a:db:65:10  01:80:c2:00:00:03        101  -
Aug 22 11:13:02  client-finish         ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  -    -
Aug 22 11:13:02  server-finish         <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  -    -
Aug 22 11:13:02  server-finish-ack     ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  -    -
Aug 22 11:13:02  inner-eap-id-req      <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  -    -
Aug 22 11:13:02  inner-eap-id-resp     ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  -    -   host/LT19515.*****************
Aug 22 11:13:02  eap-mschap-chlg       <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  -    -
Aug 22 11:13:02  eap-mschap-response   ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  9    49
Aug 22 11:13:02  mschap-request        ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  9    -   host/LT19515.*****************
Aug 22 11:13:02  mschap-response       <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  -    -   host/LT19515.*****************
Aug 22 11:13:02  eap-mschap-chlg-retry <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  -    -

 

Aug 22 11:12:57 :522035:  <INFO> |authmgr|  MAC=2c:76:8a:db:65:10 Station UP: BSSID=01:80:c2:00:00:03 ESSID=n/aVLAN=101 AP-name=Bayman_BCH
Aug 22 11:13:02 :522042:  <NOTI> |authmgr|  User Authentication Failed: username=host/LT19515.******************** MAC=2c:76:8a:db:65:10 IP=0.0.0.0 auth method=802.1x auth server=Wired

 

Any help is appreciated. Have been severely banging my head against a wall. (the stars in the output have been inserted in place of my domain)

 

Thanks

Ian

Check the event log on your NPS server.

You should have a message there telling you why the user was denied access

Yes I do, just says "An Error occured during logon"

 

Normally I would see "bad username or password" for failures (to my knowledge)

---

@Broaders wrote:

Yes I do, just says "An Error occured during logon"

 

Normally I would see "bad username or password" for failures (to my knowledge)

---

You cannot do EAP-Termination with Machine Authentication:

 

Aug 22 11:12:57  station-term-start     *  2c:76:8a:db:65:10  01:80:c2:00:00:03        101  -

 

To make this work you should change the laptops wired advanced 802.1x to user only authentication, OR, disable termination from the controller and have the NPS server do the EAP (Certificate) function.

 

Hmm I did read this. Am I right in thinking for wireless authentication, EAP does not terminate on the controller?

 

Because we use machine auth for the wireless connectivity.

 

I cant use user authentication because I need the PC to be able to authenticate before the logon request. (before entering user crendentials to logon)

 

A user cannot log on without this............Would this mean then that the certificate way would work for machine auth?

---

@Broaders wrote:

Hmm I did read this. Am I right in thinking for wireless authentication, EAP does not terminate on the controller?

 

Because we use machine auth for the wireless connectivity.

 

I cant use user authentication because I need the PC to be able to authenticate before the logon request. (before entering user crendentials to logon)

 

A user cannot log on without this............Would this mean then that the certificate way would work for machine auth?

---

Sir,

 

Based on your auth-tracebuf output, there is the "Term" parameter, which means that you have Termination on in the 802.1x profile being used for the wired port.  See if you force that wired port only to user authentication to see if that is your problem.  You could be using a 802.1x profile on the controller for wireless that does NOT use termination and a different 802.1x profile for wired that DOES use termination, and THAT could be breaking your authentication.

 

Just as a test, please force the wired 802.1x to use only user authentication in the advanced profile on the laptop to see if that is your issue.

 

Hi!

 

Yes you are correct. The wireless 802.1x profile does not use the Termination function.

 

I have a seperate 802.1x profile for the wired access. I HAVE to enable Termination in order for the NPS server to see the requests.

 

When I specify user authentication on the laptop it does work. I can also see the successful authentication log on the NPS server.

 

However this doesnt help me when I have a Laptop at the ctrl-alt-del prompt and then trying to log on.

 

Hmm is it possible to change the initial role (pre authentication) to allow the authentication to happen when entering credentials at the prompt?

Why do you have to Enable Termination for the wired 802.1x profile?  What happens when you disable it?  It should work very similar to the wireless...

If Termination is not enabled the NPS server does not receive any requests for authentication

As a test:

 

- Disable Termination on that 802.1x profile for wired.

- In the AAA profile for the wired port, make the initial role something like "Authenticated"

- Unplug, then plug in the wired port of the laptop

- Paste in the output of "show auth-tracebuf" to see what is going on with that wired authentication.

 

Could you also post the output from the following commands?

 

show aaa authentication-server radius

show aaa server-group

The authentication fails, the NPS logs show no attempt for authentication and the "show auth-tracebuf" displays

 

Aug 22 12:47:32  eapol-pkt-drop         *  2c:76:8a:db:65:10  01:80:c2:00:00:03        -    -   received eapol-pkt before assos
Aug 22 12:47:37  eapol-pkt-drop         *  2c:76:8a:db:65:10  01:80:c2:00:00:03        -    -   received eapol-pkt before assos
Aug 22 12:47:42  eapol-pkt-drop         *  2c:76:8a:db:65:10  01:80:c2:00:00:03        -    -   received eapol-pkt before assos

(BTUH-ARUBA1) # show aaa authentication-server radius

 

RADIUS Server List

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

Name                      References  Profile Status

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

Amigopod                  2

CPPM                      1

itvwnps01                 1

itvwnps01-btuhcorp-nasid  1

itvwnps01-btuhmob-nasid   1

itvwnps01-testa-nasid     1

Wired                     1

Total:7

 

 

(BTUH-ARUBA1) #show aaa server-group

 

Server Group List

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

Name                              References  Profile Status

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

RADIUS             0

RADIUS.BTUH-CORP   1

RADIUS.BTUH-Mob    1

RADIUS.mob-secure  0

RADIUS.TestA       1

BTUH-Guest                        1

BYOD                              3

default                           8

internal                          1           Predefined

RAMSEY-Guest                      1

Wired                             1

Total:11

(BTUH-ARUBA1) #

 

---

@Broaders wrote:

The authentication fails, the NPS logs show no attempt for authentication and the "show auth-tracebuf" displays

 

Aug 22 12:47:32  eapol-pkt-drop         *  2c:76:8a:db:65:10  01:80:c2:00:00:03        -    -   received eapol-pkt before assos
Aug 22 12:47:37  eapol-pkt-drop         *  2c:76:8a:db:65:10  01:80:c2:00:00:03        -    -   received eapol-pkt before assos
Aug 22 12:47:42  eapol-pkt-drop         *  2c:76:8a:db:65:10  01:80:c2:00:00:03        -    -   received eapol-pkt before assos

---

Okay,

 

Try this on the commandline:

 

config t
aaa authentication wired
profile default

 Then unplug, then re-plug the wired port and display the show auth-tracebuf again

 

 

No difference, controller shows the same again

 

Aug 22 12:54:49  eapol-pkt-drop         *  2c:76:8a:db:65:10  01:80:c2:00:00:03        -    -   received eapol-pkt before assos
Aug 22 12:54:54  eapol-pkt-drop         *  2c:76:8a:db:65:10  01:80:c2:00:00:03        -    -   received eapol-pkt before assos
Aug 22 12:54:59  eapol-pkt-drop         *  2c:76:8a:db:65:10  01:80:c2:00:00:03        -    -   received eapol-pkt before assos

Do you have the forwarding mode of that wired port set to bridged or tunneled?

 

Tunneled

Can you print the output of "show aaa authentication wired"?

 

Type "show aaa profile" to find the profile that you are using for that port.

 

Next, do this:

 

config t

aaa authentication wired <name of that profile>

 

Try to plug the port in and out again and print the show auth-tracebuf

 

 

If that doesn't work, you might have to open a case.  It should work.

 

Nope no difference.

 

FYI this is the output when I enable Termination for the Profile. Completes successfully

 

Aug 22 13:27:26  station-up             *  2c:76:8a:db:65:10  01:80:c2:00:00:03        -    -   open system
Aug 22 13:27:26  station-up             *  2c:76:8a:db:65:10  01:80:c2:00:00:03        -    -   wired station
Aug 22 13:27:26  station-term-start     *  2c:76:8a:db:65:10  01:80:c2:00:00:03        101  -
Aug 22 13:27:26  eap-term-start        ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  -    -
Aug 22 13:27:26  station-term-start     *  2c:76:8a:db:65:10  01:80:c2:00:00:03        101  -
Aug 22 13:27:31  client-finish         ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  -    -
Aug 22 13:27:31  server-finish         <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  -    -
Aug 22 13:27:31  server-finish-ack     ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  -    -
Aug 22 13:27:31  inner-eap-id-req      <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  -    -
Aug 22 13:27:31  inner-eap-id-resp     ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  -    -   Domain\Username
Aug 22 13:27:31  eap-mschap-chlg       <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  -    -
Aug 22 13:27:31  eap-mschap-response   ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  9    49
Aug 22 13:27:31  mschap-request        ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  9    -   Domain\Username
Aug 22 13:27:31  mschap-response       <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  -    -   Domain\Username
Aug 22 13:27:31  eap-mschap-success    <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  -    -
Aug 22 13:27:31  eap-mschap-success-ack->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  -    -
Aug 22 13:27:31  eap-tlv-rslt-success  <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  -    -
Aug 22 13:27:31  eap-tlv-rslt-success  ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  -    -
Aug 22 13:27:31  station-data-ready     *  2c:76:8a:db:65:10  00:00:00:00:00:00        101  -
Aug 22 13:27:31  station-data-ready_ack *  2c:76:8a:db:65:10  00:00:00:00:00:00        101  -
Aug 22 13:27:31  eap-success           <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  -    -

 

When termination is disabled I just get

 

Aug 22 13:24:21  eapol-pkt-drop         *  2c:76:8a:db:65:10  01:80:c2:00:00:03        -    -   received eapol-pkt before assos
Aug 22 13:24:26  eapol-pkt-drop         *  2c:76:8a:db:65:10  01:80:c2:00:00:03        -    -   received eapol-pkt before assos
Aug 22 13:24:31  eapol-pkt-drop         *  2c:76:8a:db:65:10  01:80:c2:00:00:03        -    -   received eapol-pkt before assos

Do you have a trusted certificate configured on that laptops wired profile?

No the option for validating certificates is not enabled.

Okay.

 

For some reason, your wired 802.1x profile is not working with the certificate on your radius server.  When you turn termination on, that shifts the EAP/Cert function to the built-in certificate on the controller, and that works.  That means your laptop's wired 802.1x profile works with the controller's built in certificate.  Termination and Machine authentication, don't work, however, otherwise you would be home free.

 

The question is why machine authentication does not work when termination is off.  Do you have any special rules on the NPS server that is preventing wired authentication?

 

Hi,

 

We've done some further investigation. We seem to now have the authentication working with Termination OFF and Machine authentication also.

 

In the wired AP profile for the RAP group we had the port ticked as "Trusted". When we unticked this and disabled the termination this worked correctly, see below;

 

Aug 22 13:49:38  eap-id-resp           ->  2c:76:8a:db:65:10  01:80:c2:00:00:03        1      26    Domain\Username
Aug 22 13:49:38  rad-req               ->  2c:76:8a:db:65:10  01:80:c2:00:00:03        65505  200
Aug 22 13:49:38  rad-resp              <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65505  90
Aug 22 13:49:38  eap-req               <-  2c:76:8a:db:65:10  01:80:c2:00:00:03        2      6
Aug 22 13:49:39  eap-resp              ->  2c:76:8a:db:65:10  01:80:c2:00:00:03        2      167
Aug 22 13:49:39  rad-req               ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65506  379
Aug 22 13:49:39  rad-resp              <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65506  239
Aug 22 13:49:39  eap-req               <-  2c:76:8a:db:65:10  01:80:c2:00:00:03        3      155
Aug 22 13:49:39  eap-resp              ->  2c:76:8a:db:65:10  01:80:c2:00:00:03        3      69
Aug 22 13:49:39  rad-req               ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65507  281
Aug 22 13:49:39  rad-resp              <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65507  191
Aug 22 13:49:39  eap-req               <-  2c:76:8a:db:65:10  01:80:c2:00:00:03        6      107
Aug 22 13:49:39  eap-resp              ->  2c:76:8a:db:65:10  01:80:c2:00:00:03        6      107
Aug 22 13:49:39  rad-req               ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65508  319
Aug 22 13:49:39  rad-accept            <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65508  242
Aug 22 13:49:39  eap-success           <-  2c:76:8a:db:65:10  01:80:c2:00:00:03        6      4

 

When we configured the laptop to use machine authentication this also worked see below;

 

Aug 22 13:52:19  eap-start             ->  2c:76:8a:db:65:10  01:80:c2:00:00:03        -      -
Aug 22 13:52:19  eap-id-req            <-  2c:76:8a:db:65:10  01:80:c2:00:00:03        8      5
Aug 22 13:52:19  eap-id-resp           ->  2c:76:8a:db:65:10  01:80:c2:00:00:03        8      32    host/LT19515.********************
Aug 22 13:52:19  rad-req               ->  2c:76:8a:db:65:10  01:80:c2:00:00:03        65513  212
Aug 22 13:52:19  rad-resp              <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65513  90
Aug 22 13:52:19  eap-req               <-  2c:76:8a:db:65:10  01:80:c2:00:00:03        9      6
Aug 22 13:52:19  eap-resp              ->  2c:76:8a:db:65:10  01:80:c2:00:00:03        9      140
Aug 22 13:52:19  rad-req               ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65514  358
Aug 22 13:52:19  rad-resp              <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65514  1434
Aug 22 13:52:19  eap-req               <-  2c:76:8a:db:65:10  01:80:c2:00:00:03        10     1340
Aug 22 13:52:19  eap-resp              ->  2c:76:8a:db:65:10  01:80:c2:00:00:03        10     6
Aug 22 13:52:19  rad-req               ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65515  224
Aug 22 13:52:19  rad-resp              <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65515  1434
Aug 22 13:52:19  eap-req               <-  2c:76:8a:db:65:10  01:80:c2:00:00:03        11     1340
Aug 22 13:52:19  eap-resp              ->  2c:76:8a:db:65:10  01:80:c2:00:00:03        11     6
Aug 22 13:52:19  rad-req               ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65516  224
Aug 22 13:52:19  rad-resp              <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65516  483
Aug 22 13:52:19  eap-req               <-  2c:76:8a:db:65:10  01:80:c2:00:00:03        12     397
Aug 22 13:52:19  eap-resp              ->  2c:76:8a:db:65:10  01:80:c2:00:00:03        12     343
Aug 22 13:52:19  rad-req               ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65517  563
Aug 22 13:52:19  rad-resp              <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65517  153
Aug 22 13:52:19  eap-req               <-  2c:76:8a:db:65:10  01:80:c2:00:00:03        13     69
Aug 22 13:52:19  eap-resp              ->  2c:76:8a:db:65:10  01:80:c2:00:00:03        13     6
Aug 22 13:52:19  rad-req               ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65518  224
Aug 22 13:52:19  rad-resp              <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65518  127
Aug 22 13:52:19  eap-req               <-  2c:76:8a:db:65:10  01:80:c2:00:00:03        14     43
Aug 22 13:52:19  eap-resp              ->  2c:76:8a:db:65:10  01:80:c2:00:00:03        14     75
Aug 22 13:52:19  rad-req               ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65519  293
Aug 22 13:52:19  rad-resp              <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65519  159
Aug 22 13:52:19  eap-req               <-  2c:76:8a:db:65:10  01:80:c2:00:00:03        15     75
Aug 22 13:52:19  eap-resp              ->  2c:76:8a:db:65:10  01:80:c2:00:00:03        15     123
Aug 22 13:52:19  rad-req               ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65520  341
Aug 22 13:52:19  rad-resp              <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65520  175
Aug 22 13:52:19  eap-req               <-  2c:76:8a:db:65:10  01:80:c2:00:00:03        16     91
Aug 22 13:52:19  eap-resp              ->  2c:76:8a:db:65:10  01:80:c2:00:00:03        16     43
Aug 22 13:52:19  rad-req               ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65521  261
Aug 22 13:52:19  rad-resp              <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65521  191
Aug 22 13:52:19  eap-req               <-  2c:76:8a:db:65:10  01:80:c2:00:00:03        17     107
Aug 22 13:52:19  eap-resp              ->  2c:76:8a:db:65:10  01:80:c2:00:00:03        17     107
Aug 22 13:52:19  rad-req               ->  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65522  325
Aug 22 13:52:19  rad-accept            <-  2c:76:8a:db:65:10  01:80:c2:00:00:03/Wired  65522  310
Aug 22 13:52:19  eap-success           <-  2c:76:8a:db:65:10  01:80:c2:00:00:03        17     4
Aug 22 13:52:19  station-data-ready     *  2c:76:8a:db:65:10  00:00:00:00:00:00        101    -
Aug 22 13:52:19  station-data-ready_ack *  2c:76:8a:db:65:10  00:00:00:00:00:00        101    -

 

I can confirm also the NPS server sees the requests and processes accordingly.

Excellent!

Indeed! Huge sigh!

 

Are you able to tell me the function of the "trusted" variable. How does it affect the configuration?

It would skip authentication if it is trusted. It is essential for with to work. Not sure why it half-works


Colin Joseph
Principal Systems Engineer, ACE
Aruba Networks
cjoseph@arubanetworks.com
512-240-2227

So as a trusted port is should essentially drop those packets?

 

Atleast its working now :)

It should not force authentication

Do you have a matching policy on NPS for computer authentication vs. user authentication?  

 

I know you said you don't see anything on the NPS server when the computer tries to authenticate.   Do you see failures in general on NPS?    I've seen a number of NPS installs where failures did not register in the log despite being configured to do so.   If you don't see other failures, run the following:

 

auditpol /set /subcategory:"Network Policy Server" /success:enable /failure:enable