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

UTM 9.2 Web Authentication

MentalMickey
Sadly it looks like the UTM is going to cause me some extra work. I know it's down to the way we have it setup on our network, but it's a bit of a frustration that means we can't use browser based authentication.

Our UTM is setup as a perimeter device. It should have no direct connection to the internal LAN, not even for authentication. So authentication is done by LDAP proxy. This authentication works just fine. However, because all user traffic is NAT'ed through an internal firewall it appears that the UTM then decides that all traffic from that one IP address belongs to the first user who logs on using browser authentication [[:(]]

So it seems that browser auth only links logged on users to the IP address. I guess I was hoping it would have some session based cookie or the like.

If I temporarily allow the UTM to talk with our AD servers and use AD SSO then the NTLM authentication works as expected and traffic is associated to the authenticated user. I'm guessing because NTLM has the authentication details in a packet that gets sent to through the internal firewall and to the UTM.

Next step is to install a Read Only Domain Controller (RODC) so that the UTM can authenticate with that using NTLM rather than LDAP. Which is sad because it means I can't use a browser unless it's NTLM capable and we all know what that means [[:(]]

Anyone got any thoughts on this?


This thread was automatically locked due to age.
Parents
  • 0
    Thanks for the response. We are in fact using Standard Mode AD-SSO because of this issue.

    That's interesting about Kerberos. I'll test it out in our wpad settings to make sure that's correct and still works. I know we currently use an IP Address in there.

    The reason we NAT is because the UTM must hot have any visibility or understanding of the internal LAN.

    We are required to have a Service Mediation Zone separating the Untrusted/Public network from the LAN. Previously we used a single device that could access LAN, SMZ and Internet. But our security requirement now means we must have a distinct separation from Untrusted and LAN. So if the UTM suffers a breach the LAN is still defended.
Reply
  • 0
    Thanks for the response. We are in fact using Standard Mode AD-SSO because of this issue.

    That's interesting about Kerberos. I'll test it out in our wpad settings to make sure that's correct and still works. I know we currently use an IP Address in there.

    The reason we NAT is because the UTM must hot have any visibility or understanding of the internal LAN.

    We are required to have a Service Mediation Zone separating the Untrusted/Public network from the LAN. Previously we used a single device that could access LAN, SMZ and Internet. But our security requirement now means we must have a distinct separation from Untrusted and LAN. So if the UTM suffers a breach the LAN is still defended.
Children
No Data