Hello all
I'm dealing with an issue brought about by upgrading our portal from 11.1 to 11.3: We can no login to the portal via SAML Entra.
The portal is sending an IP address:
https://<IP ADDRESS>/portal/sharing/rest/oauth2/saml/signin
Instead of a FQDN as it was prior to the upgrade
https://<FQDN>/portal/sharing/rest/oauth2/saml/signin
I've checked the usual suspects: Web Adaptor, IIS settings and binding, etc. It is entirely possible I've missed something there, it is not a playground a spend a lot of time in.
https://<IP ADDRESS>/portal/sharing/rest/portals/0123456789ABCDEF/sp/metadata?....
It seems like that should be the FQDN, but I can't edit that field.
Thanks in advance for any suggestions,
Chris
Solved! Go to Solution.
So we did get the situation resolved. The portal web adaptor was misconfigured with IP address instead of the FQDN (I swear we checked that half a dozen times).
Another amusing (to me) issue cropped up due to this misconfigured adaptor (probably? don't know what else could have caused it) where some of our web apps had their portalUrl changed to point the IP address instead of the FQDN which caused a lot of frowny faces until we dug in and fixed it with ArcGIS Assistant.
Shout out to ESRI's Scott Moore for his help.
Hi @DORPAD,
you can check if this file is present C:\Program Files\ArcGIS\Portal\framework\etc\hostname.properties if it is rename it to .old and give portal a restart.
The other possible culprit can be host file entries C:\Windows\System32\drivers\etc\hosts if something like IP IP is in the file.
And the 3rd thing that I would check is for a webcontexturl under https://dns.com/portal/portaladmin/system/properties
Hope it helps
Regards
Henry
Thanks for the replay Henry
There is no hostname.properties present
Nothing suspicious in C:\Windows\System32\drivers\etc\hosts
No webcontexturl in portaladmin/system/properties
This a pretty simple portal install, nothing like a reverse proxy server, multiple web adaptors, etc that could be a potential issue.
So we did get the situation resolved. The portal web adaptor was misconfigured with IP address instead of the FQDN (I swear we checked that half a dozen times).
Another amusing (to me) issue cropped up due to this misconfigured adaptor (probably? don't know what else could have caused it) where some of our web apps had their portalUrl changed to point the IP address instead of the FQDN which caused a lot of frowny faces until we dug in and fixed it with ArcGIS Assistant.
Shout out to ESRI's Scott Moore for his help.