Security

last person joined: yesterday 

Forum to discuss Enterprise security using HPE Aruba Networking NAC solutions (ClearPass), Introspect, VIA, 360 Security Exchange, Extensions, and Policy Enforcement Firewall (PEF).
Back to discussions
Expand all | Collapse all

Timing issue when Provisioning an iPad on EAP-TLS using AmigoPod OnBoard

This thread has been viewed 1 times

  • 1.  Timing issue when Provisioning an iPad on EAP-TLS using AmigoPod OnBoard

    Posted Aug 17, 2012 11:15 AM

    For the past few months I've been chasing an issue that seems to be related to a timing distrepancy between Amigopod and our Aruba 3600 controller.    I've opened several TAC cases on this issue and they can't seem to put their finger on it.   

     

    We started our rollout of corporate issued iPads about 2 months ago, while we were running on Amigopod 3.7, all seemed fine with provisioning.   The process we follow is we setup the iPad, connect to a Provisioning SSID,  within Safari go to our Provisioning web page, download the Root cert, then enter our AD credentials, which authenticates with our MS NPS Radius server for authentication.  All the certs (terminated on the controller) download with no issues, we get the Local Certicate Authority, Mobile Device Enrollment (Signing Certificate)  which contains the User Certificate, & Eap-termination certificate and our WiFi network Profile.     We then get the message that we can now switch to our secure network.  Upon switching to our secure network, we get the message stating 'Unable to join network xxxxx'.    I have checked all the certificates and they are not expired, nor do they have times that are in the future.     The wierd part is if we wait a certain number of hours (usually 6 hrs) we can join the secure network.    Which started us down the timing path and to our 3600 controller Clock settings.    We are in the Central Time Zone,  and have my setup as follows: 

     

    NTP Enabled  (same NTP server as Amiogpod as well as all other network equipment) 

    Correct Date,

    Time currently set for 24 hr clock and reads in GMT (which is 6 hours ahead of CST, ie... 9:55am, clock shows 15:55)

    Timezone is set for GMT -6

     

    When opening a TAC case they figured it was a simple case of the clock time being off and syncing the time would clear the issue.    We set up the NTP server and set the time to the current time rebooted the controller.   Upon the controller coming up I did a 'show clock' and the time would read for example Fri Aug 17 10:01:35 CST 2012, on my iPad I would try to connect to our secure network and receive the message 'unable to connect to network xxxx', within about 4 minutes (im assuming when the NTP synch occured)  I would do another 'show clock' and it would display Fri Aug 17 16:06:35 CST 2012 and iPad would connect to the secure network, other times it takes about 6 hours for us to be able to connect to our secure network.    Why would it not connect while the time was displayed in CST, and connect when the clock changed to GMT?   

    I'd like the controller to always read in CST as opposed to GMT, but everytime I set the clock it seems to revert back to GMT, I'm not sure if that is a cause of the issue or not.   

     

    The whole issue seems to be related to the clock on the controller but I have no clue as to how to fix it, I've tried to change the controller time to CST,  and it doesn't seem to matter.   I have also made sure that the time on Amigopod and the controllers are in sync which they are with the only exception that the controller is set to GMT -6. 

     

    Any ideas would be appreciated. 


    #3600


  • 2.  RE: Timing issue when Provisioning an iPad on EAP-TLS using AmigoPod OnBoard

    Posted Aug 17, 2012 11:35 AM

    Sounds like you have already done a great deal of troubleshooting with the TAC so I am not going to suggest any of the debug messages on the controller. They can sometimes provide some pointers as to whether it is a server side or client side failure. The only thing I can think of would be checking the timezone settings on your iPads as it might be the client looking at the issued certificate and declaring it not be not yet valid and not progresing in the TLS negotiation.



  • 3.  RE: Timing issue when Provisioning an iPad on EAP-TLS using AmigoPod OnBoard

    Posted Aug 17, 2012 11:52 AM

    Thanks Cam,  I checked the Timezone on the clients and they are set to Chicago, which is correct.  What are some of the debug commands I can look at?  TAC didn't do much in the way of debugging and I'm new to the Aruba environment and would like to see the output for myself.

     

    thanks



  • 4.  RE: Timing issue when Provisioning an iPad on EAP-TLS using AmigoPod OnBoard

    Posted Aug 17, 2012 11:58 AM

    I would have a look at some of these debug options below - this shows a successful EAP termination on the controller.

     

    Replace MAC address highlighted below with your troublesome iPad MAC address.

     

    (MDAC-MMC) (config)#logging level debugging user-debug 10:93:e9:24:6c:3f
    (MDAC-MMC) (config) #
    (MDAC-MMC) #show auth-tracebuf count 20                        

    Warning: user-debug is enabled on one or more specific MAC addresses;
                                                                         only those MAC addresses appear in the trace buffer.

    Auth Trace Buffer
    -----------------
                                                                                                                  
                                                                                                                  
    Jan 12 21:53:14  client-finish         ->  10:93:e9:2a:d9:08  00:24:6c:32:2c:68/MDAC-dot1x-dot1x_prof  -  -   
    Jan 12 21:53:14  server-finish         <-  10:93:e9:2a:d9:08  00:24:6c:32:2c:68/MDAC-dot1x-dot1x_prof  -  61  
    Jan 12 21:53:14  server-finish-ack     ->  10:93:e9:2a:d9:08  00:24:6c:32:2c:68/MDAC-dot1x-dot1x_prof  -  -   
    Jan 12 21:53:14  inner-eap-id-req      <-  10:93:e9:2a:d9:08  00:24:6c:32:2c:68/MDAC-dot1x-dot1x_prof  -  35  
    Jan 12 21:53:14  inner-eap-id-resp     ->  10:93:e9:2a:d9:08  00:24:6c:32:2c:68/MDAC-dot1x-dot1x_prof  -  -    mdac1
    Jan 12 21:53:14  eap-mschap-chlg       <-  10:93:e9:2a:d9:08  00:24:6c:32:2c:68/MDAC-dot1x-dot1x_prof  -  67  
    Jan 12 21:53:14  eap-mschap-response   ->  10:93:e9:2a:d9:08  00:24:6c:32:2c:68                        6  49  
    Jan 12 21:53:14  mschap-request        ->  10:93:e9:2a:d9:08  00:24:6c:32:2c:68                        6  -    mdac1
    Jan 12 21:53:15  mschap-response       <-  10:93:e9:2a:d9:08  00:24:6c:32:2c:68/Amigopod               -  -    mdac1
    Jan 12 21:53:15  eap-mschap-success    <-  10:93:e9:2a:d9:08  00:24:6c:32:2c:68/MDAC-dot1x-dot1x_prof  -  83  
    Jan 12 21:53:15  station-data-ready     *  10:93:e9:2a:d9:08  00:00:00:00:00:00                        3  -   
    Jan 12 21:53:15  eap-mschap-success-ack->  10:93:e9:2a:d9:08  00:24:6c:32:2c:68                        -  -   
    Jan 12 21:53:15  eap-tlv-rslt-success  <-  10:93:e9:2a:d9:08  00:24:6c:32:2c:68/MDAC-dot1x-dot1x_prof  -  43  
    Jan 12 21:53:15  eap-tlv-rslt-success  ->  10:93:e9:2a:d9:08  00:24:6c:32:2c:68                        -  2   
    Jan 12 21:53:15  eap-success           <-  10:93:e9:2a:d9:08  00:24:6c:32:2c:68/MDAC-dot1x-dot1x_prof  -  4   
    Jan 12 21:53:15  wpa2-key1             <-  10:93:e9:2a:d9:08  00:24:6c:32:2c:68                        -  117
    Jan 12 21:53:15  wpa2-key2             ->  10:93:e9:2a:d9:08  00:24:6c:32:2c:68                        -  117
    Jan 12 21:53:15  wpa2-key3             <-  10:93:e9:2a:d9:08  00:24:6c:32:2c:68                        -  151
    Jan 12 21:53:15  wpa2-key4             ->  10:93:e9:2a:d9:08  00:24:6c:32:2c:68                        -  95  
    Jan 12 22:11:58  station-down           *  10:93:e9:2a:d9:08  00:24:6c:32:2c:68                        -  -   

    (MDAC-MMC) #

    Hope this helps,

     

    Cam.



  • 5.  RE: Timing issue when Provisioning an iPad on EAP-TLS using AmigoPod OnBoard

    Posted Aug 17, 2012 01:46 PM

    Cam,

     

    Here is a short snippet from this mornings activity.   iI provisioned a brand new iPad directly out of the box.   My user cert has a time stamp of  Aug 17th, 2012 @ 7:52am CST.  According to the snippet below my device started logging on Aug 16th @ 13:51:35 then the date changes to the 17th.     The failures at 9:06-9:30 is when I tried to change the time on the controller to CST, at that time ALL iPads that have certificates failed to connect to our secure netowrk via eap-tls.   Once I changed it back to GMT time they all were able to reconnect.    Any idea's?

     

    Aug 16 13:51:35  wpa2-key3             <-  4c:b1:99:52:4b:3b  d8:c7:c8:f6:ba:21          -     151
    Aug 16 13:51:36  wpa2-key3             <-  4c:b1:99:52:4b:3b  d8:c7:c8:f6:ba:21          -     151
    Aug 16 13:51:36  wpa2-key4             ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:ba:21          -     95
    Aug 16 13:51:45  station-down           *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:ba:21          -     -
    Aug 16 13:51:45  station-up             *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     -     wpa2 aes
    Aug 16 13:51:45  station-term-start     *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          16    -
    Aug 16 13:51:45  client-cert           ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  1292  1292
    Aug 16 13:51:45  client-finish         ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  -     -
    Aug 16 13:51:45  server-finish         <-  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  -     -
    Aug 16 13:51:45  server-finish-ack     ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  -     -
    Aug 16 13:51:45  eap-success           <-  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  -     -
    Aug 16 13:51:45  station-data-ready     *  4c:b1:99:52:4b:3b  00:00:00:00:00:00          16    -
    Aug 16 13:51:45  wpa2-key1             <-  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     117
    Aug 16 13:51:46  wpa2-key1             <-  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     117
    Aug 16 13:51:46  wpa2-key2             ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     117
    Aug 16 13:51:46  wpa2-key3             <-  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     151
    Aug 16 13:51:46  wpa2-key4             ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     95
    Aug 16 21:02:54  station-down           *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     -
    Aug 16 21:02:54  station-up             *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9          -     -     wpa2 aes
    Aug 16 21:02:54  station-term-start     *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9          16    -
    Aug 16 21:03:11  station-down           *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9          -     -
    Aug 16 21:03:11  station-up             *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:ba:29          -     -     wpa2 aes
    Aug 16 21:03:11  station-term-start     *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:ba:29          16    -
    Aug 16 21:03:50  station-down           *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:ba:29          -     -
    Aug 16 21:03:50  station-up             *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:ba:21          -     -     wpa2 aes
    Aug 16 21:03:50  station-data-ready     *  4c:b1:99:52:4b:3b  00:00:00:00:00:00          16    -
    Aug 16 21:03:50  wpa2-key1             <-  4c:b1:99:52:4b:3b  d8:c7:c8:f6:ba:21          -     117
    Aug 16 21:03:50  wpa2-key2             ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:ba:21          -     135
    Aug 16 21:03:50  wpa2-key3             <-  4c:b1:99:52:4b:3b  d8:c7:c8:f6:ba:21          -     151
    Aug 16 21:03:50  wpa2-key4             ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:ba:21          -     95
    Aug 16 21:20:35  station-down           *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:ba:21          -     -
    Aug 16 21:56:38  rad-acct-stop         ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:ba:21          -     -
    Aug 17 15:00:03  station-up             *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9          -     -     wpa2 aes
    Aug 17 15:00:03  station-term-start     *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9          16    -
    Aug 17 15:00:04  client-cert           ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9/eap-tls  1292  1292
    Aug 17 15:00:04  client-finish         ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9/eap-tls  -     -
    Aug 17 15:00:04  server-finish         <-  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9/eap-tls  -     -
    Aug 17 15:00:04  server-finish-ack     ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9/eap-tls  -     -
    Aug 17 15:00:04  eap-success           <-  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9/eap-tls  -     -
    Aug 17 15:00:04  station-data-ready     *  4c:b1:99:52:4b:3b  00:00:00:00:00:00          16    -
    Aug 17 15:00:04  wpa2-key1             <-  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9          -     117
    Aug 17 15:00:04  wpa2-key2             ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9          -     117
    Aug 17 15:00:04  wpa2-key3             <-  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9          -     151
    Aug 17 15:00:05  station-up             *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9          -     -     wpa2 aes
    Aug 17 15:00:05  station-data-ready     *  4c:b1:99:52:4b:3b  00:00:00:00:00:00          16    -
    Aug 17 15:00:05  wpa2-key1             <-  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9          -     117
    Aug 17 15:00:05  eap-term-start        ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9/eap-tls  -     -
    Aug 17 15:00:05  station-term-start     *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9          16    -
    Aug 17 15:00:05  client-cert           ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9/eap-tls  1292  1292
    Aug 17 15:00:06  client-finish         ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9/eap-tls  -     -
    Aug 17 15:00:06  server-finish         <-  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9/eap-tls  -     -
    Aug 17 15:00:06  server-finish-ack     ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9/eap-tls  -     -
    Aug 17 15:00:06  eap-success           <-  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9/eap-tls  -     -
    Aug 17 15:00:06  station-data-ready     *  4c:b1:99:52:4b:3b  00:00:00:00:00:00          16    -
    Aug 17 15:00:06  wpa2-key1             <-  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9          -     117
    Aug 17 15:00:07  wpa2-key1             <-  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9          -     117
    Aug 17 15:00:07  wpa2-key2             ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9          -     117
    Aug 17 15:00:07  wpa2-key3             <-  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9          -     151
    Aug 17 15:00:07  wpa2-key4             ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9          -     95
    Aug 17 15:00:10  rad-acct-start        ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9          -     -
    Aug 17 09:06:08  station-down           *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:af:a9          -     -
    Aug 17 09:06:08  station-up             *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     -     wpa2 aes
    Aug 17 09:06:08  station-term-start     *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          16    -
    Aug 17 09:06:08  client-cert           ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  1292  1292
    Aug 17 09:06:08  station-term-end       *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  7616  -     failure
    Aug 17 09:06:08  rad-acct-stop         ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     -
    Aug 17 09:06:08  station-down           *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     -
    Aug 17 09:06:09  station-up             *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     -     wpa2 aes
    Aug 17 09:06:09  station-term-start     *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          16    -
    Aug 17 09:06:09  client-cert           ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  1292  1292
    Aug 17 09:06:09  station-term-end       *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  7616  -     failure
    Aug 17 09:06:09  station-down           *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     -
    Aug 17 09:06:10  station-up             *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     -     wpa2 aes
    Aug 17 09:06:10  station-term-start     *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          16    -
    Aug 17 09:06:11  client-cert           ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  1292  1292
    Aug 17 09:06:11  station-term-end       *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  7616  -     failure
    Aug 17 09:06:11  station-down           *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     -
    Aug 17 09:06:14  station-up             *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     -     wpa2 aes
    Aug 17 09:06:14  station-term-start     *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          16    -
    Aug 17 09:06:14  client-cert           ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  1292  1292
    Aug 17 09:06:14  station-term-end       *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  7616  -     failure
    Aug 17 09:06:14  station-down           *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     -
    Aug 17 09:29:58  station-up             *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     -     wpa2 aes
    Aug 17 09:29:58  station-term-start     *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          16    -
    Aug 17 09:29:58  client-cert           ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  1292  1292
    Aug 17 09:29:58  station-term-end       *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  7616  -     failure
    Aug 17 09:29:58  station-down           *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     -
    Aug 17 09:29:59  station-up             *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     -     wpa2 aes
    Aug 17 09:29:59  station-term-start     *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          16    -
    Aug 17 09:30:00  client-cert           ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  1292  1292
    Aug 17 09:30:00  station-term-end       *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  7616  -     failure
    Aug 17 09:30:00  station-down           *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     -
    Aug 17 09:30:03  station-up             *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     -     wpa2 aes
    Aug 17 09:30:03  station-term-start     *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          16    -
    Aug 17 09:30:03  client-cert           ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  1292  1292
    Aug 17 09:30:03  station-term-end       *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  7616  -     failure
    Aug 17 09:30:03  station-down           *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     -
    Aug 17 09:31:49  station-up             *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     -     wpa2 aes
    Aug 17 09:31:49  station-term-start     *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          16    -
    Aug 17 09:31:49  client-cert           ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  1292  1292
    Aug 17 09:31:49  station-term-end       *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  7616  -     failure
    Aug 17 09:31:49  station-down           *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     -
    Aug 17 15:43:09  station-up             *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     -     wpa2 aes
    Aug 17 15:43:09  station-term-start     *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          16    -
    Aug 17 15:43:09  client-cert           ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  1292  1292
    Aug 17 15:43:09  client-finish         ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  -     -
    Aug 17 15:43:09  server-finish         <-  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  -     -
    Aug 17 15:43:09  server-finish-ack     ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  -     -
    Aug 17 15:43:09  eap-success           <-  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29/eap-tls  -     -
    Aug 17 15:43:09  station-data-ready     *  4c:b1:99:52:4b:3b  00:00:00:00:00:00          16    -
    Aug 17 15:43:09  wpa2-key1             <-  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     117
    Aug 17 15:43:10  wpa2-key1             <-  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     117
    Aug 17 15:43:10  wpa2-key2             ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     117
    Aug 17 15:43:10  wpa2-key3             <-  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     151
    Aug 17 15:43:10  wpa2-key4             ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     95
    Aug 17 15:43:11  rad-acct-start        ->  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     -
    Aug 17 17:34:30  station-down           *  4c:b1:99:52:4b:3b  d8:c7:c8:f6:be:29          -     -




  • 6.  RE: Timing issue when Provisioning an iPad on EAP-TLS using AmigoPod OnBoard

    Posted Aug 17, 2012 02:16 PM

    It sounds to me like the 'valid from' date in the client certificate is being signed based on GMT time and not CST. I am getting a little out of my depth on the controller troubleshooting capabilities and it might be worth passing some of these debugs back past your TAC engineer and they should be able to dig a little deeper in terms of the server side failure.

     

    Alternatively you could look at a centralised RADIUS server for EAP Termination as a longer term solution as this will provide some additional benefits in terms of policy management for the admission of these devices and handle multiple certiifciate trust chains if this is ever required. ClearPass Policy Manager is an example of this class of RADIUS server.



  • 7.  RE: Timing issue when Provisioning an iPad on EAP-TLS using AmigoPod OnBoard

    Posted Sep 06, 2012 07:40 AM

    frankdipietro did you get any further with this?

     

    we seem to be experiencing a similar issue, only with Windows 2008 as CA and using iOS and Windows 7 devices.



  • 8.  RE: Timing issue when Provisioning an iPad on EAP-TLS using AmigoPod OnBoard

    Posted Sep 10, 2012 04:15 PM

    bone yard, I have not had any success on finding a solution to this, I'm still working with TAC to figure it out.  For now we created another SSID using WPA2, once the cert is downloaded we connect to the newly created SSID and continue with our provisioning for our MDM solution. 



  • 9.  RE: Timing issue when Provisioning an iPad on EAP-TLS using AmigoPod OnBoard

    Posted Sep 21, 2012 10:27 AM

    we went for the clearpass route, there it seems to work fine.

     

    perhaps Aruba will find the cause and fix it on the controller someday.



  • 10.  RE: Timing issue when Provisioning an iPad on EAP-TLS using AmigoPod OnBoard

    Posted Oct 01, 2012 11:02 AM

     

    Sounds somewhat like the same I struggled with, and my solution was to move EAP-Termination from Controller to Amigopod (Clearpass Guest).