AnsweredAssumed Answered

Moving the Web Adaptor from an internal network machine to a DMZ machine

Question asked by shawnm.miller on Mar 13, 2018
Latest reply on Mar 20, 2018 by shawnm.miller

Like • Show 1 Like1
Comment • 10

I am looking for some gotchas and advice you all have when moving an ArcGIS Server and Portal for ArcGIS to a new Web Adaptor machine, in a DMZ network, to provide authenticated public access to the internal resources. Below is my plan of action from a high level, what am I missing?

When doing this I am planning on unregistering the internal network machine's Web Adaptor from an ArcGIS Server and Portal for ArcGIS. The ArcGIS Server site is federated with Portal via this internal network machine's Web Adaptor. I am planning on leaving that alone right now (should I unfederate?). Then I was planning on registering the new DMZ network machine with the ArcGIS Server and Portal for ArcGIS. The new DMZ network machine does have a new name, so it will not be the same as the old. The Web Adaptor also already provides Integrated Windows Authentication (IWA) to the Portal for ArcGIS.

I am guessing once this is done all the web maps (configs, popups, etc.), services, AGOL items, apps, 3rd party apps that use these things outside of Esri products, etc. will all need to be re-published, re-created, or at least re-configured for the new Web Adaptor name, is that correct?

No one else has this question

Outcomes

10 Replies

Chad_Kopplin Mar 13, 2018 10:05 PM
Mark Correct
Correct Answer
Everything you mentioned is right, and you can make the DMZ version use secure web services if need be. That is what we did with our system, you do not need to unfederate the internal web server and portal. You are correct you will have to republish the services and reconfigure your 3rd party applications etc. Chad
Like • Show 0 Likes0
Actions
JQuinn-esristaff Mar 14, 2018 9:57 AM
Mark Correct
Correct Answer
Unfederating and refederating is really the only way to update URLs that are stored in a few config-files, but that introduces a lot of cleanup. When you refederate, all existing services will be re-added as items in the Portal and all hosted services will lose a tag that indicates they're hosted. You'll need to identify which services are pointing to the right items, (check the portalProperties section of the service within the Admin API for the item ID and validate that against the item IDs in the portal). Hosted services will need to be republished.

All of the service items will have new itemIDs and new URLs, so all webmaps will have to be updated with the new URLs. Popups won't need to be updated, you'll just need to use something like the Python API to loop through all items and update the URLs.

When you say "authenticated public access", you're referring to users who have an account within your AD, correct? You can use SAML to authenticate users using either a SAML account, (for users who have an account within your AD), or a built-in account, (for users who don't have an account).
Like • Show 0 Likes0
Actions
shawnm.miller Mar 14, 2018 10:18 AM
Mark Correct
Correct Answer
Thank you Chad Kopplin!

Hi Jonathan Quinn, thank you for your reply. I had forgot about the re-adding of all existing items again once the federation where to be setup again. Do you think undefederating the Server site with Portal is required in this instance or will the moving of the Web Adaptor be enough for this change? I was actually thinking the DMZ located machine hosting Web Adaptor (in IIS) would continue doing Windows Authentication (IWA) as it is today internally by just talking to the local domain controllers (this is the admin endpoint user store configuration with a domain username and password). Is that possible in your experience without having to setup federation to provide SAML accounts? Or must a federation provider like AD FS need to be setup to do what I am describing? Currently there is no built-in identities being used.
Like • Show 0 Likes0
Actions
- JQuinn-esristaff @ shawnm.miller on Mar 14, 2018 3:37 PM
  Mark Correct
  Correct Answer
  Moving the web adaptor won't be enough, unfortunately. We're working on support for updating the front-end URLs in future releases.
  
  If all users who will reach the web adaptor have accounts within your AD, then yes, that should be OK. Typically, though, when you start working towards public access of resources, that typically means either members of the public, (unauthenticated, anonymous users), can reach the endpoints or authenticated users that aren't part of your AD can reach secure endpoints. If it's the latter, they'd need an account such as a built-in account to get in. IWA portals don't support built-in account as well as IWA accounts, but portals configured with SAML/ADFS do.
  
  You may also have employees needing public access of your resources, in which case, there shouldn't be a problem.
  
  Is that possible in your experience without having to setup federation to provide SAML accounts?
     We use the term "federation" to mean federating portal and server, and server will then use portal's security store. I assume you mean set up Portal to use ADFS/SAML, so here might be a better way to break it down:
  
  Scenario 1:
     Anyone reaching the Portal will have accounts within your AD. This means IWA will continue to work for you.
  
  Scenario 2:
     Public, anonymous people may need to reach apps or webmaps within the Portal, but you still want users within your AD to have the option of signing in with they enteprise accounts. You can use SAML to achieve this.
  1 person found this helpful
  Like • Show 0 Likes0
  Actions
shawnm.miller Mar 15, 2018 11:20 AM
Mark Correct
Correct Answer
Thanks again Jonathan Quinn, makes sense on the authentication and sorry yep I meant federation in the identity sense not the Portal sense, great clarification there. I just want to confirm authentication aside for a moment (so the next few sentences are with the Portal version of the word federated). You are saying here that if I unregister the old Web Adaptor and then register the new Web Adaptor, that is not enough. What I mean by not enough is I will also have to unfederate the Server site from Portal to complete this process. And that is because when the Server site and Portal are federated that federation leverages the Web Adaptor for the ArcGIS Services and potentially the Administrative endpoint as well. Is that accurate? If that is, what is the best order of operations to do that in granted I am able to deal with all the pain that removal of the federation will cause me. Is it? Unfederate Server with Portal, unregister Web Adaptor for Server, unregister Web Adaptor for Portal, register Web Adaptor for Portal, register Web Adaptor for Server, and finally federate the Server site with Portal.
1 person found this helpful
Like • Show 1 Like1
Actions
- JQuinn-esristaff @ shawnm.miller on Mar 15, 2018 2:20 PM
  Mark Correct
  Correct Answer
  Yes, since we don't currently support updating the URLs in your deployment, you'll need to go through what you proposed:
  
  1) Unfederate Portal and Server
  2) Unregister the web adaptor from portal and the web adaptor from Server
  3) Reinstall both web adaptors on the new machine and configure them with the appropriate component
  4) Re-federate
  
  The tough part now is that you have a bunch of duplicate items within the Portal. At this point, you'll need to compare the item ID that the service is storing through the Admin API with the item ID's in your My Content page and delete the item that is a duplicate.
  1 person found this helpful
  Like • Show 0 Likes0
  Actions
  - rastrauch @ JQuinn-esristaff on Mar 15, 2018 2:43 PM
    Mark Correct
    Correct Answer
    The tough part now is that you have a bunch of duplicate items within the Portal. At this point, you'll need to compare the item ID that the service is storing through the Admin API with the item ID's in your My Content page and delete the item that is a duplicate.
    Jon,
    I actually haven't seen a federated Portal and Server yet, but I know that Portal controls the security. ( I probably should go look at some videos that show this.)
    Q1: when federated, do you still have service in Server and can they be in folders?
    Q2: are services in Portal separate from these? Or, are the item numbers you mention actually pointing to the Server services.
    
    The reason I ask is, if you unfederate...
    Q3: what causes the item ID duplication?
    Q4: will your Server services still be there and possibly in folders, or do they all need to be recreated?
    
    Since I am getting questions about federating our setup, which I am discouraging at this time due to being in the middle of our upgrade. But, I'm trying to gather information like Shawn Miller is asking in this thread, so I hopefully give an unbiased and informative opinion once things settle down. Everything seems to be pushing the federation, but there are still good reasons not to do it. So, knowing what might be lost if we push the federation and then decide it isn't working will be valuable.
    Like • Show 0 Likes0
    Actions
    - JQuinn-esristaff @ rastrauch on Mar 15, 2018 3:34 PM
      Mark Correct
      Correct Answer
      Q1: when federated, do you still have service in Server and can they be in folders?
            Yes, once you federate, all services will still exist on the server in their original folders, they're just automatically added as items to the portal. You'll need to move them into folders yourself within your My Content if you want similar structure, but where they exist in Portal doesn't affect how they're stored in Server, (security, of course is affected, as the security store will change).
      
      Q2: are services in Portal separate from these? Or, are the item numbers you mention actually pointing to the Server services.
         Portal is always storing references or pointers to services. You can publish directly to Portal, (creating a hosted service), or you can publish to Server directly, (traditional map service). In either case, a service is still spun up on the Server for you and an associated item is created within the Portal. The item numbers, or item IDs associate the item in Portal to the service in Server to establish the link for security/sharing.
      
      Q3: what causes the item ID duplication?
           Simply the act of federation adds all services in the Server as items to the Portal, regardless if the item already exists or not. We've had some discussions on how to handle this, but nothing in place yet.
      
      Q4: will your Server services still be there and possibly in folders, or do they all need to be recreated?
         Once you unfederate, the security for services will be controlled by the Server again. I believe your original security store, (the same users, roles, etc), will be available but I haven't tested that. You may have to secure your services again, though. The services will continue to exist, you won't need to recreate any.
      1 person found this helpful
      Like • Show 0 Likes0
      Actions
      - rastrauch @ JQuinn-esristaff on Mar 15, 2018 3:44 PM
        Mark Correct
        Correct Answer
        Thanks Jon. That actually makes me feel much more comfortable with trying the federation since it can be undone without loss of the Server services. I still have other reservations about it, similar to Shawn's since we do also share secure services through web pages and web apps. So, I will continue to watch this thread, that will be something that will need to be tested on our end.
        
        Shawn, hopefully these questions help for you too. I wasn't trying to hijack your thread, but think they are inline with your questions.
        Like • Show 0 Likes0
        Actions
        shawnm.miller @ rastrauch on Mar 20, 2018 10:09 AM
        Mark Correct
        Correct Answer
        Rebecca Strauch, GISP, no problem on the hijacking. A federation for Portal has been very useful so I would recommend moving that way for sure. I think what I have learned here is that it is important to user a DNS alias (CNAME record) to augment your machine name when leveraging the Esri Web Adaptor. More importantly, if you are ever going to externalize (or make public) your GIS services or Portal, secured or not, you should really think about putting your Esri Web Adaptor in the location that makes sense from the get go for that to occur, so for some that is the DMZ. We have opted to build out a new Server and Portal to attach to the DMZ based Web Adaptor to limit production downtime during this change and avoid the unfederating activity all together here.
        
        Thanks again Jonathan Quinn!
        1 person found this helpful
        Like • Show 0 Likes0
        Actions

GeoNet

The Esri Community

Moving the Web Adaptor from an internal network machine to a DMZ machine

Outcomes

Related Content

Recommended Content