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

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.
Parents
  • 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
Reply
  • 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
Children
  • 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.