Sign in window appear on some portal pages including settings

[Suleyman-Arslan]

Hello,

I just finish fresh new installation of ArcGIS Ent. on Azure. I used "ArcGIS Ent. Cloud Builder 11.0 for Ms Azure" Version 11.0.35046

After successfull deployment I login to portal and get login screen when I open the setting page. I did not notice any  degredation or problem on portal.

Do you have any ideas to get rid of this issue?

I use below configuration options:

Deployment type: Multi Machine Multi Tier

From Esri Image:- Yes
Image Name:- ArcGIS Enterprise 11.0
Total Machines:- 5
Machine Names:- saFileShare, saServer-0, saPortal-Pri, saDataStr-Pri, saJumpox
Enable OS Updates:- No
Remote Desktop:- Yes (Port 0)
ARM Resource Prefix:- sa
Preserve artifacts:- Yes
Use Cloud Storage:- Yes
Cloud Storage Option:- Azure Files (SMB)
Uses Azure Monitor Logs Workspace:- Yes
Capture Server Logs:- Yes
Automatic VM Shutdown Enabled:- No

Portal Context:- portal
Server Context:- server
Site Administrator UserName:- siteadmin
ArcGIS Service Domain Account:- False
File Share Option:- On Single Machine
File Share Host:- saFileShare

Data Store Types:- Relational

SSL Option:- CA Issued Certificate

[Scott_Tansley]

The additional popup box is asking you to sign in to the application server using port :7443 rather than going through true HTTPS.  Can you log in to:

https://your.domain.com/portal/portaladmin/system/properties

and see if you have a webcontexturl set?  If not then I'd recommend implemeting it.  Essentially it forces all portal traffic to occur over the 443 address rather thatn 7443 address, which is a good thing.  Instructions are here:

https://enterprise.arcgis.com/en/portal/latest/administer/windows/using-a-reverse-proxy-server-with-...

You need to be appending a JSON snippet along the lines of:

{ "WebContextURL": "https://your.domain.com /portal" }

In essence, most of your web requests appear to be going via 443, but occasionally it's swapping to 7443, and the above configuration should stop that from happening.

[Suleyman-Arslan]

Hello @Scott_Tansley ,

Thank you for your answer.

webcontexturl and privateportalurl already set by cloud builder setup as below.

{"WebContextURL":"https://your.domain.com/portal","privatePortalURL":"https://your.domain.com/portal"}

I did try another setup with same configuration to ensure that there is no error on Cloud builder deployment, unfortunately get exactly the same problem on second deployment.

Suleyman.

I am planning to go with manual setup if I can not solve this issue.

[Scott_Tansley]

There must be something deeper in the APIs, possibly the sharing API.  I build manually for all my clients.  I have clients on AWS, Azure, IaaS and hardware.  They're all built and configured manually and to the same standard, it makes support much easier.  When there's different builders and different versions of builders it's hard to say where the issue is.  

Sorry, I'm genuinely not sure on this one. 

[Suleyman-Arslan]

@Scott_Tansley ,

Usually I do the same but this time I was trying to save time. I was expecting cloud builder will do everything in standardized way.

Any how, thank you for your time.

Suleyman.

[Scott_Tansley]

I hear you.  I experimented with the cloud builders back at 10.5.1/10.6.1 and found I spent more time setting things up to 'my standard' than it would have taken to build manually.  

My pleasure, and I'm sorry I couldn't find a solution for you.