Failing Authentication with AD

Use this forum to post questions relating to WinGate, feature requests, technical or configuration problems

Moderator: Qbik Staff

Failing Authentication with AD

Postby FishHook » Nov 27 14 3:53 am

I am using version 8.2.5.4733 to control access to the internet. We have a fairly large group and everyone seems to want to jump onto our wifi and internet with their cell phones etc. Once I tell those users who are allowed what the wifi password is, it quickly spreads across the plant. We also found a few users who where allowed to use the internet visiting sites that were ... lets just say inappropriate for a business. In trying to implement a system to only allow users that had a domain account access to the internet, I'm getting mixed results. There is one thing that I require though and that is when we have customers visit, they do need access to the internet. So, I've created a UN/PS on the domain for them to use. I'm also trying to make this "transparent" so that I don't have to configure all their computers to use our proxy. The perfect scenario that I'm looking for would be if you have a domain account .. you have access .. if you don't have a domain account then upon trying to get on the internet redirect to an "internal" webpage stating the rules and a log in option. Then users can attempt to log in with the UN/PS that I created, then they are allowed on the internet.

1.) Here's what I have done. I've restricted all access to ports 80 and 443 on our Cisco firewall to only accept traffic from the Wingate PC.
2.) I have configured intercepting connections on port 80 and 443 in the WWW Proxy Server.
3.) I have configured a policy on WWW Proxy Server: Request that first checks if user is in the domain .. etc. etc. etc.
4.) Most (if not all) users have their browsers setup to use the IP of the proxy.
5.) At some point in the policy, if all checks fails .. it goes to a redirect (internally so to bypass the proxy) and then the button login is just a redirect to our company site.
6.) A check in the policy says if the request is "our company" site .. the result is auth.
7.) Upon first implementing this ... success. It worked and worked great.

The mixed results is now some users who have domain accounts are getting error message and are not authorizing themselves with the proxy server and therefore don't have access to the internet. If I tell them to browse to the company website, the auth happens automatically and they don't have to enter credentials and are then able to browse the net.

Am I missing something?
Attachments
ProxyPolicy.PNG
Web Proxy Policy
ProxyPolicy.PNG (30.51 KiB) Viewed 4471 times
FishHook
 
Posts: 8
Joined: Nov 27 14 3:14 am

Re: Failing Authentication with AD

Postby MattP » Dec 11 14 7:36 pm

Hi,

If you check the activity panel when the users are having problems, are they showing up as an authenticated user, or are they showing up as an authenticated computername? I'm wondering if perhaps the machine is authing due to a Windows update check, then the user is inheriting the credentials from the machine and therefore failing authentication. If you force a re-authentication for domain computers does this fix the problem?

Matt
MattP
Qbik Staff
 
Posts: 991
Joined: Sep 08 03 4:30 pm

Re: Failing Authentication with AD

Postby GrahamElder » Apr 20 15 10:35 pm

Hi MattP,

I'm interested in your reply here, as we get quite a few issues with Authentication.

We use AD authentication and, as you say, where the Activity panel shows the user name as authenticated then there is no problem. In some cases though, the machine name shows as the authenticated name and the user cannot access web pages as they aren't authenticated.

This seems to happen with applications where a tray icon is running and there is no 'proxy authentication' option and where this has managed to sneak in first and make the connection before the user starts IE.

I have to go to the activity panel and repeatedly close their connection until the offending process lets go.

This has gotten more tricky now as I have a Windows 8.1 pc and it creates a session to 'wns.microsoft.com' which appears to be persistent. I cannot authenticate to the proxy server at all as this session always grabs the session first and authenticates with the machine name.

How can I address this overall issue?

Many thanks,
Graham
GrahamElder
 
Posts: 6
Joined: Apr 20 15 10:04 pm

Re: Failing Authentication with AD

Postby adrien » Apr 23 15 10:11 pm

HI Graham

this is not an unusual scenario when system services access sites through the proxy that the proxy requires authentication for. For example windows updates sites.

In these cases, these services need to authenticate to the proxy, and the only account they have is the domain computer account.

Then when the user connects, if the credentials are still cached, then the user won't be unknown, but will be assumed to be the same user - the domain computer account. If this is denied access to the site the user is trying to access, then they get denied instead of authenticating as themselvers.

there are several ways to avoid this.

1. Have some allow rules at the top of the rule table that allow access for everyone to the windows update and other sites that the system services are accessing. This prevents them having to auth, so the domain computer credentials don't get established for that IP on the proxy.

2, use a re-authenticate rule to force re-authentication at a point in the rule table where you want to start granting rights to users not computers. The rule typically looks something like this:

Result: Re-authenticate
Who: everyon except authenticated users

Regards

Adrien de Croy
adrien
Qbik Staff
 
Posts: 5441
Joined: Sep 03 03 2:54 pm
Location: Auckland

Re: Failing Authentication with AD

Postby brian.hays » Dec 29 16 7:03 am

What would be the downfall of allowing the computernames to authenticate as well as the usernames?
brian.hays
 
Posts: 7
Joined: Dec 29 16 6:59 am

Re: Failing Authentication with AD

Postby adrien » Dec 30 16 9:15 am

Computer domain accounts are often used to auth from a system service, most often windows update or various AV updater services.

The main downside of allowing these to auth is that they then associate the computer IP with the domain computer account, and prevent users authenticating as themselves (prevent WinGate sending auth challenges as the IP is already deemed authenticated).

This then often requires rules to overcome this, such as re-authentication rules to force the browser to deal with an authentication challenge thereby giving them an opportunity to authenticate as the logged in user.

Adrien
adrien
Qbik Staff
 
Posts: 5441
Joined: Sep 03 03 2:54 pm
Location: Auckland


Return to WinGate

Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 41 guests

cron