Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Replies 4 replies
  • Subscribers 0 subscribers
  • Views 1202 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
Parents
  • 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.

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

Children
No Data
Unfiltered HTML