I just added a featureupvote for Untangle to handle the Username field better.

[WebFooL]

I do believe that there are more then my clients that use Oauth/Office365 and with the current setup there are multiple ways the users userPrincipalName can enter the Username field in Untangle instead of the sAMAccountName.

This makes so all other logic in Untangle stops from working.

Ex Rules with Group membership, Rules with Username Specified.

This is for me a huge issue and I don't understand how Untangle them self in my earlier threads and talks have jet started to act on this.

Please take your time and go and vote :-)

https://untanglengfirewall.featureupvote.com/suggestions/266888/untangle-need-to-able-to-work-with-both-samaccountname-and-userprincipalname

[dashpuppy]

I do believe that there are more then my clients that use Oauth/Office365 and with the current setup there are multiple ways the users userPrincipalName can enter the Username field in Untangle instead of the sAMAccountName.

This makes so all other logic in Untangle stops from working.

Ex Rules with Group membership, Rules with Username Specified.

This is for me a huge issue and I don't understand how Untangle them self in my earlier threads and talks have jet started to act on this.

Please take your time and go and vote :-)

https://untanglengfirewall.featureup...rprincipalname

Id rather see proper 2FA ASAP than anything ATM..

[sky-knight]

These are both critical features for the target market of Untangle. Both are needed if Untangle is going to maintain its place in anything resembling an enterprise environment.

[WebFooL]

dashpuppy,

I/we set MFA policy in Office365 so Untangle Captive Portal demands MFA for that Oauth type.
But all sessions get the "wrong" Username as the Claim form Microsoft don't by default include samAccountName.

I see more and more clients that are all cloud but still has local office with some hybrid setup.

So we can have legacy rules with samAccountName and group lookup but more modern clients its just going down hill and I can't even make it work with the current toolbox from Untangle.

[sky-knight]

Webfool, the Goofy part is, modern domains can use EITHER. SO there's really no reason to continue being married to samAccountName, because platforms that can only resolve it are too old to be secure anyway.

Add the UPN to the domain, and assign it to your users in prep for being a hybrid. This is standard practice now.

But Untangle themselves are insanely married to GSuite for their email, so I don't expect they'll understand all of this. They themselves are missing out on the massive internal communications and automation advantages of M365 over anything with Google's name on it.

But schools are like this a ton... often using both platforms for different segments of their populations. It's bonkers to me, because it's a ton of extra work for nothing but headaches.

[WebFooL]

sky-knight, Agreed they can use EITHER but untangle as we both see are stuck in the pre 2000 setup.

But I see daily users authentication to IPsec/Captiveportal etc that has logged in with [email protected] and it works..
Except none of he Policy rules for there group membership works..

For me it is a few quick fixes and that logic should work and we all should be happy but instead we get a WAF.

Looks more and more that we are going to push for Palo Alto as there Group Membership component works as we need it to do.

[sky-knight]

sky-knight, Agreed they can use EITHER but untangle as we both see are stuck in the pre 2000 setup.

But I see daily users authentication to IPsec/Captiveportal etc that has logged in with [email protected] and it works..
Except none of he Policy rules for there group membership works..

For me it is a few quick fixes and that logic should work and we all should be happy but instead we get a WAF.

Looks more and more that we are going to push for Palo Alto as there Group Membership component works as we need it to do.

Jim and I are working on this... sort of. We're putting together the documentation of how to integrate Untangle with Network Policy Server, which functions as a RADIOUS terminator. Using that enables MFA via Azure AD, Radius OKs the login event itself, so the entire AD integration process Untangle uses is subverted into a simple RADIUS call.

Then the usernames say "local" and don't get mixed up. More importantly, the firewall is more easily exchanged with another system that uses the same standards based authentication mechanism.

We've still got some homework to do though, so I can't really comment on this further.

[dashpuppy]

dashpuppy,

I/we set MFA policy in Office365 so Untangle Captive Portal demands MFA for that Oauth type.
But all sessions get the "wrong" Username as the Claim form Microsoft don't by default include samAccountName.

I see more and more clients that are all cloud but still has local office with some hybrid setup.

So we can have legacy rules with samAccountName and group lookup but more modern clients its just going down hill and I can't even make it work with the current toolbox from Untangle.

I was more tlaking about the Command center Portal getting a proper 2FA, ditch this email 2fa thing..

[donhwyo]

https://untanglengfirewall.featureup...rprincipalname
Suggestion not found
This suggestion is awaiting moderation.

[donhwyo]

Tried to vote for it again. Somebody must be on vacation. Sill waiting for moderation. Maybe next year?