Deploy Portal with several DNS entries

378
9
03-02-2022 02:26 AM
PhilippeVDV
New Contributor III

Hi folks

I'm wondering whether it's possible to deploy Portal for ArcGIS with several DNS entries?

The customer always had a standalone ArcGIS Server that had several DNS entries, so the ArcGIS REST directory was accessible over different URLs:

https://DNS1/arcgis/rest/services

https://DNS2/arcgis/rest/services

https://DNS3/arcgis/rest/services

I installed now a Portal and federated ArcGIS Server with https://DNS1/arcgis as the services URL. I set https://DNS1/portal as the webcontexturl.

Portal seems accessible over the 3 DNS entries:

https://DNS1/portal

https://DNS2/portal

https://DNS3/portal

 

(when logging in in https://DNS2/portalhttps://DNS3/portal in the item details I see https://DNS1/arcgis/rest/services/xxxx/MapServer which makes sense as the federation was based on DNS1; I can live with that)

 

However, 2 things don't work:

When trying to login on ArcGIS Server Manager or to login on the REST directory, when using the DNS2 or DNS3 URLs nothing happens. I see a token error in the DEV tools of the browser. One of the URLs that is constructed is the following one: 

https://DNS1/portal/sharing/generateToken?request=getToken&serverUrl=https://DNS2/arcgis/login/../re...

When manually editing the URL above and substituting DNS1 by DNS2, a token can be generated.

My question: how can I get ArcGIS Server manager + the REST directory working over the DNS2 and DNS3 entries? Now it only works when using DNS1. Is it even possible? The fact that I can manually correct the URL that gets the token from Portal, gives me hope that there should be some way to fix this 🙂 

Anyone some ideas?

Thanks in advance!

Phil

 

 

 

0 Kudos
9 Replies
BillFox
MVP Frequent Contributor

I think once you do multiple you have to use the web adaptor path

try adding the alias dns ip to each machine's nic

0 Kudos
Scott_Tansley
Regular Contributor

This topic here states that portal only supports a single dns.

A lot of the security trust functions use that so if customer2 tries to do something secure then it could fail.

additionally it’s going to make your content messy due to the way urls are stored in items.

have you considered a generic url and then use sites?

I can guarantee it will get messy quickly if you carry on with your proposal and you’ll be unsupported.

Scott Tansley
Consulting Architect (ArcGIS Enterprise)
https://www.linkedin.com/in/scotttansley/
0 Kudos
BillFox
MVP Frequent Contributor

I'm thinking HA

jump to the section clip below about DNS alias

similar for privateportalurl

https://enterprise.arcgis.com/en/web-adaptor/latest/install/java-windows/using-a-reverse-proxy-serve...

Set the WebContextURL property

The portal's WebContextURL property helps it construct the correct URLs on all resources it sends to the end user. Do the following to change the WebContextURL:

Open a web browser and sign in to the ArcGIS Portal Directory as a member of the default Administrator role in your portal organization. The URL is formatted https://portal.domain.com:7443/arcgis/portaladmin.
Click System > Properties > Update Properties.
On the Update System Properties dialog box, insert the following JSON, substituting your own reverse proxy server or DNS alias URL as seen by users outside your organization's firewall.

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

Note:

Portal for ArcGIS only supports a single DNS.
Note:

You cannot use a nonstandard port (that is, a port other than 443) when setting the WebContextURL property.

 

0 Kudos
Scott_Tansley
Regular Contributor

HA always has the same single reference URL.  If you’re using SAML2, then you can only connect to one IDP.  When you configure the trust you can only do that with one URL.  So how do the other urls authentic using SAML2.

yea the webcontexturl is used to construct some of the content.  But if you open up the JSON/XML configuration of items in the portal content store then the URLs are hard coded in there.

I’ve tried changing one url to another in the past because a customer screwed up their build.  It proved quicker to start again. Ans that was before federation!.  The thought of multiple URLs fills me with dread.  

There are too many deep things where URLs get generated and messages going between federated components to even consider this.

Scott Tansley
Consulting Architect (ArcGIS Enterprise)
https://www.linkedin.com/in/scotttansley/
0 Kudos
PhilippeVDV
New Contributor III

Hi,

Thanks for your reply. As far as I know, you can only configure just 1 WebContextURL, so this is not the solution I'm afraid

 

Best regards

Phil

0 Kudos
Scott_Tansley
Regular Contributor

The possible supported solutions are:

   Three Enterprise Portals

    One enterprise portal and three sites

   One portal and three seperate front pages on different URLs that consume from the one portal.  Along the lines of:  https://www.eagle.co.nz/gis-solutions/industry-solutions/localmaps

 

Scott Tansley
Consulting Architect (ArcGIS Enterprise)
https://www.linkedin.com/in/scotttansley/
0 Kudos
PhilippeVDV
New Contributor III

Hi Scott,

 

Thanks for your reply. 

3 ArcGIS Enterprise deployments would be a bit of an overkill 🙂

I'm going to investigate your Enterprise sites proposal, but not sure if this will fix the authentication issue in which I'm running in. I want to be able to access secured REST services over different DNS aliases and this implies that Portal should generate a token (which only works for a single DNS now). I don't see how Enterprise sites could be the workaround, but I'll investigate!

 

Best regards

Phil

 

0 Kudos
Scott_Tansley
Regular Contributor

I hear you.  If you’re using saml2 for authentication then you could look at federating multiple IDPs and having ArcGIS authenticate against that or possibly consider OpenID to support it?  I haven’t tried the latter.  

The only way I see of getting three URLs to sort of work would be to use the portal anonymously.  

Sorry, I’ve pushed and pulled  the Enterprise Portal in different directions since 10.3.1, mainly to support different client whims.  My findings are that if you work within the supported instructions then it works incredibly well, but deviate from the supported path and expect pain.  

Scott Tansley
Consulting Architect (ArcGIS Enterprise)
https://www.linkedin.com/in/scotttansley/
0 Kudos
PhilippeVDV
New Contributor III

@JonathanQuinn , do you have any thoughts on this?

0 Kudos