Security

Hi,

Does anybody have an example of a validator argument that would stop a guest from sponsoring themselves? i.e. the sponsor email must not be equal to the guest's email. I know the same person could use two different emails to get around this (the customer is choosing to ignore this obvious flaw in the plan!!!),

I suspect it's possible by putting some kind of alias into the deny array. I'm just not sure how to format it?

Any thoughts?

Cheers!

You can always force the person who received the link to login to the Clear Pass Guest Appliance to ensre that they are an authorized Provisioner.

" Require sponsors to provide credentials prior to sponsoring the guest

Hi Cjoseph!

I've already set it up so sponsors have to authorise the guests after registering (by way of clicking the email link, going to clearpass etc).

The challange in this case, is that the customer wants anybody within the business (identified by way of the sponsor email domain) to be able to "authorise" guest registrations. I've already sorted that part by way of the validator argument (in that the sponsor has to be in @customerdomain.com).

In addition, he didn't want the sponsors to have to "login" to do it, as it's too complex for them (most are um, "low skilled"). I think that rules out your suggestion?

With that in mind, he just didn't want a single member of staff (within the domain) sponsoring themselves and abusing the system as it's really only intended for real guests. People could still get around it of course by teaming up, but by doing so they have to be vocal with one another about what they're up to. So, it's different if you get my drift?

---

@The.racking.monkey wrote:

Hi Cjoseph!

 

I've already set it up so sponsors have to authorise the guests after registering (by way of clicking the email link, going to clearpass etc).

 

@The challange in this case, is that the customer wants anybody within the business (identified by way of the sponsor email domain) to be able to "authorise" guest registrations. I've already sorted that part by way of the validator argument (in that the sponsor has to be in @customerdomain.com).

 

In addition, he didn't want the sponsors to have to "login" to do it, as it's too complex for them (most are um, "low skilled"). I think that rules out your suggestion?

 

With that in mind, he just didn't want a single member of staff (within the domain) sponsoring themselves and abusing the system as it's really only intended for real guests. People could still get around it of course by teaming up, but by doing so they have to be vocal with one another about what they're up to. So, it's different if you get my drift?

 

---

You are right.  There may be no real solution to that specific problem.  If a sponsor is reduced to sponsoring himself, that means the business might not have made it easy or worth it for him to onboard his personal device.  If you are already trusting that person to sponsor others, it implies that you trust him to sponsor himself?

Making it easy to have an employee onboard his own device (which is part of the ClearPass Guest Package, by the way - http://www.arubanetworks.com/products/clearpass/policy-manager/onboard/), in combination with making the guest network a little more restrictive than employee BYOD access sometimes deals with this problem.

Hi,

I know. There's a certain irony here.

In this case, the customer business has a very restricted internal policy on internet access. i.e. it's heavily filtered and policed.

What they're trying to do, is give external parties the ability to get access, without the internal users exploiting the priviledge (whilst still allowing them to sponsor).

The only other thing that might work is being able to set a sponsor limit? So that any one sponsor email could only be leveraged say 3 times a month? Don't suppose that's possible?

I'll have a think about the bigger picture and discuss it with them some more.

Filter the guest access the same way as the internal.  Issue specific usernames and passwords to people who need moreaccess and limit who can give those out.

You could restrict the email domain so that it does not match any of the company's domains.

array (
   'allow' =>
   array (
   ),
   'deny' =>
   array (
     'invalid.org',
   ),
 )

Not sure if the last suggestion pushed me in the right direction, but I got this working!

The email validator looks like this…

array (

  'deny' =>

  array (

    0 => 'domaininquestion.co.uk',

  ),

  'allow' =>

  array (

  ),

)

The sponsor email validator looks like this…

array (

  'allow' =>

  array (

    0 => 'domaininquestion.co.uk',

  ),

  'deny' =>

  array (

    0 => '*',

  ),

)

Thanks for those who offered an opinion!