Kerberos without LocalIP restriction

[maeday85]

Hello,

 

We've been running HAP for a while now and its been a great upgrade over other portals in previous years, so thank you to the team that made it. Were running single sign on with kerberos here and its all running fine, one of the feature points is that it checks the IP address of the client machine via the "InternalIPs" variable.

 

I was wondering if it was possible to bypass this feature or have it turned off? My issue is that in South Australia we have a government mandated administration network that has one directional traffic flow and its own separate auth domain. We create kerberos tickets on these admin machines from the domain HAP resides in, however HAP cannot talk back to the network segment these clients originate from (Im assuming this to be my problem). Essentially anyone on this IP range cannot perform single sign on to HAP, other items from our realm e.g exchange, IIS websties, sharepoint, sign on without issue on this network segment.

 

My understanding is that this is to prevent SSO for external hosting? We sit behind a reverse proxy/firewall that does AD auth and creates a kerberos ticket for the user as well. It would also be great for that identity to function as well, im assuiming the solution to be the same for both segments.

 

Would this perhaps be a configurable on/off feature request item? Any advice would be welcomed in making our users lives easier

[nickbro]

Hi @maeday85, unfortunately you won't be able to do what you suggest. As kerberos is a handshake between IIS and the client's browser, it will always authenticate with the local user credentials, or prompt for them. A reserve lookup is performed to get the client's IP to determine if it's an internal device (as specified by the ip range) so it can be authenticated against the local Active Directory (the one HAP+ is installed against)

[maeday85]

Hi Nick,

Thanks for replying. Is the reserve lookup a necessary component? I thought that may be the only part that is not working in the equation. Two directional handshakes do work, although we arent privy to the configuration I believe established traffic is bidirectional. As mentioned before exchange/owa will autosign in with the saved windows Identity.