Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 23 replies
  • Subscribers 1 subscriber
  • Views 8458 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSO-AD , user account lock on Win2008/Win7

Momohteks
Hi,

We are using AWG 7.510, and implemented SSO-AD authentication against our win2003 AD domain. This works fine with Winxp and Win 2003 clients.

We are now deploying first Windows 7 ou Win 2008 clients, and we are facing a very weird problem:

On some websites, SSO authentication fails, locks the user account, and a popup is presented to the user. ( our password policy locks the account after 5 attempts)

I insist on the fact that the account is locked BEFORE the popup is presented and the user tries to login.

On the logs i can see:

2012:02:09-13:47:13 AWG01 httpproxy[4569]: [0xae2d2ca0] auth_adir_auth_crap_callback (auth_adir.c:875) Authorization denied (NT_STATUS_WRONG_PASSWORD)
2012:02:09-13:47:13 AWG01 httpproxy[4569]: [0xa927bbf8] auth_adir_auth_crap_callback (auth_adir.c:875) Authorization denied (NT_STATUS_WRONG_PASSWORD)
2012:02:09-13:47:13 AWG01 httpproxy[4569]: [0xad82fe48] auth_adir_auth_crap_callback (auth_adir.c:875) Authorization denied (NT_STATUS_WRONG_PASSWORD)
2012:02:09-13:47:13 AWG01 httpproxy[4569]: [0xa6874f78] auth_adir_auth_crap_callback (auth_adir.c:875) Authorization denied (NT_STATUS_WRONG_PASSWORD)
2012:02:09-13:47:13 AWG01 httpproxy[4569]: [0xb1667b68] auth_adir_auth_crap_callback (auth_adir.c:875) Authorization denied (NT_STATUS_WRONG_PASSWORD)
2012:02:09-13:47:13 AWG01 httpproxy[4569]: [0xa4c80508] auth_adir_auth_crap_callback (auth_adir.c:875) Authorization denied (NT_STATUS_ACCOUNT_LOCKED_OUT)
2012:02:09-13:47:13 AWG01 httpproxy[4569]: [0xa78ac670] auth_adir_auth_crap_callback (auth_adir.c:875) Authorization denied (NT_STATUS_ACCOUNT_LOCKED_OUT)

The problem can be reproduced from any Win7 or Win2008 client, IE or firefox (didn't test other browsers), by going on this page for example :
https://www-304.ibm.com/support/docview.wss?uid=swg27017522

before the complete loading of the page, the account will be locked and an auth pop-up will show.

Thanks for any help.


This thread was automatically locked due to age.
  • 0
    Hi ,

    Are your 220 and 320 UTM on same version ?
    Are they configured the same way for web filtering and SSO ?

    All my best .
    Gilipeled.
  • 0 in reply to gilipeled
    Hi ,

    Are your 220 and 320 UTM on same version ?
    Are they configured the same way for web filtering and SSO ?

    All my best .
    Gilipeled.


    Hi,

    Yes, we use the same configuration. The proxy settings are set by a proxy.pac hosted by a domain controller. We use the Proxy Profiles with Active Directory SSO authentication.

    The profile do the same things on both sites.
  • 0
    Hi ,

    Are you using same configuration of AV scanning on both ?
    Because you mention web sockets that leads me to think maybe the AV. Breaks the web sockets.
    But it is just a wild wild guess.
    Just for checking , can you disable AV scanning in the place it does not work ?

    All my best.
    Gilipeled
  • 0
    So, I disabled the AV but no effect on the behavior. I found a little difference between both sites when going to websocket.org/echo.

    On UTM 220, I have this :

    2013:08:22-17:21:47 fw2n1fr-1 httpproxy[5597]: id="0002" severity="info" sys="SecureWeb" sub="http" name="web request blocked" action="block" method="CONNECT" srcip="192.168.50.80" dstip="" user="****" statuscode="407" cached="0" profile="REF_HttProDefault (Default)" filteraction=" ()" size="2370" request="0x855cad8" url="echo.websocket.org/" exceptions="" error=""


    The request is blocked with Authentication error status.

    On ASG320 I have this :

    2013:08:22-17:24:21 fw1n1lu-1 httpproxy[6176]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="CONNECT" srcip="192.168.2.92" dstip="174.129.224.73" user="****" statuscode="200" cached="0" profile="REF_IQIPaHnXvX (Default)" filteraction="REF_fJDgikSjOA (IT)" size="1192" request="0x10b75690" url="echo.websocket.org/" exceptions="" error="" category="178" reputation="neutral" categoryname="Internet Services"


    The request is OK.

    It is the same address, configurations are identical. But something does not work.
    Moreover, I do not understand why I see the https request because, the scan is disable for such URL.

    Thanks for your reply !

    Best,
  • 0
    Hi ,

    We must find the difference .
    If both appliances have the same version and same configuration there must be no difference in the behavior.
    We areas missing something.

    All my best.
    Gilipeled
  • 0 in reply to gilipeled
    Hi ,

    We must find the difference .
    If both appliances have the same version and same configuration there must be no difference in the behavior.
    We areas missing something.

    All my best.
    Gilipeled


    I agree !
    I just do not find it yet [:)] but I do not give up !
  • 0
    Hi ,

    There is something strange in the logs you have sent , in the one that does not work destination IP is only "" , in the one that does work there is a destination IP ADDRESS.
    Did you see that ?

    All my best.
    Gilipeled
  • 0 in reply to gilipeled
    Hi ,

    There is something strange in the logs you have sent , in the one that does not work destination IP is only "" , in the one that does work there is a destination IP ADDRESS.
    Did you see that ?

    All my best.
    Gilipeled


    yes, I saw that, this is very strange.

    I never thought about that before but I activated the Chrome Console to analyze network exchanges. So, it appears that the HTTP Header is not well formatted when using the proxy settings. When I disable it, it is well formatted.

    On site where the problem does not show up, with proxy settings the HTTP Header is OK.

    New clue !

    EDIT :

    Erf, I think it is just a consequence of the errorstatus = 407 in fact ...
  • 0
    Hi ,

    After I saw that thing in the log and after you investigated in the browser console , it looks that the cause is not the UTM , but the browser itself.
    Try to see if you config the browser proxy manually the results are the same , maybe the automatic PAC file has a problem that case this behavior.

    All my best.
    Gilipeled
  • 0 in reply to gilipeled
    Hi ,

    After I saw that thing in the log and after you investigated in the browser console , it looks that the cause is not the UTM , but the browser itself.
    Try to see if you config the browser proxy manually the results are the same , maybe the automatic PAC file has a problem that case this behavior.

    All my best.
    Gilipeled


    So, I tried some other tests. The behavior is very strange :

    PAC FILE
    With FQDN (site not ok) -> NOT OK - normal file -
    With FQDN (site ok) in .pac -> OK

    With IP (site not ok)  -> NOT OK
    With IP (site ok) -> NOT OK


    Proxy Set in HTTP PROXY
    With IP (site ok) -> OK
    With IP (site not ok) -> OK

    That I do not understand is, why the pac file has no problem on the site where the web socket work. So the problem can not come from Chrome. There actually is a problem with my UTM220.