Latest Contributions by NicolasGIS

Hello, Migrated to 11.3, I am facing an issue: ArcGIS Server keeps crashing after reboot. Running on Windows Server 2022 which each component of ArcGIS Enterprise installed on its own machine: 16 CPU and 60 Go RAM which seems to me like a good VM. After restarting the services, it crashes and the VM is freezed (required a reboot from cloud interface). In Windows event viewer the following is logged:   In ArcGIS Server logs, I have: <Msg time="2024-06-11T09:00:54,317" type="SEVERE" code="8003" source="Secu/Risks_Prod_Site.MapServer" process="9996" thread="33" methodName="" machine="GISSERVER.COMPANY.COM" user="" elapsed="0.0" requestID="">Failed to initialize server object 'Secu/Risks_Prod_Site': 0x80043007: </Msg>   for few services and then it stops suddenly requiring several reboots to make it back alive but then the issue occurs once again. The issue only occurs on federated server and not hosted. It has around 80 services published... Any help would highly appreciated !    Thanks ... View more

Hello, Running quite often webgisdr backup and restore to standby environment to maintain availability while upgrading the "master" one, I really miss a functionnality: being able to restore a single specific component (ArcGIS Datastore, ArcGIS for Server, Portal for ArcGIS). Something like:   webgisdr --import --file C:\propfiles\toimport.properties --component Server   It happened quite few times a full webgisdr restore fails at some step (eg: restore of Federated Server or Portal for ArcGIS). For example, lately I got a "Connexion reset" after restoring an ArcGIS Server. Rebooting Server fixed it strangely... But then I had to rerun a full webgisdr restore and wait again 10 hours for unzipping / restore relational datastore / restore tileCache datastatore / restore hosting server. It's a big waste of time and very annoying when planning an intervention ! You basically need to postpone for the next day.    I don't think this functionnality exists. There are the export/import site operations avaible for both Portal for ArcGIS and ArcGIS for Server but I am under the impression that it is solely meant to be used on the "master" environment and not the standby. For example, ArcGIS Server directory paths must be the same while with webgisdr it is not required: https://enterprise.arcgis.com/en/portal/latest/administer/windows/overview-disaster-recovery-replication.htm#ESRI_SECTION1_C2CCF3D59BAE4F93AAF841EED439FE2F So I guess webgisdr is doing some additional/different configurations while importing the exported site located in the webgisdr zip file.   Any thought about it @JonathanQuinn maybe ? Did I miss anything ? I would love to be wrong !   Thanks,   Best regards,   Nicolas     ... View more

Hello, I am facing an issue with the new 11.3 setups of ArcGIS Server  and ArcGIS Datastore: service won't start after a successfull installation. Portal for ArcGIS works. I found out there is an installation log at 11.3 in  "C:\Program Files\Arcgis\Server\framework\support", where the following error is logged: # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (codeBuffer.cpp:972), pid=7088, tid=3008 # guarantee(sect->end() <= tend) failed: sanity # # JRE version: (17.0.10+7) (build ) # Java VM: OpenJDK 64-Bit Server VM (17.0.10+7, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64) # Core dump will be written. Default location: C:\Windows\system32\hs_err_pid7088.mdmp # # An error report file with more information is saved as: # C:\Windows\system32\hs_err_pid7088.log   But as if it was not a systematic issue, I understood it was related to the CPU of the VM which is: Intel(R) Xeon(R) Gold 6326 CPU @ 2.90GHz On some other CPU, it works.  With previous versions of the setup (11.1/11.2), it works. Anyone else ? I guess one shall verify the setup works on the same CPU as the VM which is upgraded otherwise it could be a big issue I guess ! I feel lucky I realized this issue before upgrading a VM with a problematic CPU !   Thanks,   Nicolas /cc @CedricDespierreCorporon  ... View more

Hello, Many users in my organization are complaining about a security issue because of Portal for ArcGIS SAML logout behavior: it does not propagate logout to identity provider and as a consequence, users remains logged in which is a security vulnerability. I noticed the following: "Propagate logout to Identity provider" only works if logged in directly on Portal for ArcGIS (ie: OAuth client id  ="arcgisonline"). If you are logged in on Portal for ArcGIS through an OAuth application (ie: OAuth client id  ="o8WEYheNpQcE2dwwh"), then when signing out from another application, Portal for ArcGIS does not propage the logout and instead displays the following window: Let's illustrate this workflow with the diagram below: source: https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0-cd-02_html_m50a2ba3e.gif Let's say "sp2.example.edu" is Portal for ArcGIS. 1. Working scenario when logged in directly on Portal for ArcGIS: User is logged in on both Portal for ArcGIS and sp1.example.com and the user request a global logout from sp1.example.com. At step 3, Idp make a POST to sharing/rest/oauth2/saml/signout and the reply is the following:   <!DOCTYPE html> <html> <head> <title>Posting request..</title> <link href="/geoportal/sharing/rest/files/gw.css" rel="stylesheet" type="text/css"/> <script language="javascript"> window.onload = function(e) { document.forms[0].submit(); }; </script> </head> <body> <form name="f" action="https://idp.example.org/auth/realms/company/protocol/saml" method="post"> <input type="hidden" name="SAMLRequest" value="foo" /> <input type="hidden" name="RelayState" value="bar" /> </form> </body> </html>   Note the form that will POST to Idp with "SAMLRequest" and "RelayState" parameters in order to sign out from Idp. It corresponds to step 4 and it works. Now, let's compare it with the broken scenario: 2. Broken scenario when logged in indirectly on Portal for ArcGIS through an OAuth application: User is logged in on Portal for ArcGIS indirectly through an OAuth application and on sp1.example.com and the user request a global logout from sp1.example.com. At step 3, Idp make a POST to sharing/rest/oauth2/saml/signout but this time the reply is the following:   <html> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta http-equiv="X-UA-Compatible" content="ie=edge"> <meta name="referrer" content="origin"> <title>Sign In</title> <script src="/geoportal/sharing/files/scripts/detector.min.js?__ARTIFACTID__"></script> <link rel="stylesheet" href="/geoportal/sharing/files/css/site.min.css?__ARTIFACTID__"> <script src="/geoportal/sharing/files/scripts/theme.min.js?__ARTIFACTID__"></script> <script> var oAuthInfo = {"contextPath":"/geoportal/sharing","originSignin":false} window.setTheme(oAuthInfo, "/geoportal/sharing"); </script> <script src="/geoportal/sharing/files/scripts/oauth2.js?__ARTIFACTID__"></script> </head> <body> <div class="content"></div> </body> <script> oAuthInfo.locale = ((oAuthInfo.locale && oAuthInfo.locale === "iw") ? "he" : oAuthInfo.locale); require.config({ baseUrl: "/geoportal/sharing/files/scripts/", locale: oAuthInfo.locale && oAuthInfo.locale.toLowerCase() || "" }); require(["signout-new", "domReady!"], function (signUp) { signUp.startup(oAuthInfo); }); </script> </html>   which ends up to the page "You have been successfully signed out".  So coming back to our diagram, there is no longer a POST back to IDP and the logout process from IdP is broken in the middle because of Portal for ArcGIS. As a consequence, users are still logged in and as mentionned in the documentation:    If the user's web browser cache is not cleared, attempting to immediately sign back in to Portal for ArcGIS using the enterprise login option will result in an immediate login without needing to provide user credentials to the SAML identity provider. This is a security vulnerability that can be exploited when using a computer that is easily accessible to unauthorized users or to the general public.   Note that if you disable the "Propagate logout to Indentity Provider" option, you will have the same phenomena as in "Broken scenario when logged in indirectly on Portal for ArcGIS through an OAuth application" when logged in directly to Portal for ArcGIS.  As a conclusion, to me, the option "Propagate logout to Indentity Provider"  should apply for all oauth client application ("argisonline" and all the others) and not solely to Portal for ArcGIS client. Anybody else observing the same phenomena ? Any comments ? Did I miss anything obvious ? Thanks, Nicolas /cc @CedricDespierreCorporon  ... View more