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

Weird problem with AD SSO

gente
Hello Guys,

I'm trying to configure AD SSO with an ASG220. The firewall joined our domain (W2k8 R2 but in 2k3 scheme) and when I'll do the "test Authentication" in the webadmin everything seems fine. The test passes and I get back the groups of the specific user I'm testing.

The AD authentication even works for ssl vpn, it just didn't for the proxy.

When the authentication is activated, I get a popup where I have to fill in the credentials (in IE as well as Opera). After filling in the data and closing the popup it just pops up again. This repeats several times, unless I got a page that the authentication fails. Of course I've checked the Authenication Daemon Log - there was no entry for the authorization.

I've used this guide for configuration:
Astaro V7 Active Directory SSO setup and HTTP Profiles Configuration

Do you have an idea what could be wrong in my config?


This thread was automatically locked due to age.
Parents
  • 0
    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
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • 0
    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
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
No Data