Webproxy with AD SSO, non-domain clients login request without domain name in URL

By default authentication is done via the hostname.  This is because Internet Explorer will consider this an intranet site and be willing to do silent SSO to it.

If you cannot resolve it on your clients (you are not using the UTM for dns) (and you don't want to add the domain name to automatic suffix) then you can get the UTM to use the FQDN instead.

On the command line:

cc set http adsso_redirect_use_hostname 0

(set to 1 to turn it back on)

This will not use the FQDN.  IE will now do password pop-ups because it thinks that some internet site is asking for your password.  To get rid of the prompt, in IE you can set the UTM fqdn as a Intranet site.  This can also be done via an AD push.  FF has a similar problem and again can be configured (network.negotiate-auth.trusted-uris)

The Situation is this.

We have some locations connected via vpn, vpn HUB + UTM is located in a datacenter and the UTM serves as central firewall for about 30 differnt subnets.

Now we have Proxy transparent mode + AD SSO enabled, works great as long as the client is in our Windows domain.

So we don't speak about AD domain clients but about non-domain clients which cannot resolve UTM's hostname/netbios name while trying to hit UTM's authentication page.

Now when a business partner comes to visit a department, connects I want to give them Internet access and here comes the issue.

The browser shows only https://fxx-dxxx/IDxxxxxx

The computer of the business partner gets an IP from the dhcp + nameserver of locations AD server, the AD server cannot resolve fxx-dxxx and the authentication process fails.

As soon as an entry in computers local hosts file exist which points to the UTM, then the auth process works fine, becaues the pc can resolve the name. Second option is to add the local domain suffix in the network settings of the partner pc, it works also. Manipulating partner clients IE, FF, Chrome settings as well as hosts or network settings in order to have UTM netbios name in local zone is not an option because of legal rules.

The problem could be fixed easily when the UTM would respond with the correct FQDN, which would be resolvable for non-domain clients.

For Phones and Tablets it's the same situation, now we have set the authenticate option NONE...

I don't understand why Sophos UTM gives out netbios names, although the AD intergration is active, this is a clear indicator that we have a domain environment which we have to handle by domain names. At least there should be an supported option to switch between.

I will setup a testsystem tomorrow to test "cc set http adsso_redirect_use_hostname 0" option. Would the change breake the support contract?

If somebody from Sophos support reads this, please tell my why UTM doesn't use FQDN for authentication of non-domain clients when AD integration is active? Is there any reason for this.

Daniel

Daniel, this isn't a venue to have conversations with Sophos.  Occasionally, a Sophos employee will show up here, but 99% of the answers here come from other members like you.  If you have a suggestion for improvement, go to the Features site.

For your current issue, I think you would be best served by opening a case with Sophos Support.  Please let us know the result of your case.

Cheers - Bob

>>the AD server cannot resolve fxx-dxxx and the authentication process fails.

If you configure your AD server so that it resolves the bare hostname of the UTM does this solve your problem?

>>I don't understand why Sophos UTM gives out netbios names, although the AD intergration is active, this is a clear indicator that we have a domain environment which we have to handle by domain names. At least there should be an supported option to switch between.

>>please tell my why UTM doesn't use FQDN for authentication of non-domain clients when AD integration is active? Is there any reason for this

To get around an annoying IE/FF authentication pop-up.  Microsoft (and Mozilla) consider a webpage to be "Internet" if it has a FQDN, even if it on the same domain.  Blame browsers being secure.  There is a supported option to switch for fqdn.  It is not frequently used and is only accessible via backend.  It does not invalidate support but if you make that change make sure that you tell any support person (so they know they are not dealing with a default config).

Google "adsso_redirect_use_hostname" to find related threads and discussions.  Read up so we don't have to repeat in this thread.

But as Bob suggested, the forums are for quick sharing of info on known problems and common configuration issues.  If you need real help for your specific scenario, use Support.

Hi Michael,

I have a support case open with our Sophos partner but they have to ask their support as well.

They also suggested to add the bare hostname to AD, in order to make the clients resolve the name, unfortunately they cannot say how to do it. I work for some years with AD now and I had never the demand to do so.
After spending half a day to get it working, I didn't get it.

Well, is the suggestion to add the bare hostname to AD in order to resolve it just an idea of a possible fix, or is it a known solution? Please give me a hint how to add bare hostnames in a domain driven AD system.

As soon as I get any news from the support, I'll let you know.

Daniel

Daniel, what happens if you assign the local domain with your DHCP server?  I think the clients should then append that to the hostname when requesting name resolution.

Cheers - Bob

Daniel, what happens if you assign the local domain with your DHCP server?  I think the clients should then append that to the hostname when requesting name resolution.

Cheers - Bob

Hi Bob,

sounds interesting, I'll try it tomorrow and give feedback.

Hello Bob,

your recommendation to add the domain name as dhcp option works stable.

So this is a possible solution.

Best regards,

Daniel