Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 1 subscriber
  • Views 13792 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

Problem with AD-SSO Transparent-Proxy

seroal
Hi all,

long time ago, I installed an utm at a customers site. If it is important, originally the hostname of the utm was utm01. Later I changed it to utm01.domain.local.
The utm joined the domain (2x AD Servers (1xWin Srv 2008 & 1x Win Srv 2008R2) but at Win 2003 functionlevel (perhaps this is interesting for you). Originally, the Transparent Mode AD-SSO with AD-Groups for specific Proxy Rules was working, but not from the beginning. The setup was already in place, but Transparent-AD-SSO didn´t work. It started working without any changes...(on the utm, perhaps the customer did sth. with the AD) That was pretty surprisingly for our support-partner and me.

Now, since december the AD-SSO isn´t working any more. Not working means, the browser displays a popup and is asking for credentials. I already re-joined the utm multiple times, but that didn´t change anything.

At first my distributor, now Sophos care´s about the ticket. So far sophos has no exact clue, what has to be done to solve the problem. Again and again I was told to check the configuration, regarding to the KB Article:
https://sophos.com/kb/120791. I´ve done that, but that didn´t do the trick.

We did a lot of captures, I could provide them for somebody, who is interested in.

I captured the following (all from exact the same time):
- Traffic at UTM with different filters (4 files)
- DC Eventlog
- DC Sysinternals Procmon Capture
- Wireshark capture Client
- AD-Attribute info for the utm Account

Domain: radiologie.local
Ip-Addr of AD-SRVs: 10.247.100.111,10.247.139.1
Client:10.247.100.101
UTM:10.247.254.22

There is an interesting thing, that I found in the capture (communication between utm and DC):

KRB Error: KRB5KDC_ERR_PREAUTH_REQUIRED
KRB Error: KRB5KDC_ERR_ETYPE_NOSUPP


I made a few extra tests, I switched to standard-proxy mode with SSO.

1.) Configuration of Client-Browser settings Proxy: "utm01.radiologie.local:8080" or "utm01:8080" ----> SSO Working fine, all the time.
2.) Configuration of Client-Browser settings Proxy: "10.247.254.22:8080" ----> SSO doesn´t work, popup appears!!! I verified this behaviour.... its reproduceable.

I don´t understand this behaviour... Standard-Proxy SSO Works, Transparent-Proxy SSO doesn´t work. I might be wrong, but for me it seems to be a problem with Kerberos/NTLM auth and the maschineaccount in the domain?!

I´ve attached some screenshots.

Current Firmware Version of the UTM: 9.210-20

Any ideas?

have a nice day,
Sebastian


This thread was automatically locked due to age.
Parents
  • 0
    The UTM does transparent mode authentication by temporarily redirecting the browser to load a page from the UTM, authenticate with it as a website (not as a configured proxy), and then redirect back to the original site request.

    If the UTM presents itself as a single hostname, IE will go "oh, it must be on the intranet" and will SSO silently.  If the UTM presents itself as a FQDN, IE will go "oh some internet site is asking for credentials, I better let the user know".

    When the user is getting the pop-up (or maybe if they hit cancel) does the address bar have the hostname or fqdn.  If the latter, this is the issue.

    This can be configured and is defaulted to hostname (except for people who installed early 9.2 beta)...  but maybe something in changing your UTM's name got it confused.

    cc get http adsso_redirect_use_hostname
    If this is 0, then change it to 1
    cc set http adsso_redirect_use_hostname 1

    Alternately if you must have the fqdn (eg otherwise unresolvable) then you need to the add the UTM fqdn to the IE list of Intranet sites.  FF has a similar config.
  • 0 in reply to Michael Dunn

    If the UTM presents itself as a single hostname, IE will go "oh, it must be on the intranet" and will SSO silently.  If the UTM presents itself as a FQDN, IE will go "oh some internet site is asking for credentials, I better let the user know". 


    Ok, but therefore we configure the browsers trusted site settings, right?

     When the user is getting the pop-up (or maybe if they hit cancel) does the address bar have the hostname or fqdn.  If the latter, this is the issue.


    Its always a simple hostname, I can change the utm´s hostname but that won´t change anything in the transparent-sso-proxy redirection url.


    This can be configured and is defaulted to hostname (except for people who installed early 9.2 beta)...  but maybe something in changing your UTM's name got it confused.

    cc get http adsso_redirect_use_hostname
    If this is 0, then change it to 1
    cc set http adsso_redirect_use_hostname 1

    I checked this, the value is already "1"


    Alternately if you must have the fqdn (eg otherwise unresolvable) then you need to the add the UTM fqdn to the IE list of Intranet sites.  FF has a similar config.


    It´s added... But at the beginning, when AD-SSO was working, I didn´t need to configure this settings.
Reply
  • 0 in reply to Michael Dunn

    If the UTM presents itself as a single hostname, IE will go "oh, it must be on the intranet" and will SSO silently.  If the UTM presents itself as a FQDN, IE will go "oh some internet site is asking for credentials, I better let the user know". 


    Ok, but therefore we configure the browsers trusted site settings, right?

     When the user is getting the pop-up (or maybe if they hit cancel) does the address bar have the hostname or fqdn.  If the latter, this is the issue.


    Its always a simple hostname, I can change the utm´s hostname but that won´t change anything in the transparent-sso-proxy redirection url.


    This can be configured and is defaulted to hostname (except for people who installed early 9.2 beta)...  but maybe something in changing your UTM's name got it confused.

    cc get http adsso_redirect_use_hostname
    If this is 0, then change it to 1
    cc set http adsso_redirect_use_hostname 1

    I checked this, the value is already "1"


    Alternately if you must have the fqdn (eg otherwise unresolvable) then you need to the add the UTM fqdn to the IE list of Intranet sites.  FF has a similar config.


    It´s added... But at the beginning, when AD-SSO was working, I didn´t need to configure this settings.
Children
No Data
Unfiltered HTML