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

Authentication Single Sign On for Web Protection for multiple domains

Hello everybody,

 

we are a public school and we have 4 separate Windows domains. We can not build a trust between domains for legal reasons.

 

We would like to use SSO with our SG135 and Web Protection. We have different user groups that partly work on different PCs. So I can not solve the problem by IP address allocation.

 

If I join with the SG135 only in a domain everything works great. Only the other 3 domains can then only rudimentarily filter over the Baserichtlinie.

 

Is there a way to set up SSO for 4 domains?

 

Thanks for your tips.

 

Best regards

 

Andreas

 


This thread was automatically locked due to age.
Parents
  • You can achieve the desired results using ldap.   See my article in the wiki section of the forum.  Send me a private message if you have questions.

    You will need to use qualified usernames to avoid ambiguity between the domains.

  • I linked to your Wiki article, Using LDAP with Active Directory, in his thread in the German Forum, Doug.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • I have news.  I have just begun parsing the "Group" field from the Web Proxy logs, and it created some concerns.

    My configuration:

    • Primary domain uses AD SSO
    • Alternate domains use LDAP
    • Default Filter Action allows most web functions.
    • Filter Profiles specify AD SSO as the authentication method.   Both AD and LDAP groups are assigned to most Policies.

    Log file evidence:

    • Username and domain fields are populated correctly for both AD and LDAP users.
    • Group field is only populated for AD SSO users.

    This suggests that maybe the LDAP domain users are getting the Default Filter Profile rather than one based on their group memberships.   However, I just ran a test, and testing shows that  the group memberships are being evaluated correctly, even though the Group field is not being populated in the logs.

    In a world that fit the UTM design perfectly, each domain would have dedicated subnets, and users would never work outside their normal subnets.   If this were the case, then the optimal solution is to configure one Filter Profile with AD SSO authentication, and another Filter Profile for LDAP authentication, with appropriate network range limits applied to each Profile.

    I plan to open a case with support to draw there attention to the missing Group data, but have not done this yet.

  • On further inspection, I have confirmed that the FilterAction and Profile fields of the log are being populated correctly for LDAP users.  This confirms my test results, which indicated that LDAP group memberships were processed correctly, even though the Group field of the log is empty, and even though the FilterProfile references AD SSO instead of LDAP as the authentication method.

Reply
  • On further inspection, I have confirmed that the FilterAction and Profile fields of the log are being populated correctly for LDAP users.  This confirms my test results, which indicated that LDAP group memberships were processed correctly, even though the Group field of the log is empty, and even though the FilterProfile references AD SSO instead of LDAP as the authentication method.

Children
  • I tried to report a bug about the missing group="" values for LDAP users, but Support can only log bug reports on the latest version.   Since I have opted to bypass the excitement of the last 9 releases, I am not in a position to do that.  Perhaps someone on 9.503 can reproduce the problem and pursue the issue with support.