Security

Hi,

We have a test cluster setup with two CPPM's.

We are doing testing right now to see what the requests look like when we force the user requests to hit an individual CPPM to simiulate them being in different locations.

One thing that I have noticed is that during an Onboard attempt of either an Apple device or Android the Radius:IETF:NAS-Identifier

is equal to the hostname of the Publisher.

I had thought that we had made sure that the request would be processed by the Subscriber (by manipulating our DNS), but when I saw the NAS-Identifier being equal to that of the Publisher I was a little surprised.

Does the NAS-Identifier change depending upon the CPPM process the request (in the case of an Onboarding attempt)? Or does the Subscriber only act as like a gateway back to the Publisher so that all requests are always forwarded back to the Publisher for processing? 

Hopefully I explained that correctly.

Thank you,

Cheers

I believe in the case of Onboarding and Guest authentication, the NAS Identifier is equal to the Publisher since these services are centralized on it.

Thanks @thecompnerd

Much appreciated. I was a little surprised to see this. But it makes sense.

I wish there was better documentation available that went into more detail about clustering and how it works. I am sure it is coming though.

Cheers

Hi,

Sorry to bring back an old topic.

I had another question pertaining to the information availabe in the Access Tracker when in a cluster.

If you had two CPPM's clustered together that were in two different physical locations. When an authentication request comes in is there any information that would link the client request to the specific location that the request originated from?

So if you had location A (publisher) and location B (subscriber) and a request originated from location B will that request contain some information linking it to location B? This way you could have a set of services that would serve requests coming in from location B and a set of services serving requests coming from location A.

Thank you,

Cheers

---

@bourne wrote:

Hi,

 

Sorry to bring back an old topic.

 

I had another question pertaining to the information availabe in the Access Tracker when in a cluster.

 

If you had two CPPM's clustered together that were in two different physical locations. When an authentication request comes in is there any information that would link the client request to the specific location that the request originated from?

 

So if you had location A (publisher) and location B (subscriber) and a request originated from location B will that request contain some information linking it to location B? This way you could have a set of services that would serve requests coming in from location B and a set of services serving requests coming from location A.

 

Thank you,

 

Cheers

---

Bourne,

The NAS ID is a configurable parameter in the radius definition on the Aruba or Wireless LAN controller that you are sending the request from, so that might not be what you are looking for.

These are some of the incoming radius packet parameters that you can use in the Role Mappings to assign a role to your incoming authentication:

You can use the NAS ip address, which indicates the ip address of the controller it is coming from.  

You could use the "Radius:Aruba:Aruba-AP-Group" parameter to make decisions based on ap-group.

You could use the "Radius:Aruba:Aruba-Location-Id" which is the name of the access point the user is connecting to.

Last but not least you can use the "Connection:Dest-IP-Address" parameter to determine the ip address of the CPPM that the request is being sent to.  Between the Dest-IP-Address and the IETF:NAS-IP-Address, you can determine where it is coming from and what CPPM it is being sent to, to determine what you want to do....

cjoseph,

Thank you for your response it is very much appreciated.

Those are all great suggestions and I will investigate them further.

Using a Role Mapping rule is quite interesting I hadn't thought of that. That would allow me to cut down on my services if I chose to do so!

So I should see some differences in the request information that is received on the CPPM?

Sorry to ask such a weird question this will be the first real cluster I have worked with and I don't really know what is "normal" I guess you could say.

And this should included 802.1x based request as well?

The primary purpose for being able to distinguish the requests is so that for our primary 802.1x SSID we can respond with the correct VLAN depending on where the request originates from.

Is there any chance that perhaps the information in the user request could get over written by the publisher so that all requests appear as though they are coming from the location of the publisher?

Thank you,

Cheers

---

@bourne wrote:

cjoseph,

 

Thank you for your response it is very much appreciated.

Those are all great suggestions and I will investigate them further.

 

Using a Role Mapping rule is quite interesting I hadn't thought of that. That would allow me to cut down on my services if I chose to do so!

 

So I should see some differences in the request information that is received on the CPPM?

Sorry to ask such a weird question this will be the first real cluster I have worked with and I don't really know what is "normal" I guess you could say.

And this should included 802.1x based request as well?

 

The primary purpose for being able to distinguish the requests is so that for our primary 802.1x SSID we can respond with the correct VLAN depending on where the request originates from.

 

Is there any chance that perhaps the information in the user request could get over written by the publisher so that all requests appear as though they are coming from the location of the publisher?

 

Thank you,

 

Cheers

---

Bourne,

The CPPM policy model is that you:

- Gather as much information as you can about an incoming request and in the role mapping policy, you "Tag" it with internal CPPM roles.  

- When you write that role mapping policy, you use "Evaluate-all" so that an incoming authentication can be tagged with as much information  (roles) as possible.  

- In the enforcement policy, you check to see what combination of roles is tagged by the role mapping and you send back a command to the NAS using an enforcement profile based on what combination of your CPPM-defined roles are tagged on an incoming authentication.  You normally use first-applicable here because you want to send back instructions to your WLC as soon as your combination of roles is seen, in the order that they are seen.

It is all designed that you can process as much policy as possible in a service.

In the access tracker, under Input, you can see all of the attributes that can be used to tag an incoming authentication in the role mapping policy, and then send back an enforcemnt profile using the enforcement policy.

Why would you want the incoming user authentication to be overwritten by the publisher?  Please be specific, so we can advise you on what best to do.  What is the use case?

If you have two CPPM servers in the same cluster, the location of the client would not change if it is on the same controller, so you should send the same VLAN or role back.

If the access point(s) failed over to a different controller, in the CPPM enforcement profile you could send back an Aruba-Named-Vlan attribute, which would mean one VLAN on the first controller, but a different VLAN on the second controller.  Hopefully that is the use case.   CPPM would send the same attribute back, but on each individual controller the name would be translated to a different VLAN:

Bourne,

Since you are just starting to work with clusters I would recomend that you also check out a few Videos that are availible and make sure you work with one of the Clearpass or Wireless SEs to validate the cluster design.

http://community.arubanetworks.com/t5/Video/VIDEO-High-availability-for-a-ClearPass-Cluster/ta-p/78562

http://community.arubanetworks.com/t5/Video/VIDEO-Using-Virtual-IP-interfaces-in-a-ClearPass-Cluster/ta-p/78564

A couple things to keep in mind when working with cluster........

1. Latency (This is a big one when looking at remote locations auth to set of CPPMs sitting in a central location.)

2. Failover design (using VIPS for OnBoard/Guests)

3. Cluster Size.

       A. Publisher - Subscriber

       B. Publisher- Sub - Sub - etc

       C. Dedicated Publisher - Sub - Sub 

When looking at designing a cluster you need to keep in mind the total Auth each applice will have and how many CPPMs you will have in the cluster. My standard rule of thumb is that if you have 4 or more subscribers in a cluster then you should have a dedicated publisher. 

Thanks @tarnold.

I will watch those videos again as it has been a while.

The primary reason we wanted to setup the cluster was to ensure that the Guest/Onboard devices work seamlessly between our two locations. We are only a few km's away and have our employees traveling back and forth.

Latency time shouldn't be a huge issue but it is still something to keep in mind.

I will have to get more advice though this week as I will be getting more into it. I will keep your points in mind though as we stumble through the initial phases of testing.

Thank you!

Cheers

Hey cjoseph,

The CPPM policy model is that you:

- Gather as much information as you can about an incoming request and in the role mapping policy, you "Tag" it with internal CPPM roles.  

- When you write that role mapping policy, you use "Evaluate-all" so that an incoming authentication can be tagged with as much information  (roles) as possible.  

- In the enforcement policy, you check to see what combination of roles is tagged by the role mapping and you send back a command to the NAS using an enforcement profile based on what combination of your CPPM-defined roles are tagged on an incoming authentication.  You normally use first-applicable here because you want to send back instructions to your WLC as soon as your combination of roles is seen, in the order that they are seen.

It is all designed that you can process as much policy as possible in a service.

In the access tracker, under Input, you can see all of the attributes that can be used to tag an incoming authentication in the role mapping policy, and then send back an enforcemnt profile using the enforcement policy.

I appreciate the philosophy explanation behind the CPPM, it is defintiely helpful! So in general would you say it is recommended to work with role mapping policies whenever possible? 

Why would you want the incoming user authentication to be overwritten by the publisher?  Please be specific, so we can advise you on what best to do.  What is the use case?

Sorry I wasn't very clear here. I don't want to overwrite any of the user authentication requests. I was just curious if this was a behavior that the CPPM may do on it's own. The reason I ask this is because I was seeing some Access Tracker requests that had information that wasn't really making sense. Unfortunately I was away from the office when the testing began so I have limited information at this stage.

The use case would look something like this:

• Two different physical locations
• Each location has it's own set of subnets and VLANs
• Each location has it's own controller. These controllers are not setup for failover.
• Each location has a CPPM. Location A is publisher and location B is subscriber.
• Location A will have a set of services associated with it.
• Location B will have a set of services associated with it. 
• There could be better ways of doing this, but this is how we initially figured we would set it up.
• This was to ensure the correct VLAN get's sent in the RADIUS response.
• If an authentication request comes in from Location A then the services associated with Location A must handle the request to ensure that the correct VLAN and User Role are returned. And the same goes for requests originating from Location B.

If the access point(s) failed over to a different controller, in the CPPM enforcement profile you could send back an Aruba-Named-Vlan attribute, which would mean one VLAN on the first controller, but a different VLAN on the second controller.  Hopefully that is the use case.   CPPM would send the same attribute back, but on each individual controller the name would be translated to a different VLAN:

This is a very interesting idea. I didn't know this could be done. We could perhaps use this in place of the different services. It could be a more efficient way of managing the requests.

Thank you,

Cheers

 

I appreciate the philosophy explanation behind the CPPM, it is defintiely helpful! So in general would you say it is recommended to work with role mapping policies whenever possible?   Absolutely

 

 

 

If the access point(s) failed over to a different controller, in the CPPM enforcement profile you could send back an Aruba-Named-Vlan attribute, which would mean one VLAN on the first controller, but a different VLAN on the second controller.  Hopefully that is the use case.   CPPM would send the same attribute back, but on each individual controller the name would be translated to a different VLAN:

 

This is a very interesting idea. I didn't know this could be done. We could perhaps use this in place of the different services. It could be a more efficient way of managing the requests.

 

Thank you,

 

Cheers

Bourne, Tarnold is absoultely right.  Clustering using 802.1x is fairly straightforward, and I was answering those questions.  However, clustering when you need to layer on guest and onboard has quite a few considerations, mostly with your server certificates, to ensure it is working the way you need it to.  The documents he mentioned are essential to your success.

Hi cjoseph,

I'll review the videos tarnold suggested again.

Still have a lot to learn.

Thanks for the info!

Cheers

---

@cjoseph wrote:

 

I appreciate the philosophy explanation behind the CPPM, it is defintiely helpful! So in general would you say it is recommended to work with role mapping policies whenever possible?   Absolutely

 

 

 

If the access point(s) failed over to a different controller, in the CPPM enforcement profile you could send back an Aruba-Named-Vlan attribute, which would mean one VLAN on the first controller, but a different VLAN on the second controller.  Hopefully that is the use case.   CPPM would send the same attribute back, but on each individual controller the name would be translated to a different VLAN:

 

This is a very interesting idea. I didn't know this could be done. We could perhaps use this in place of the different services. It could be a more efficient way of managing the requests.

 

Thank you,

 

Cheers

Bourne, Tarnold is absoultely right.  Clustering using 802.1x is fairly straightforward, and I was answering those questions.  However, clustering when you need to layer on guest and onboard has quite a few considerations, mostly with your server certificates, to ensure it is working the way you need it to.  The documents he mentioned are essential to your success.

 

---

Thanks for the comment on the Role Mappings!

I went through some of my Enforcement Policies and was able to greatly simplify them by introducing more efficient Role Mappings. Opened my eyes a lot more to the power of them!

Thank you sir!

Cheers