Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Replies 4 replies
  • Subscribers 0 subscribers
  • Views 1200 views
  • Users 0 members are here
Options
Suggested

[9.200] AD/SSO in Transparent Mode

PlatosGimp
I have been trying to test the new ability to run the HTTP proxy in transparent mode and use AD/SSO. I cant seem to get a user to be seen in the logs when AD/SSO is used in transparent mode.

Is this by design or should we still be able to see the authenticated AD users in the logs? When I switch this particular "Test AD Profile" back to standard mode, the user shows up just fine.


2014:03:10-15:07:46 UTM-92 httpproxy[808]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="GET" srcip="192.168.2.175" dstip="173.194.33.120" user="" statuscode="200" cached="0" profile="REF_HttProContaInterNetwo (Test AD Profile)" filteraction="REF_DefaultHTTPCFFAction (Default content filter action)" size="519" request="0xe695dc0" url="www.google.ca/url
  • 0
    Is the UTM acting as the default gateway for the client?

    Also, do you have FIREWALL rules that permit outbound direct HTTP/SSL access?  If so, you may wish to revoke these rules, or set a source that does NOT include client IP address pools.

    ==

    When in doubt, Script it out.

  • 0
    The transparent AD-SSO uses some funky redirects and stuff to actually work.

    I'd check to ensure that your UTM has an internal DNS (FQDN) name, of which is resovable by the client systems.

    Also, if the FQDN of the UTM differs to that of your AD DNS suffix, then you may need to add the UTM's FQDN to the LOCAL INTRANET sites list in Internet Explorer for it to all work.

    An example of the above is many name their UTMs as public resolvable hosts (eg: UTM.contoso.com) where as their internal Active Directory name space is contoso.internal

    In some cases, this can cause the authentication between the client and AD to fail because of the variance above.  It did for me.  To work around this, I needed to add the FQDN of the UTM to the Internet Explorer Security Settings 'LOCAL Intranet'...  then everything worked.

    ==

    When in doubt, Script it out.

  • 0
    Thanks kindly for responding.

    Yes on having an internal FQDN resolvable by clients

    Yes on the suffix of the UTM matching the suffix of the AD/internal domain

    And as soon as I switch to standard mode, the exact same client shows up just fine as an AD/SSO authenticated user in the logs.
  • 0
    Can you confirm that the profile you are hitting (Test AD Profile) is in Transparent Mode with AD SSO and that "Block access on authentication failure" is turned on?

    You say you are using a client and switching back and forth between transparent and standard modes.  When you are using Transparent Mode, did you remove the proxy settings on the client?


    Are there any other profiles that it could be hitting or interfering?  Try temporarily disabling other profiles.

    ----

    Transparent AD SSO will authenticate and then cache the user for five minutes, not needing to reauthenticate during that time.

    If it needs to authenticate, it will actually skip authentication in several scenarios, including URLs that have parameters or HTTPS.  I *think* (not sure off the top of my head) that it uses and logs the last known user, and if unknown it follows policy for "All Users" (often Base Policy).

    Can you try again, this time making sure you hit a normal HTTP non-parameter URL?
Unfiltered HTML