Security

I have a requirement to use two separate login portals in amigo pod. Each portal uses a username only. Trouble is I want one code to work on one portal and not on the other - any thoughts anyone? everything is ok except both codes can be used in both portals

Can you give us a few more details about your deployment.

 

Does each login page map back to a different SSID or controller on your wireless network?

Is this working against an Aruba wireless network or other vendor?

 

If this is the case we should be able to recover the name of the SSID or unique controller address from the inbound RADIUS Access-Request and then build a business rule to reject the access code if this user is not connected to the correct network.

 

Rgds

 

Cam.

 

Does each login page map back to a different SSID or controller on your wireless network?

Yes it does

Is this working against an Aruba wireless network or other vendor?

Aruba kit - all the way through

 

Thanks - this sounds perfect - but I have never built a business rule on amigopod (newbie)

Hi cam,

 

 

Can you give us a pointer?  I have been through the documentation UG, but I cannot seem to find the specifics on where exactly the SSID can be referenced to the user account on amigopod?

 

 

Thanks a million

Each RADIUS transaction received from the Aruba controller will include a RADIUS VSA called Aruba-Essid-Name. This will give the Amigopod the context of the SSID that the authenticating user is connected to.

 

What you can do is create two roles within the RADIUS > User Roles section of the Amigopod UI - for example you might create roles called Aruba1 and Aruba2.

 

In each of these Roles you can add some simple logic to check on the connected SSID and if it doesn't the SSID associated with the access token authenticating to authenticate, you can send an Access-Reject.

 

To do this add a RADIUS attribute such as Reply-Message (the name of attribute doesn't really matter as it is just a way of processing the business rule) to the new RADIUS Role and enter the following into conditional expression section of the attribute configuration.

 

Role: Aruba1

 

return GetAttr('Aruba-Essid-Name') == 'Aruba1' || AccessReject();

 

Role: Aruba2

 

return GetAttr('Aruba-Essid-Name') == 'Aruba2' || AccessReject();

 

This conditional expression will send an Access-Reject to the Aruba controller in the event that the connected SSID doesn't match the SSID recorded in this attribute. By assigned the access token accounts to the appropriate roles when the token are created you will be able to effectively control which captive portal will be permitted for each group of access tokens.

 

Obviously feel free to change the Aruba1 and Aruba2 names in these examples to suit your SSID names and deployment specifics.

 

Hope this helps and if you get stuck the TAC can definitely walk you through any of this.

 

Cam.

 

 

 

 

Spot on - EXACTLY what I needed

 

Good product this. :smileyvery-happy:

Thanks for the pointer cam I will post up the successful method when I have one, thanks again for the help!