Web Appliance RE: User authentication via Active Directory

If you enable AD authentication it will allow you to associate Policy and reporting to a domain\user ..

AD integration will allow you to create more robust policy and ensure that the correct people can access the correct sites..

for example you could create policy based on teachers, or students.. you could in turn go down to the site leve and say teachers can access this and students cant.

in terms of reporting enabling https scanning will produce the best results, but regardless any traffic to the appliance will show DOMAIN\user in all traffic.. so you can generate any report on any DOMAIN\user .. you can also create reporting groups and include all of your AD trees into them..

Without authentication you are limited to rules based on IP address, for example anyone from 192.168.1.10 network can go to youtube but any one on  192.168.1.20 can’’’’t.  (for example)

AD interaction has a dramatic effect on everything from policy, logging and all aspects of reports I would consider it essential for the web appliance.

When setting it up .. I would recommend (adjust to taste)

configuration / system / authentication / default settings

Authenticate using

check off single sign on

(also check perform sso for mac if you have macs on your domain)

do not check off captive portal

on authentication  failure.

block access.

this policy would apply to all of your wired stuff on the domain. so chances are that’’’’s the majority of the connections..

after that I would set up a captive portal on WIFI. 

so under connection profiles create a new one,, call it WIFI then under the IP range put in the WIFI range.. 10.10.10.1/24

save that.

click on authentication again , this time select the profiles tab

create a new profile.

set it to authenticate using the captive portal, and again set it to block access.

this will present a log in scree to anyone on the 10.10.10.1/24 network .. when uses log in they can surf the net (I would recommend a 1hr credential. 

you can create additional authentication profiles or profiles based on user agent string to taste.. (may people have like Ipads or other devices that are not on the domain, so you could create an authentication bypass for those devices) 

so this policy would :

for anyone logging into a wired machine that’’’’s on the domain authentication is totally transparent.. clients who are not logged into the domain on the wired net work are denied access.. anyone on the 10.10.10.1/24 network would receive a captive portal log in request or be blocked.. and then if you made bypasses for say Ipads.. they would not receive any log ins or indication they are on the network.. you could in turn make policy to block sites  for unauthenticated people.

Keep in mind this is just an example, you can pretty much do anything with the applaince

If you enable AD authentication it will allow you to associate Policy and reporting to a domain\user ..

AD integration will allow you to create more robust policy and ensure that the correct people can access the correct sites..

for example you could create policy based on teachers, or students.. you could in turn go down to the site leve and say teachers can access this and students cant.

in terms of reporting enabling https scanning will produce the best results, but regardless any traffic to the appliance will show DOMAIN\user in all traffic.. so you can generate any report on any DOMAIN\user .. you can also create reporting groups and include all of your AD trees into them..

Without authentication you are limited to rules based on IP address, for example anyone from 192.168.1.10 network can go to youtube but any one on  192.168.1.20 can’’’’t.  (for example)

AD interaction has a dramatic effect on everything from policy, logging and all aspects of reports I would consider it essential for the web appliance.

When setting it up .. I would recommend (adjust to taste)

configuration / system / authentication / default settings

Authenticate using

check off single sign on

(also check perform sso for mac if you have macs on your domain)

do not check off captive portal

on authentication  failure.

block access.

this policy would apply to all of your wired stuff on the domain. so chances are that’’’’s the majority of the connections..

after that I would set up a captive portal on WIFI. 

so under connection profiles create a new one,, call it WIFI then under the IP range put in the WIFI range.. 10.10.10.1/24

save that.

click on authentication again , this time select the profiles tab

create a new profile.

set it to authenticate using the captive portal, and again set it to block access.

this will present a log in scree to anyone on the 10.10.10.1/24 network .. when uses log in they can surf the net (I would recommend a 1hr credential. 

you can create additional authentication profiles or profiles based on user agent string to taste.. (may people have like Ipads or other devices that are not on the domain, so you could create an authentication bypass for those devices) 

so this policy would :

for anyone logging into a wired machine that’’’’s on the domain authentication is totally transparent.. clients who are not logged into the domain on the wired net work are denied access.. anyone on the 10.10.10.1/24 network would receive a captive portal log in request or be blocked.. and then if you made bypasses for say Ipads.. they would not receive any log ins or indication they are on the network.. you could in turn make policy to block sites  for unauthenticated people.

Keep in mind this is just an example, you can pretty much do anything with the applaince