Weird problem with AD SSO

What do you see in the fallback, aua logs?

So i finally found something in the http\s logs, but I'll think I need some help on that:

2010:09:29-13:18:24 gw httpproxy[4924]: [0xaeef0698] adir_auth_process_ntlm (auth_adir.c:567) received ntlmpkt with invalid signature: [c]
2010:09:29-13:18:24 gw httpproxy[4924]: [0xb1ac6ea8] auth_adir_auth_crap_callback (auth_adir.c:875) Authorization denied (NT code 0x00000721)
2010:09:29-13:18:26 gw httpproxy[4924]: [     (nil)] utf16le_to_utf8 (auth_adir.c:417) failed to convert username from UTF-16LE to UTF-8: Partial character sequence at end of input
2010:09:29-13:18:26 gw httpproxy[4924]: [0xaeca4988] auth_adir_auth_crap_callback (auth_adir.c:875) Authorization denied (NT_STATUS_PIPE_DISCONNECTED)
2010:09:29-13:18:26 gw httpproxy[4924]: [     (nil)] utf16le_to_utf8 (auth_adir.c:417) failed to convert username from UTF-16LE to UTF-8: Partial character sequence at end of input
2010:09:29-13:18:26 gw httpproxy[4924]: [0xb20bc438] auth_adir_auth_crap_callback (auth_adir.c:875) Authorization denied (NT_STATUS_PIPE_DISCONNECTED)
2010:09:29-13:18:26 gw httpproxy[4924]: [     (nil)] utf16le_to_utf8 (auth_adir.c:417) failed to convert username from UTF-16LE to UTF-8: Partial character sequence at end of input
2010:09:29-13:18:26 gw httpproxy[4924]: [0xafd0d9a8] auth_adir_auth_crap_callback (auth_adir.c:875) Authorization denied (NT_STATUS_PIPE_DISCONNECTED)

Good calls, techuser!

Gente, check out: https://community.sophos.com/products/unified-threat-management/astaroorg/f/55/t/44385

Cheers - Bob

Hm ok I'll understand that I have to use the Kerberos authentication when I'll authenticate my users for the proxy and the only way to do so, seems to deploy the complete FDQN (GPOs) which I already do... 

The only thing I could think of is, that I've possibly got an additional dns name for the proxy on my domain which I am deploying, I'll check that out on the next weekend, messing with the dns and deploying new GPOs would disturb our office at worktimes to much. We really depend on a working internet connection. Thanks for the help everybody, I'll let you know if it works.

It is like I've expected yesterday. 

We have a pointer set at our servers which is pointing at: 

proxy.***.local, this is also the domain name I'm deploying to the clients via GPO

The hostname in the AD is gw, but it isn't reachable and doesn't resolve on the DNS. When I'll check the hostname tab in the webadmin it says gw.ourwebsite.com, which is resolveable but points at our webservers. 

Whats the best (and possibly easiest) method to resolve this? Change the hostname to proxy and get rid of the static dns entry? Your help is very appreciated!

The Astaro doesn't "know" its FQDN as such unless you create a static entry in its DNS, but I don't think you want to do that here.  First a little discussion about how we normally do things with Astaro.

Normally, when the Astaro is in front of a mail server, we will assign a hostname like mail.domain.com, set mail.domain.com in the authoritative mail server as the highest-priority MX-record and point it at the primary IP on the External interface.  Inside the LAN, we, and most of our customers, name the internal domain, domain.local.

We configure DNS as in: DNS Best Practice and add Forward & Reverse lookup zones for the few domain.com FQDNs needed by laptop users.  For example, outside the network outlook.domain.com might resolve to 60.70.80.90, an Additional Address on the External interface used for Outlook Web Access.  Inside the LAN, we need for the internal DNS to resolve outlook.domain.com to the private, internal IP, like 10.11.12.13, of the OWA server.

To use the Web Proxy in AD-SSO mode, the Astaro must be joined to the domain.  An Astaro with a hostname of mail.domain.com will join domain.local as "mail", so you don't want to change the hostname to anything that is not resolvable in public DNS; mail.domain.com is correct.

So, in your case, I guess you want to use gw.ourwebsite.local in your GPO, and have your internal DNS aim that at the IP of the Astaro's "Internal (Address)".  If you use the numeric IP, that forces the use of NTLM, and that's not reliable; using the FQDN allows Keberos to work instead.

Cheers - Bob

Thanks for your explanations! My problem is that I haven't done the initial configuration for the astaro and the technician who did it, isn't reachable any more and we are a little bit stuck at this config by now. There are so many things that aren't configured like the recommended "Best Practices" that we are just happy, that it runs without any big problem.

Anyway I tried to add the gw.ourwebsite.local to our internal dns as static entry, it was never resolveable by any client. I think about switching to basic auth (just better than no auth) as the upgrade to an ASG320 is in the forseeable future and we probably give it a fresh start.

Depending on how you have DNS configured everywhere, you might need to add a 'Request Route': ourwebsite.local -> {Internal DNS}

Cheers - Bob
PS I just thought through my earlier post... Since the Astaro already has joined the domain as gw, I think Internal DNS should know how to resolve gw.ourwebsite.local without the static entry.

Hm I'll hope I can give you a general idea of our DNS configuration, at least I don't understand it anymore and I didn't configured it.

Our external and internal domains have different names, internal its the short term for our company (for example: ghi.local) external it is ghi-company.com.

The mx record mail.ghi-company.com (and webmail.ghi-company.com) just points at the external IP of the firewall and there is a wildcard record *.ghi-company.com which points at our webserver which is hosted elsewhere.

When I look at the astaro DNS config, the following data is entered:

Global -> Allowed Network -> Internal Network
Forwarders -> DNS Forwarders -> our AD Server - Use Forwarders assigned by ISP is unchecked
Static Entries -> webmail.ghi-company.com -> pointed at internal mail server

At the internal DNS which is running at the AD Server, there is a static entry for

proxy.ghi.local -> internal address of the asg

I don't see an entry for gw.ghi.local on either the asg or the AD Server DNS, and of course it isn't resolvable. On the AD Server I can't create a static entry for gw.ghi-company.local because it doesn't know this domain.

Anyway the AD Server is also our DHCP. We have the following IP ranges in use: 
 

• 10.***.1.* - Servers
• 10.***.2.* - Printers
• 10.***.3.* - Clients
• 10.***.4.* - Production Machines
  
  

with a subnet of 255.255.248.0. These Nets are joined by one of our manageable switches wich is also configured as gateway (it it also deployed as gateway at the dhcp config). So I have to say, I don't see through this whole configuration anymore. It is a lot more complex than it should be...

Anyway hopefully I've given enough information, for resolving a bit of this mess and get AD SSO to work [:)]

If I were hired to "fix" your issue, my first step would be to change your DHCP and DNS configurations to conform to DNS Best Practice as described in post #17 above.

Next, I would delete all references to the Astaro in your AD server, and rejoin the domain as described in HTTP/S with AD-SSO.

Does that resolve your issues?

Cheers - Bob