BOXI 3.0 SSO Stops Working for clients attempting to log in through VPN

[Former Member]

Our SSO is working nicely inside the network, but it fails when I try it through the VPN. Has anyone come up with a solution for this?

[Former Member · Accepted solution]

This is a vanilla install of boxi 3.0. We are using Windows AD through vintela on tomcat with the default port of 8080. Again it works fine when we are in the network, but doesnt when we are trying to login from the cisco vpn. At the moment I am only trying to get Infoview to work.

Thanks

Edited by: Mark White on Sep 14, 2008 8:52 AM

[BasicTek · Accepted solution]

I just tested 2 types of SSO (vintela and IIS .net) both good on XIR2 (I'm currently using Cisco VPN). There are no known vintela issues on 3.0 that would prevent this.

So I VPN into work from my vista laptop using cisco client 5.0. Then open an internal infoview link using IIS integrated auth or vintela java. It SSO's every time.

I'd guess the problem could be with the VPN configuration itself or maybe even the client configuration. Can you try Microsoft VPN to isolate the issue?

Regards,

Tim

[Former Member · Accepted solution]

Tim,

I will work with my clients admins to try to get a picture of how vpn is setup and then we can continue the conversation.

[BasicTek · Accepted solution]

Sure thing Mark,

Just a little more background.

Whether logged in to a desktop or VPN your microsoft credentials should be available to send through a browser but the workflow is important especially with many differing client configurations available.

In my case the workflow was this

connect via VPN

remote my desktop

click on various SSO links,

all worked.

Now another possible workflow that could produce different results

connect via vpn

try to launch URL locally (without remoting a desktop)

this could be an issue depending on the client rules of routing network traffic. Generally it's desired NOT to route remote traffic through the VPN but if enabled then even this should work

Also is the URL different for VPN users than internal?

Does the URL have any periods in it? If so then the site may need to be added to the client local intranet sites.

Let us know...

Regards,

Tim

[Former Member · Accepted solution]

Tim,

My workflow was simply using the same url in my laptop browser from the office and remotely through VPN. When I did a remote desktop to one of the servers it worked fine. The failure seems to occur when I try to do it remotely from my normal browser.

I looked at the vpn config file and it appears it is setup to use a group authentication and UDP for IPSEC The other option is TCP for IPSEC. Could this be the issue?

[BasicTek · Accepted solution]

Ok I just reproduced. The level of troubleshooting at this point I think exceeds the scope of these forums. Can you open a message with support and direct you engineer to this post. They should be able to reach me if they have any questions. This may need to be escalated, I'm not sure what needs to be done to change this behavior.

I used to use Microsoft VPN and that workflow worked fine. Just FYI.

-Tim

[BasicTek · Accepted solution]

oh I missed that. Kerberos does need TCP, can you try that and let me know

[Former Member · Accepted solution]

I am unable to turn on the TCP probably due to the security settings of the organization. Do you know what the official non-sso url should be for Infoview 3.0? I need an alternative if we cannot get the vpn issue resolved.

Thanks

[BasicTek · Accepted solution]

yep it's InfoViewApp/logonNoSso.jsp

I did escalate a bug on this and it sometimes gives an error instead of the logon screen(depending on certain factors). The bug was set to be fixed in SP1 (hopefully coming in a couple weeks).

Let me know if it works.

I'll try to play around with my VPN settings and see if I can figure this out too.

-Tim

[BasicTek · Accepted solution]

Did a little more testing. The problem is with kerberos. Using NTLM I was able to SSO from my laptop (without a remote connection).

Packet scanning the vintela attempt I can see that instead of doing SPNEGO NTLM was used on the client. Vintela cannot login with NTLM. Setting up a trusted auth IIS server may be the easiest resolution. This would put NTLM in the front and could be configured to use the existing mapped AD users to login.

I too couldn't connect via TCP (it would likely require a change in my companies VPN) and I can't do that. I'd be curious to see if that would have worked?

-Tim

[Former Member · Accepted solution]

Could this work? http://support.microsoft.com/kb/244474

[BasicTek · Accepted solution]

We use that KB regularly when deploying vintela.

How it generally works is like this

we run a service that will be making kerberos requests with the AD service account (CMS)

running a packet scan prior to that KB will show UDP failures and TCP retries/success

make that registry change on that server

packet scan again and no more UDP failures

In this case I think the VPN client is preventing the type of communication that we need (based on my packet scan) I don't think this will work but your welcome to try the KB is pretty much harmless and easy to undo.

Also found a thread on the vintela forums about this

http://vintela.inside.quest.com/post!reply.jspa?messageID=22061

Regards,

Tim

[Former Member · Accepted solution]

I think you stumped the Vintela folks. I no response on their site

[BasicTek · Accepted solution]

Do you have access to our SMP portal? Note 1231879, Apparently you may be able to resolve this by forcing TCP but it will have to be done on tomcat or other JAS (for SSO). The registry key won't force it.

-Tim

[Former Member · Accepted solution]

Yes I do have access. I already had the settings for the max packet size, but I will try the krb5 file modification. Thanks! I will try this amd let you know.

[BasicTek · Accepted solution]

not likely to be resolved with UDP pref.

That is for manual logons

the one vintela uses is -Djcsi.kerberos.maxpacketsize=0

[Former Member · Accepted solution]

This didnt work either. Anyother thoughts? Thanks

[BasicTek · Accepted solution]

Yep, According to the vintela forums you must be a member of a domain to do SSO, which makes sense since the client workstation must negotiate credentials with a DC (on the other side of your firewall) during the process NTLM or SPNEGO/kerberos.

So, when you VPNed in, and remote an internal computer, you are now attempting SSO from a domain computer and it works. When you take the link and try to run it on your VPNed computer, you are not a member of the internal network so the process never really gets started.

You can try faking it out by adding cached credentials to your external workstation, but this isn't SSO and will break every time your password expires.

From XP control panel/user accounts/advanced/manage passwords but that is not really SSO. On my VPN'd computer I could only get that working for NTLM.

from vista control panel/user accounts/manage network passwords. So no guarentee this will work but it's worth a quick try

Regards,

Tim

[Former Member · Accepted solution]

Tim,

Your last post got me thinking. I found a setting in the Cisco VPN client under Options-->Windows Log On properties and selected "Enable start before log on". This allows you to run the vpn to establish the connection before logging into the computer. It works like a champ! Our machines are on the network, so I do not know if it will work in your case, but we are good to go. Thanks for all your help!

Mark

[BasicTek · Accepted solution]

Thanks for the update Mark,

In my case my machine was at home (not part of the network).

It's good to know it will work with the above options.

Regards,

Tim

[BasicTek]

Hi Mark,

There are many instances where users can SSO through a VPN. We need more details to provide an answer to your question.

1) Type of SSO (vintela, IIS integrated auth, siteminder, or 3rd party trusted authentication)?

2) application you are attempting to do SSO with (infoview, deski, other)?

It may also help to get the current allowed port number(s) (80, 8080, 6400)?

Regards,

Tim