Luminis Banner Channels prompting for User ID and PIN
We have had a few users who are prompted for their User ID and Pin when they try to access the Banner Channels within Luminis. Some of them are on Military bases and some of them are not, I have seen where access from military bases is sketchy.
Has anyone encountered this issue recently and is there a fix for this. We opened a ticket with Sungard and since we were not able to consistenly reproduce this issue we could not proceed. This is frustrating for our users and we not able to nail the problem down, any suggestions would be welcome. Thanks
Satellite ISP
This is indeed a known issue and happens for direct SSB sso links as well. This happens on two occasions:
1. User has a colon (":") in their Luminis password
2. User is using a Satellite ISP.
Since you mentioned users in military bases having this issue, I can virtually guarantee that you are seeing the same issue as military bases tend to use a satellite ISP. We discovered this in March 2009 and reported it to Sungard and its been almost a year and no solution yet from them. From what we found during our testing that two cookies (BANSSO and CPSESSID) do not get set during an sso connection to banner channels or directly to SSB. Interestingly, manually setting these cookies using a cookie editor makes it work. So, we are currently trying to modify the sso package in banner to force the setting of the cookie as we haven't been able to determine why using a satellite ISP causes these cookies to not be set.
In the interim we have told our users to use either a VPN connection or Remote Desktop connection (if possible) when they get this error.
Refer:
http://www.lumdev.net/node/3109
http://www.lumdev.net/node/2195
pickup.html
We have developed our own GCF connector to allow SSO to Banner Webfor using our user's Active Directory credentials. (These are the same as the ones used to log in to Luminis.)
At the moment we are on Banner 7, but are going to be moving to Banner 8 soon ... (in which case things may need to change before it will work properly)
So the GCF <authenticate> has two steps
<GET> to make sure that the Banner TEST cookie is in place
<POST> credentials to the correct form location
Then a pickup.html makes sure that the cookies associated with the session get into the browser.
Would this mechanism work for a Satelite ISP?
Derek
University of Leeds, UK
One of my programmers found
One of my programmers found this for specific ISP but we don't have a way to test it so YMMV; if you have any feedback or someone can test it, that would be helpful and appreciated.
1. Ask if student is accessing Luminis using a satellite ISP if so:
a. If using HughesNet :
Go into IE, to internet options and to connections tab. Click LAN settings and choose to use a proxy server by putting a check in that box. Then click the advanced button and enter in the following for HTTP and Secure fields: 69.19.14.10.
And for the port, put 3128 in the ports for HTTP and Secure fields for port.
This will slow their connection down noticeably but they will be able to get in to the system
b. We do not have a fix for Wild Blue
using proxy for https?
Interesting to learn that there is a workaround, at least for one of the satellite providers.
But if a student puts the Hughes proxy server 69.19.14.10 for both HTTP and Secure, that means that the SSL-protected portal/SSB pages aren't protected anymore, at least from the proxy server administrator.
This has been very helpful, I
This has been very helpful, I will try some of the suggesstions and update what comes of them. Thanks again
Same issue
We are experiencing the same issue at our university with WildBlue and HughesNet. We have had some success with the HughesNet workaround mentioned above but WildBlue users are still out of luck...it would be nice if SunGard came up with a fix for this!
Nathan
Longwood University
Farmville, VA