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

AD SSO – intermittent authentication failures.

I just finished configuring SG310 under 9.315-2. The web filtering is configured to use Full Transparent mode. I have a bridge setup between the switch and a firewall with third interface (management) connected. 

Here’s a setup:

1. The SG310 is AD joined. 
2. DNS is properly configured. I am able to resolve names of all domain controllers and ping them all from the UTM.
3. Request Routing is configured for my domain and is pointing to the AD DNS severs within my AD site.
4. AD authentication server is configured. Base DN is set. All tests are Pass.
5. The AD account used in previous step have correct SPN set for HTTP service type. (i.e  and 
6. Web Filtering profile is configured to use AD SSO in Full Transparent mode. Block Access in failed authentication is checked.
7. Policy is configured to use group with backend membership = Active Directory. Limit to backend group(s) membership is set and includes group that I need.

Now, when I logon to the client PC with AD user account, it initially works fine. But after some time (could be anywhere from 15 minutes to 3 hours), a user authentication dialog box pops us. Entering AD username and password does not work. As a matter of fact, if you do enter it, it will lock the user’s AD account. If you click cancel, you get “Authentication Failed” web page. Web Fileting log shows blank username and domain. You can attempt to navigate to the same website a few more times, chances are one of the attempts will succeed only to fail again several minutes later on a different site.

Has anyone experienced the same issue and does anyone know a resolution?


This thread was automatically locked due to age.
Parents
  • I’ve been doing more digging into this issue. The problems seems to be related to Kerberos authentication on the DCs. At the time of the failure the following error messages get recorded in the log: 
    [CRITICAL] NlPrintRpcDebug: Couldn't get EEInfo for I_NetLogonSamLogonWithFlags: 1761 (may be legitimate for 0xc000006a). Basically 0xc000006a means blank or incorrect password. It appears Sophos UTM does not correctly sends authentication credentials on behalf of the user resulting in denial of resources and eventual AD user account lockout. 

    Has anyone dealt with this type of issue before?

    I have a ticket open with Sophos Support, but they been pretty useless.
Reply
  • I’ve been doing more digging into this issue. The problems seems to be related to Kerberos authentication on the DCs. At the time of the failure the following error messages get recorded in the log: 
    [CRITICAL] NlPrintRpcDebug: Couldn't get EEInfo for I_NetLogonSamLogonWithFlags: 1761 (may be legitimate for 0xc000006a). Basically 0xc000006a means blank or incorrect password. It appears Sophos UTM does not correctly sends authentication credentials on behalf of the user resulting in denial of resources and eventual AD user account lockout. 

    Has anyone dealt with this type of issue before?

    I have a ticket open with Sophos Support, but they been pretty useless.
Children
  • Hi MNGMND,

    did you ever had a response from support?

    i´m noticing this behaviour when using Firefox. Despite that initially works fine (i.e, the user is correctly authenticated, after 15 minutes, there it a popup asking for credentials).