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

Cannot Authenticate User in AD environment

Hello,

I have downloaded the 30days trial of the Security Gateway version 8.301 to evaluate the product and I need some help in order to configure it.
I have an Active Directory running on a W2003 Server. 

What I am trying to do is the following:
I want different user groups to have different access levels. I know I can achieve that through "Web filtering Profiles". I have made a setup which I'll analyze later, and I am getting an "Authentication Failed" on the user's browser!

In order to configure it I followed the steps bellow (Some steps might be unnecessary, I am not sure...):

1. In WebAdmin, "Definition and Users"->"Network". I created my Domain Controller. Type:Host, Interface: Any

2. My DC is also a DNS server. So I put it as a forwarder in "Network Services" ->DNS->Forwarders.

3. In   "Network Services" ->DNS->Request Routing I created a new DNS request giving my full domain name (domain.local) and the DC as a Target Server.

4. In "Definition and Users"->Authentication->Server tab I added the DC. Both tests passed.

5. In "Definition and Users"->Authentication->SSO tab I joined the device to the domain. Current status "Joined Domain".

6.  In "Definition and Users"->Authentication->Advanced tab in the "Prefetch… " section, I selected the domain controller and the users group to be fetched daily.

7.  In "Definition and Users"->Authentication->Global Settings I ticked the "create users automatically" (not sure why) and also ticked "Client Auth." and "Web filter".

8. I created a group in  In "Definition and Users"->Users->Group tab, named test, group type: "Backend membership", backend: "AD", ticked "limit to…" and added the user group with the users I wanted.

9.  "Client Authentication" is disabled in "Definition and Users"->Client Authentication

10. Enabled Web Filtering in "Web Security"->Web Filtering->Global tab, in allowed networks put "Internal Network" and "Transparent Mode" with no "Authentication".

11. In "Web Security"->Web Filtering->URL Filtering tab, I clicked on "Block Content that does not match the criteria below" because I want my default rule to be block all.

12. In "Web Security"->Web Filtering Profiles->Filter Actions tab I created a filter with some restrictions.

13. In "Web Security"->Web Filtering Profiles->Filter Assignments tab I created a new filter assignment. Named it Test, added the group which I selected it from the prefetched groups and put as "filter action" the previously selected filter action.

14. In "Web Security"->Web Filtering Profiles->Proxy Profiles tab, I created a new profile, named it Office, source network: internal, filter assignments: the previously created, fall back action[:D]efault filter action, Operation Mode: standard, Authentication Mode: AD SSO.
 
From the User side now, I just put the Astaro's IP as a gateway and in IE settings, proxy server, I put astaro.domain.local in port 8080. (astaro is the name of my Gateway). Also ticked "Bypass proxy for local addresses". 
In any page I put (apart from my intranet page) I get an Access denied: Authentication failed error….
What am I missing…?

Thank you in advance and forgive me for the long message but I wanted to include every step I did…


This thread was automatically locked due to age.
Parents
  • Hi, GRUser, and welcome to the User BB!

    The easy answer would be to use an FQDN that resolves to the IP of the Astaro instead of the numeric IP.  That forces the use of Kerberos instead of NTLM.  You might want to look in the KnowledgeBase at URL="http://www.sophos.com/en-us/support/knowledgebase/2800/2450/4550/115659.aspx"]HTTP/S Proxy Access with AD-SSO[/URL] (Caution, the section "Configure User Authentication" should be eliminated as it has no effect on AD-SSO and can cause problems in larger organizations).  I may be confused about your #13 - I assume you mean the group created in step 8.

    A few comments on your post to clarify:

    1. This was not necessary for AD-SSO

    2&3. See DNS Best Practices

    6&7. In general, this is necessary only where users must be known to the Astaro: Quarantine Report and Remote Access using certificates come to mind.

    9. "Client Authentication" is a different method than AD-SSO.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hi, GRUser, and welcome to the User BB!

    The easy answer would be to use an FQDN that resolves to the IP of the Astaro instead of the numeric IP.  That forces the use of Kerberos instead of NTLM.  You might want to look in the KnowledgeBase at HTTP/S Proxy Access with AD-SSO (Caution, the section "Configure User Authentication" should be eliminated as it has no effect on AD-SSO and can cause problems in larger organizations).  I may be confused about your #13 - I assume you mean the group created in step 8.

    A few comments on your post to clarify:

    1. This was not necessary for AD-SSO

    2&3. See DNS Best Practices

    6&7. In general, this is necessary only where users must be known to the Astaro: Quarantine Report and Remote Access using certificates come to mind.

    9. "Client Authentication" is a different method than AD-SSO.

    Cheers - Bob


    Bob thank you for your answer.

    You mean to use the FQDN instead of the IP where? On the Proxy settings on the clients IE settings? That's what I did. I used the IP as a gateway on the TCP/IP properties.

    Regarding your question on step 13 you are right. That is what I mean.

    Regarding step 1 what exactly do you mean? I don't need to add the domain controller in Networks? But I will need it later in step 4...

    Regarding 2&3 I'll see the best practices and revert.

    Regarding 6&7 point taken!

    Regarding 9, I agree!

    So what is wrong...?

    Regards,
    Geo
Reply
  • Hi, GRUser, and welcome to the User BB!

    The easy answer would be to use an FQDN that resolves to the IP of the Astaro instead of the numeric IP.  That forces the use of Kerberos instead of NTLM.  You might want to look in the KnowledgeBase at HTTP/S Proxy Access with AD-SSO (Caution, the section "Configure User Authentication" should be eliminated as it has no effect on AD-SSO and can cause problems in larger organizations).  I may be confused about your #13 - I assume you mean the group created in step 8.

    A few comments on your post to clarify:

    1. This was not necessary for AD-SSO

    2&3. See DNS Best Practices

    6&7. In general, this is necessary only where users must be known to the Astaro: Quarantine Report and Remote Access using certificates come to mind.

    9. "Client Authentication" is a different method than AD-SSO.

    Cheers - Bob


    Bob thank you for your answer.

    You mean to use the FQDN instead of the IP where? On the Proxy settings on the clients IE settings? That's what I did. I used the IP as a gateway on the TCP/IP properties.

    Regarding your question on step 13 you are right. That is what I mean.

    Regarding step 1 what exactly do you mean? I don't need to add the domain controller in Networks? But I will need it later in step 4...

    Regarding 2&3 I'll see the best practices and revert.

    Regarding 6&7 point taken!

    Regarding 9, I agree!

    So what is wrong...?

    Regards,
    Geo
Children
No Data