I just got off the phone with technical support and the technician said that the only traffic I can authenticate is http/https. Can someone confirm that the use case below is not valid?
Here is what I want to do:
Use HTTPS to authenticate a user
After Authentication, user is allowed access to a server in a manner controlled by a security policy that non-authenticated users are not able to access.
In other words:
Mywebserver1 is a protected resource in that should allow HTTPS traffic from any resource on the internet.
ExternalTrustedUser1 is someone coming in from my internet feed that needs to be authenticated for administrative access to the server.
ExternalTrustedUser1 uses HTTPS to authenticate using webforms with Captive Portal.
After ExternalTrustedUser1 is authenticated, they are allowed to RDP to Mywebserver1 which the rest of the traffic from the internet is NOT allowed to RDP but all other internet users can use HTTPS to connect to Mywebserver1.
I see no reason that this wouldn't function as you mention. Once you are through the captive portal they will temporarily have a user-ID and therefore you could utilize that user-id mapping in a security policy allowing SSH or RDP access for example. I've never personally set something up like this and don't know how much I would recommend it, but I don't see a technical reason why it wouldn't work.
Okey dokey... its my assumption that the user-id will be based on the source ip of the user so going to re post...
Sounds like a plan... but... three words.... NAT.
User1 books his car in for a service at a toyota garage...
while he is there he authenticates to your captive portal via wifi.
this then allows 16000 plus users access to your server via your user id policy.... because they will all have the same source address...
user1 is in macdonalds.....
user1 is in a library...
you do have the option to set source ip to policy but ip spoofing is still possible even in todays world...
for me.... vpn tunnel, multi factor or 2factor auth....
worst case scenario... rdp gateway in DMZ with similar auths.
I'll agree with @MickBall here, esspecially since you are allowing RDP connections. You have a tool already (PA Firewall) that allows you to configure GlobalProtect and provide a VPN connection for these users for free without exposing RDP to the internet. Regardless of the fact you've done your best to limit that access, you've still opened RDP to the internet.
thank you for your replies as I am just curious about captive portal. It is concerning that this could open up the internet. I thought that the user ID and mapping was established with a browser session which means I would not actually opening up RDP to the internet but rather to the session that owned the session cookies. Did I miss something?
PA could only allow traffic based on IP addresses, ports and user information. You can't make rules and allow traffic based on session cookies.
Another potential issue; for CP to work on outside interface you'll have to enable User-ID on the security zone for that interface. If you have WMI queries enabled UID agent will try to send queries to any public address that tries to authenticate. So make sure you either have this disabled or to have this traffic blocked. Otherwise you're leaking information about your network and domain.
You make a very important point here. I was thinking that the only way to realistically do USER-ID on external would be to set up authentication with client certificates since there are so few that would be allowed this ability which would limit the exposure of authentication methods like NTLM.
Is there a gotcha to my idea of client certificates that I am not recognizing because I certianly do not want to leak domain or network info.
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!