cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1173
Views
0
Helpful
5
Replies

Unwanted Auth. PopUps

Hello Community,

shortly after having implemented a pair of S650s we started to run into problems with unwanted auth. popup windows that would appear every now and then.

Even though we have already opened a ticket and the Support Team is working hard on getting the issue resolved I'd still like to share our experiences with the rest of you to see if anyone else has run into a similar problem yet.

The scenario:

- Two S650s running in "failover-mode" by a hand-made wpad.dat file, running version 5.5.2-027
- placement: DMZ subnet connected to a Juniper SSG550M firewall, currently allowing ANY service to the AD/DCs
- authenticatin is based on NTLM(SSP)
- AD/DCs running on W2k3 in native mode
- testauthconfig runs fine every time we test it, the only hickup being a "High Latency: (0.261s) for <coro>" when we run it on the CLI.


The problem:

Most of the time web browsing seems to work just fine, but after an undefined amount of time auth. popups appear left and right when clients or apps try to access the web. In case the user is too fast in hitting the "cancel" button an proxy auth. error is being displayed, but if he waits 2-3 seconds he can just click cancel but the site is still being displayed after the user was properly authenticated.

So far we haven't been able to find any errors in the AD logs that might give a clue about why authentication didn't work for a split second. Our last hope was the upgrade to the latest release that seems to have fixed a few issues around NTLM, but since it didn't help in resolving the issue we might have to start all over again.

Now I am curious to see if anyone else has experienced a similar issue yet.

Torsten

5 Replies 5

jowolfer
Level 1
Level 1

Torsten,

What version of the WSA are you running? Each major release handles auth a little differently (Getting better each time - of course! :) )


- Two S650s running in "failover-mode" by a hand-made wpad.dat file, running version 5.5.2-027


;)

gsc_ironport
Level 1
Level 1

We had these unexpected "auth-pop-ups" under heavy load conditions. At that time we were using AsyncOS 5.2.0-467. Haven't repeated tests anymore with such a big user community "hitting" the S650. We tested it with > 2.000 potential users on the same WSA.

How many users are utilizing your S650 at the same time? Have you checked through the CLI command "proxystat" the number of req/sec when this behavior occured? Could it be that the Active Directory DC becomes the bottleneck when too many authentication requests (note that each requested URL is being authenticated against the AD) are hitting the DC? Is the DC running on 32- or on 64-bit Windows Server 2003 and how much memory do you have in that DC?

Testing is being done by 5-10 users right now. So nothing that could bring the system anywhere close to being overloaded (at least I hope so).

Output from the proxystat usually looks like this, even though it's hard to get a reading from when the errors occur, since they happen so randomly.

%CPU reqs client server %bw disk disk
used /sec hits misses kb/sec kb/sec saved wrs rds
0.56 0 0 0 0 0 0.0 0 0
0.62 0 0 0 0 0 0.0 0 0
0.80 0 0 6 6 0 100.0 0 0
0.75 0 0 0 0 0 0.0 0 0
0.54 0 0 0 0 0 0.0 0 0
0.77 0 0 0 0 0 0.0 0 0
0.56 0 0 0 0 0 0.0 0 0
0.69 0 0 0 0 0 0.0 0 0
0.77 0 0 3 3 0 100.0 0 0
0.69 0 0 0 0 0 0.0 0 0

I am not 100% sure about the AD setup, but will find out.

EDIT: Domain Controllers run on Win2003-32bit SP2 on IBM servers with 4x Xeons (E5320 @1.86Ghz) and 2GB of RAM

-T

gsc_ironport
Level 1
Level 1

Well, as you are using the WSA with just a few users the Active Directory definetely shouldn't be the bottleneck. However it still can be, depending on the size of the Active Directory itself. Furthermore 2 GB of RAM could also be an issue. If there is no big performance issues with the AD in general I would not expect the AD being responsible for the behavior of the WSA. It would be good to know a bit more about your AD size (look for the NTDS.dit file).