Welcome, Guest. Please login or register.
Did you miss your activation email?
Saturday 09 November 2024, 12:54:57 pm

Login with username, password and session length

CLICK HERE for the The official Endian Roadmap and Issue tracker
14250 Posts in 4377 Topics by 6515 Members
Latest Member: hulteends
Search:     Advanced search
+  EFW Support
|-+  Support
| |-+  General Support
| | |-+  Endian requesting authentication for browsing
0 Members and 4 Guests are viewing this topic. « previous next »
Pages: [1] Go Down Print
Author Topic: Endian requesting authentication for browsing  (Read 15558 times)
ricardo.claus
Full Member
***
Offline Offline

Posts: 30


« on: Friday 22 January 2016, 02:08:47 am »

Dear,
I am deploying Endian 3.0.5 beta1, to perform authenticated proxy in AD 2012 R2, via NTLM.
The question is as follows.
The Endian already is integrated with AD, set access policies based on groups.
All desktops will feed into the AD, with the GPO to set proxy in browsers.
But the notebooks will not be added in AD.
So I left the door open on the firewall 80/443 without redirect to the proxy port. I left so for the purpose of, who is not with proxy enabled on browsers, is not to go through the proxy.

About 60% of desktops are already in AD.
Today I did a test, initially enabling the transparent proxy.
Problem: When you enable transparent proxy, the machines that are not in the AD started asking user / password to browse.
I did not even test the non-transparent proxy, as already seen that the problem already occurs with the transparent proxy.

Someone knows how to solve this problem?
Logged
mrkroket
Hero Member
*****
Offline Offline

Posts: 495


« Reply #1 on: Friday 22 January 2016, 02:55:58 am »

It depends a lot on you HTTP Proxy rules.

What you can do (meanwhile you don't migrate all users to AD) is to add some HTTP rules to allow unauthenticated users.

So your HTTP Proxy rules should be: 1) Allow unauthenticated, 2) Allow authenticated

1-Source: IP or MAC, and write down all non-AD computers by MAC address or IP Authentication: disabled Destination: ANY Filter Profile: A profile you have (with the whitelisted and blacklisted domains you need)
2-Source:GREEN/ORANGE/BLUE, Authentication: enabled Destination: ANY Filter Profile: A profile you have (with the whitelisted and blacklisted domains you need).

If you can't get the MAC address of the notebooks, you can try to separate them to the BLUE zone and set the proxy transparent on that zone.

P.S.: It's not recommended to use Source:ANY on HTTP Proxy, if you misconfigure external access you can become an open HTTP proxy to the internet.
Logged
ricardo.claus
Full Member
***
Offline Offline

Posts: 30


« Reply #2 on: Friday 22 January 2016, 06:07:42 am »

Dear mrkroket,
The first rule, if I do not put the MAC or IP for unauthenticated, the rule will allow unauthenticated connections?
The problem is that visitors will come with notebooks ... If so, when you get a visitor, I will have to get the IP or MAC of each of them to register in the rule.

To use the blue zone, you'll need to add a new network card?
Logged
mrkroket
Hero Member
*****
Offline Offline

Posts: 495


« Reply #3 on: Saturday 23 January 2016, 05:31:08 am »

Having to register visitors' MAC is unfeasible, you must think about some way to difference between unauthenticated and authenticated.
Could be whatever you like/can: By MAC, by IP, by subnets, by CIDR, etc etc.

The whole idea that you must achieve on your rules is:

1-Create an unauthenticated rule that catch all visitors BUT doesn't affect to your authenticated users.
2-Catch anything, and request authentication.

This way you trap all visitor requests with the first rule, and they don't get any auth request because the rule don't ask for.
With the second rule you catch the rest of the traffic (that is, your authenticated users).
 So the thing is that AUTH rule only fires with AUTH users, and UNAUTH rule only fires with UNAUTH.


You do need a second interface for blue. It can be a physical NIC or a VLAN. Endian accepts VLAN's, but you need a managed switch with VLAN support, and it's more complex.
I can recommend some options:

Option 1:
Catch MAC address from auth users first.
Rule 1: Catch all AUTH users. Create an AUTH rule with the MAC of your authenticated users
Rule 2: Catch anything. It's an UNAUTH rule for everything else.

Pros: This option is good if you authenticated users are few, and don't change a lot. Not to hard to setup. Doesn't require new hardware
Cons: With a lot of users it becomes hard to manage, and it's hard to link users with MAC Address.

Option 2:
Separate users by IP ranges:
If you use DHCP, create fixed DHCP leases for your known users, and move it outside your DHCP range.
Set your DHCP range to a simple CIDR range. Use a CIDR calculator (like http://www.subnet-calculator.com/cidr.php ) to group users.
For example set your DHCP range from 192.168.0.128 to 192.168.0.254 (change 192.168.0 for your real subnet), that range correspond to the  192.168.0.128/25 CIDR.
Range 192.168.0.1 to 192.168.0.127 translates to 192.168.0.0/25, and it's for AUTH users.
I.e: You have 30 users, and you want to auth them. Create a fixed DHCP lease for each of them, all of them with IP's below 192.168.0.128.
Rule 1: Source IP: 192.168.0.128/25, UNAUTH.
Rule 2: Source IP: 192.168.0.0/25, AUTH

Pros: Don't require new hardware. DHCP fixed leases allow to identify what MAC belongs to what computer/user.
Cons: Hard to manage. Hard to setup. Clients with admin privileges can change their IP and exit for the other rule.

Option 3: (recommended, but you need new hardware)
Add a BLUE zone for visitors, you need a new NIC and some changes on your network. The easiest setup is to add a NIC for BLUE, and connect only an Access Point to that NIC. All users connecting to that WiFi will be on BLUE zone.

Configure HTTP Proxy: BLUE zone as transparent, GREEN as non transparent.
Rule 1: Zone BLUE, UNAUTH rule
Rule 2: Zone GREEN, AUTH rule.

Pros: Cleaner and easier to manage. Set up and forget.
Cons: Adds some complexity with NIC's and Access Points.


Logged
ricardo.claus
Full Member
***
Offline Offline

Posts: 30


« Reply #4 on: Thursday 28 January 2016, 04:43:32 am »

Dear MRKROKET,
Excuse me for being slow to respond.
After analyzing their considerations, internal board will decide how we will apply the proxy.
Any news I will post here.
I appreciate your cooperation.
Hugs!
Logged
Pages: [1] Go Up Print 
« previous next »
Jump to:  

Page created in 0.063 seconds with 19 queries.
Powered by SMF 1.1 RC2 | SMF © 2001-2005, Lewis Media Design by 7dana.com