PLEASE READ Advisory: Kernel memory issue affecting multiple OS (aka F**CKWIT, KAISER, KPTI, Meltdown & Spectre) for the latest updates.
We'd love to hear about it! Click here to go to the product suggestion community
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.
you are not able to do SSO with more than one AD Domain you can only join the UTM to one domain.
you'll need four proxys to archive SSO for four Domains (not for proxy profiles)
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.
In reply to DouglasFoster:
I linked to your Wiki article, Using LDAP with Active Directory, in his thread in the German Forum, Doug.
Cheers - Bob
In reply to BAlfson:
I have news. I have just begun parsing the "Group" field from the Web Proxy logs, and it created some concerns.
Log file evidence:
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.
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.