I'm trying to find out the options for authenticating remote users via IMEI and MISDN values via ACS 5.3
I'm unfamiliar with the Radius attribute options here and what kind of request/response we can utilise. Also previously I could define IP pools on ACS 4 but can't seem to do that now. Is there a way have ACS 5.3 to provide a DHCP server address for the connection ?
This question was prevously asked in relation to ACS 5.2 but no answer was provided via the forum discussion hence the reposting.
As per the IP Pools feature, the ACS 5.x does not include such functionality. It is not on the ACS 5.x roadmap either as the recommended scenario would be to use a dedicated DHCP server.
ACS 4.x included that functionality, however, it was not the best solution as the ACS returned the IP Address value as a RADIUS Attribute instead of acting as a real DCHP server.
As per the IMEI and MISDN I am assuming you are referring to International Mobile Equipment Identity and Mobile Subscriber ISDN. Correct me if I am wrong.
In that case it seems that the ACS 5.x should be able to Allow or Deny access based on Radius Attribute 30 (Called-Station-Id) and 31 (Calling-Station-Id).
In that case you might want to use the End-Station Filters feature and use it as the condition for the Rule. The End-Station Filter feature uses CLI/DNIS where CLI is Radius Attribute 31 and DNIS is Attribute 30.
I am assuming a Generic Username will be embedded on the devices request. In that case you will define which end-user devices will be granted access based on the above attributes.
Here is a snapshot of the section:
NOTE: Click to enlarge.
Hope this clarifies it.
Many thanks Carlos
Is there a way we can create a list of acceptable IMEI numbers that we can check against similar to the internal users database ? So somehow record the IMEI number as the device is allocated and check against this list as the request comes in ?
Also, how does the DHCP operate now ? Wasn't the ACS 4 solution based on allocating the address after successful authentication. Do we now return a DHCP server address as part of a successful authentication rather than the actual address in a Radius attribute ?
Thanks again, Stephen.
The list of IMEI numbers must be configured manually on the End Station Filter sections. You might need to confirm with a packet capture for the RADIUS Access-Request which of the RADIUS Attributes (30 or 31) includes the number you want to filter as the value.
After determining the appropriate attribute you can start configuring the list under CLI or DNIS based on the attribute that includes the devices number. I am assuming it would be Calling-Station-ID (31) which would be CLI.
As per the DHCP concern, the clients should be able to get an IP address assigned by the DHCP server before authenticating. The authentication against the ACS will still be triggered as it is started by a switchport or an AP.
Let me know if this clarifies it.
Thanks again Carlos.
I intend to set up a test device and authenticate it an see if we can determine the appropriate Radius attribute from the logs. If I recall last time I looked at remote access radius logs on ACS 5.1 they were pretty detailed. Failing that I'll work on those two attributes 30 and 31 to get the proper setup.
A last thing if you don't mind. Is it possible to hold back the DHCP address until authentication has completed ? I have been asked about this but can't think of any way the APN, which will be the DHCP server, could hold back address assignment pending successful authentication.
As fas as I know, the client is configured for DHCP in his TCP/IP and EAP for his WLAN/LAN profile. EAP authentication for Wireless (AP) or Wired (Switch) will occur first before allowing the clients access to the network.
When the authentication is successful the client will be part of the VLAN Configured for the SSID or the switchport. The client should be getting an IP Address from the DHCP server under that VLAN for the client to pass traffic as expected.
Hope this helps.