Block known AD users from Guest LAN

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.
Palo Alto Networks Approved
Palo Alto Networks Approved
Community Expert Verified
Community Expert Verified

Block known AD users from Guest LAN

L3 Networker

We have two types of network. The internal LAN and guest LAN. These are two separated networks
On the internal LAN we have use other policies then the guest LAN. Our employees connect to the guest LAN to avoid the policies on the internal LAN. So I created a block rule on the guest LAN if the user =  AD User.
On the internal LAN we have an active directory server and we use user identification.
On the guest LAN I also enabled user identification, but the users don't get recognized and the policies doesn't work.
I think the problem is that from the guest LAN you can't contact the internal AD server, but that is also the purpose.

What can I do to fix this?

1 accepted solution

Accepted Solutions

Cyber Elite
Cyber Elite

@ZEBIT,

You have nothing to identify the user if you're restricting access to internal resources, that in my mind is all "by design" when dealing with a guest network. Assuming that you are using issued devices, you could easily use a netsh wlan filter to block the guest SSID on your issued endpoints. 

Alternatively you simply make sure that your guest network is blocking the same resources, if not more, than what you allow on the internal network. Essentially making sure that users don't have a reason to ever connect to the guest network. 

 

Another alternative, stop using technology to fix HR problems. If you have a way of identifying these users already setup, and a policy to prevent this sort of bypass, then document it and send it up the chain of command. At the end of the day this isn't a technology failure, it's a process/policy failure. If your internal network is more stringent than your guest network, of course users are going to bypass those restrictions if they can. Either take away their ability to connect to the guest network, make the guest network more stringent than the internal network, or this happens. 

View solution in original post

4 REPLIES 4

Cyber Elite
Cyber Elite

Hello,

For the past few networks I managed, we set the same restrictions on the guest networks, etc. Actually they were a bit more stringent since we didnt want to apply user-id and policies based on it, etc. So if a person connected to the guest network, they only had access to the internet and the url filters were more stringent.

 

Regards,

Cyber Elite
Cyber Elite

@ZEBIT,

You have nothing to identify the user if you're restricting access to internal resources, that in my mind is all "by design" when dealing with a guest network. Assuming that you are using issued devices, you could easily use a netsh wlan filter to block the guest SSID on your issued endpoints. 

Alternatively you simply make sure that your guest network is blocking the same resources, if not more, than what you allow on the internal network. Essentially making sure that users don't have a reason to ever connect to the guest network. 

 

Another alternative, stop using technology to fix HR problems. If you have a way of identifying these users already setup, and a policy to prevent this sort of bypass, then document it and send it up the chain of command. At the end of the day this isn't a technology failure, it's a process/policy failure. If your internal network is more stringent than your guest network, of course users are going to bypass those restrictions if they can. Either take away their ability to connect to the guest network, make the guest network more stringent than the internal network, or this happens. 

L5 Sessionator

You could create dynamic user groups using MAC addresses, so when computers connect to a network the policies associated with the 'user' aka device connects policy is still enforced. 

 

You could also simplify that significantly with Palo's IoT solution, automated device discovery that pushes mappings to the NGFW, and write policies for managed endpoints. 

Help the community! Add tags and mark solutions please.

Thanks all for this info. I know now which direction I need to go.

  • 1 accepted solution
  • 1949 Views
  • 4 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!