Automatic IP-ADUser matching

[tlong]

We are evaluating WG7 to replace a legacy MS ISA Server install in an fully Windows LAN with AD. ISA has a client similar to WGIC which allows us to "know" the AD user for non-proxied connections. We really like WG7, but the lack of WGIC for 64 bit Win7 is the sticking point. (Side note: Not sure why Win7 64 bit support is still pending, Win7 has been out for a long time, heck Win8 is shipping.)

We want to be able to control all traffic, including non-proxy aware apps. That seems to point us to NAT for the workstations. But we also want the AD user for logging and rule enforcement. So the sticking point is how to resolve the AD user for the NAT connections, eg. Joe can run non-proxy aware apps, but not Bob.

Here's what I'm thinking (partly stolen from Untagle's solution for this)
1) Set workstations to NAT with gateway being WG7 box
2) Setup wpad / auto-proxy detection so IE always must proxy
3) Create a WAC allow rule for "Domain Users" going to a specific site (using internic.net for this)
4) Use a GPO to force workstations to run a vbs logon script
5) Logon script runs hidden loop: make an xmlhttp request to internic.net, waits 30 s., loop
6) Script loop supplies NTLM every 30s so WG7 knows the AD user for the IP (we don't use Term Services)

That seems like it will keep the IP -AD user mapping intact in WG for rules, logging, etc.

Is that the best we can do, or is there some better way?

[adrien]

Hi Tim

it's a long story basically about the issues with WinGate Client. In fact we had thought its use had basically died out back around 2001 after we had NAT. So we'd slated it for a peaceful death and then started getting a few more requests for it. That's basically why it's behind in development.

In any case for your scenario, you're more interested in associating the IP with an account, rather than a particular connection, so something like the QbikAuth login tool may be a better option. We just need to port that to work for WinGate 7, but that's a very simple task.

That is basically an app, runs in the system tray, which allows a user to log in and out. We could add options so you could control its execution centrally via GPO (e.g. enforce its use).

I'll have a look at it today. We changed the auth protocol used on the Remote Control Service between 6 and 7 which is why the old one won't work, but it's a fairly minor change.

There's another option. In credentials rules, the default settings allow you to control what happens when someone disconnects everything. You could extend the period the creds are cached, and not down-grade them. This would allow a scenario such as web first, auth, then that enables everything else. This would not really work if you have different people using the same machine all over the place though.

Regards

Adrien

[adrien]

Hi Tim

I got QbikAuth working logging into WinGate 7. It needs a few refinements, but if you're not using TLS on the Remote Control Service, it will work fine.

Let me know if you'd like a look at it for testing purposes to see

a) if it will meet your needs
b) if there are any refinements you'd like me to add while I'm stomping around in the code

Regards

Adrien

[tlong]

Adrien,

Thanks for the quick turnaround. Ideally QbikAuth would provide the user credentials to WG7 automatically w/o the user needing to enter them. Is that possible?

Also, can you point me to any documentation on QbikAuth?

Thanks.

[adrien]

Hi

Currently it requires manually entering the password, but we can certainly allow it to use currently logged in user creds like we do with WinGate Management.

In fact the new framework we have for user databases (since WinGate 7.0) means depending on the user database you're using, there may be a domain field to fill in as well.

One thing will need to be configured or discovered, and that's the location of the WinGate server.

We're also looking into the captive portal option, which would mean the user could log in with a browser first.

Regards

Adrien

[tlong]

I'm not sure how widely this applies to others, but for us the ideal behavior would similar to the ISA client. The app starts in the system tray on login, and continually stays "connected" to WG7 using the currently logged in user's AD credentials. On logout/app stop it "disconnects" from WG7. The app would show green (or some good indicator) when "connected", red or warning icon when server was not able to be contacted.

Also, on each start the app would examine the wpad DNS entry to "auto discover" the WG server. For failed connects (either on start or while running), the app would try to "auto discover" again. Some people might want to allow the user to manually enter proxy server, and/or not rely on wpad.

I think I know the answer to this, but just want to check: If we want to avoid double NAT-ting (because we have a load balancing edge solution that must NAT) then we'd need to use a proxifier versus NAT-ing, correct?

[adrien]

I'm not sure how widely this applies to others, but for us the ideal behavior would similar to the ISA client. The app starts in the system tray on login, and continually stays "connected" to WG7 using the currently logged in user's AD credentials. On logout/app stop it "disconnects" from WG7. The app would show green (or some good indicator) when "connected", red or warning icon when server was not able to be contacted.

that's pretty much what I had in mind. Attempt to auth with current windows creds first, and if that fails pop a login dialog. We need to cover the scenario where the server isn't using a Windows or AD user database. Since we support NTLM with even the WinGate user database, if the user/pass matches the windows box, then the auth succeeds.

Also, on each start the app would examine the wpad DNS entry to "auto discover" the WG server. For failed connects (either on start or while running), the app would try to "auto discover" again. Some people might want to allow the user to manually enter proxy server, and/or not rely on wpad.

I think I know the answer to this, but just want to check: If we want to avoid double NAT-ting (because we have a load balancing edge solution that must NAT) then we'd need to use a proxifier versus NAT-ing, correct?

We have a discovery service in WinGate (GDP service) that the WinGate client uses to discover the WRP service. It's possible to use that to query for Remote Control Service as well

In the end I'm not sure the Remote Control Service is the best option for simply authenticating, since it pushes a requirement for SSL onto the client even though the auth should be secure. So we may do another service in WinGate specifically for authenticating.

[adrien]

p.s.

re the double-NAT. It's not that uncommon, and I'm not sure why you'd want to prevent it. If the clients go through the proxy first, then as far as the edge firewall is concerned, all the traffic is coming from the WinGate box anyway, as would be the case if the clients were using WinGate also for NAT.

What problem does double NAT cause for you?

You could alternatively have the clients not use WinGate for default gateway, just configured to use WinGate for web proxy, and set up the edge firewall to prevent HTTP from anywhere other than WinGate.