Garacesh Posted November 17, 2023 Posted November 17, 2023 Trying to debug this one and it's driving me bonkers. Staff are trying to login to iam.pearson.com and it's consistently crashing when they try to login. It doesn't happen on an unmanaged device, so it's clearly something to do with the settings we're pushing to Windows or browsers. It doesn't happen for admin accounts, or accounts outside of the typical scope, so that infers it's something to do with user settings/policies. But now I'm hitting a roadblock. How do I drill into this more? It happens in Chrome, Edge and FireFox. The browser will hang for ages, before Chrome and Edge complain and give you the option to terminate. chrome://crashes and edge://crashes don't give me any useful information. Annoyingly, Firefox seems to handle this issue better and eventually recovers, so nothing at all in about:crashes. Nothing in event logs. Kinda stuck now.
Rundc Posted November 17, 2023 Posted November 17, 2023 I was having a similar issue recently with pearson, our issue was related to filtering, whitelisted the site and all has been good since!
Linfit Posted November 17, 2023 Posted November 17, 2023 (edited) We had the same issue with it timing out with very similar symptoms. It was our firewall/filter which needed tweaking: https://edexcelonline.pearson.com https://userportal.pqs.pearsonprd.tech/ https://iam.pearson.com All needed whitelisting. I think we were missing the second one. I recall there was also an issue where the link sent to exams officers to the login page was wrong and an issue where if they had logged into the Edexcelonline site in the same session it tried to get back into there rather than the new page on the iam pearson domain. Fixed by clearing cache. Doesn't help with the many other issues with the Pearson sites and the authentication process. Their online presence is truly dreadful. Edited November 17, 2023 by Linfit 1
6Foot2 Posted November 17, 2023 Posted November 17, 2023 ... It doesn't happen on an unmanaged device, so it's clearly something to do with the settings we're pushing to Windows or browsers ... Does it happen on all devices? (all AD OUs) Can you narrow it by finding an OU, or OUs where it doesn't happen? What about Windows event logs? Is there anything helpful in there?
dapaulio Posted November 18, 2023 Posted November 18, 2023 We too had similar issues. Create an updated whitelist as suggested above. As per linfit post.
sigma Posted November 18, 2023 Posted November 18, 2023 Pull off a Netsweeper report for a timed test from 2 mins before to 2 mins after, just the person or policy group, find the entry where they access the site and see what follows as denied. Sorry if this akin to sucking eggs.
altecsole Posted November 19, 2023 Posted November 19, 2023 We had a similar issue. It tuned out that the Pearson sign-in uses port 8443, rather than standard 443. This seems to be used by Tom Cat servers. We had to add a rule on our Firewall to allow this.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now