Security

Up till now when processing wired authentication requests I've used an Authentication source that extracts the vlan a client device needs to be on from a remote MSSQL database and passed this back in the RADIOUS Access-Accept packet. Given the fact that CPPM doesn't support db connection pooling and some concerns about the resilience/reliability of our MSSQL database we've decidded to look at another way of doing this.

 

The current plan is to add an attribute to an endpoints database entry called "UoY VLAN" which, if not 0 will be the numeric vlan the client needs to be in after a successful auth. I've got most of this service implemented  but

 

1). having created an endpoints entry and added UoY VLAN  to it with an appropriate value, my corresponding  Enforcement policy needs to send back UoY VLAN to the switch. I *think* that I need to set up an authentication source that returns the value of UoY VLAN attribute associated with an endpoint entry due to the fact that when trying to assign a value to Tunelled-Private-Group-Id only shows Auth Source items in the dropdown list and explicitly setting it to   %{Authorization:[Endpoints Repository]:UoY VLAN} generated an error.

 

If I do need to create an  auth source, what would be the format for grabbing a locally defined endpoint attribute? It's gonig to be some form of select statement with the client mac address as the primary key I'd guess.

 

2). Obviously we're not going to updated our entire endpont db by hand. Given the fact that we can use appadmin to remotely access the back-end database, what we'd like to do is set up a trigger on our IPAM db so that when somethings changes ( add device,move dev onto another vlan, delete device etc) we can  update the endpoint UoY VLAN attribute as  appropriate. Where can I find the db schema for CPPM 6.5 and what might the format of an update statement be?

 

Rgds

Alex

 

 

 

Hi Alex,

 

I think you are over-complicating this. You should be able to use the %{Endpoint:UofY VLAN} in your enforcement policy for the VLAN number. It might not like the space, so you might want to change it to UofY_VLAN.

 

Couple things to check. Add Endpoints Repository to your Authorization Sources (Under Additional Sources on the Authorization tab). Also, check the data type for that attribute. String should work.

.... and it works :-)) Simples!

I've now modified my Enforcement  policy so that if UoY_Vlan exists it  uses a profile that sets Tunnelled-Private-Group-Id to be value of UoY_Vlan.

 

Now need some method of ensuring that when an entry on in our IPAM system gets changed, and vlan changes get replicated to CPPM.

Rgds

Alex

As mentioned before, this now works. Only item 2 remaining now i.e. how do I bulk define my UoY_Vlan attribute to multiple endpoint entries ?

Rgds
Alex

Alexsuoy,

 

My suggestion above means you would only have to define an attribute on your network devices like switches, NOT on every endpoint.  It also would mean as new users join the network, you do not have to add the attribute to them or change the attributes.  You would only have to add the attribute to the network devices at a physical location.  The users would get the attribute from the physical devices at a location.

Alex,

 

zjennings is right in that there is probably a simpler way.  You also do not want to enter a wired attribute for every user in a database, either, because those users move around and it is an administrative hardship.  Typically users on a specific switch are all placed into the same Data and Voice VLAN for the same switch.  What you can do, is configure a data VLAN (and a voice VLAN if you need it) for each switch in CPPM and when a user authenticates in CPPM, read the data VLAN from the switch the user is authenticating through and place them on that VLAN.  Here is how you would do it:

 

1. Define a Data VLAN for a switch using an attribute on the device in CPPM.  In this case, I used the "data-vlan" attribute:

 

2.  On your enforcement policy you would just use the "device" namespace to pull the data-vlan attribute from the switch that the user is authenticating through to put them on a specific VLAN using 

RADIUS:IETF Tunnel-Private-Group-Id %{Device:data-vlan}

That will pull the "data-vlan" attribute from the device that is handling the authentication and return it to the user as a VLAN.  If the user authenticated to the switch above, it would return vlan 20.

 

 

You could easily use:  

RADIUS:IETF Tunnel-Private-Group-Id %{Device:voice-vlan}

 ...if you wanted to return the voice VLAN for that specific switch to the user.