Latest Contributions by JeffSmith

‎01-30-2023

Yes, we do plan on providing a fix for this for 10.9.1 as a part of the next Portal security patch. We are hoping to have this available by early March.

‎01-17-2023

The behavior you are describing sounds like an issue related to special characters in the .pfx password that are getting misinterpreted by ArcGIS Server. That being said, a bug was logged several years ago for that issue specifically which was fixed in 10.7. BUG-000107534 - SSL Certificates with special characters in the password fails to import to ArcGIS Server. At 10.9.1 I wouldn't think you would run into that issue. If it is a password issue, a possible workaround would be to import the pfx into IIS (since that works) and export it to a new pfx with a different password.

‎12-05-2022

Version B of this Portal for ArcGIS patch for 11.0 has just been released. It may take a little while to be listed in the Patch Notification tool, but it can be downloaded from the patch page. https://support.esri.com/en/download/8070

‎12-01-2022

We have identified the source of this issue in the patch and confirmed that it only impacts 11.0. We are working to fix it and hope to have version B available soon.

‎11-18-2022

Yes, there were some enhancements in 10.9.1 to validate the certificate used in the Server admin url. We didn't do this in 10.7 and while things still worked, there were some workflows that would fail if Portal did not trust the Server admin url certificate. Since you are receiving that error message, I would double-check that the root certificate and any intermediate certificates from the CA that signed your wildcard cert are imported into the portaladmin api under sslCertificates/importRootOrIntermediate. Once imported, make sure the Portal service restarts for the new certs to take effect.

‎11-03-2022

Yes, I think the issue you are seeing is related to the certificate not being trusted. An easy way to check that is to use the checkUrl endpoint in the Portal sharing api (assuming HTML access is enabled). https://our.server/portal/sharing/rest/portals/checkUrl This will tell you if the certificate for that url is trusted or not. Assuming it is not trusted, you may need to import both the root and intermediate certificate for the CA that signed the certificate. Portal will need to restart after importing these certificates. Once restarted, use the checkUrl endpoint again to confirm it is trusted. To get copies of those root and intermediate certificates, the easiest way is to use Chrome or Edge to view the details of the certificate and you can export each one from there.

‎10-07-2022

@Jay_Gregory- Once support for SAML based groups was added to ArcGIS Enterprise around release 10.7, that became the recommended workflow. Technically using SAML for logins and LDAP for enterprise groups should still work though. A couple of things to double-check: * The username attribute used by SAML (corresponding to the "Name ID") needs to match the "usernameAttribute" specified in the group store configuration json string. If you are connecting to Active Directory, this is usually "sAMAccountName". * In the SAML login configuration in Portal, make sure the option to "Enable SAML based group membership" is disabled in the advanced settings. Since you want to use LDAP to manage group membership, you want to make sure Portal is not expecting groups to be passed in the SAML assertion.

‎10-03-2022

@MarGIS, I can't say for 100% that it is not supported but I have never seen one on Linux and from what I have read, if it were possible, it would not be straight-forward. I know you can federate a Linux server with AD but I'm not sure how Linux would utilize a gMSA without explicitly providing the password.

‎09-29-2022

I'm not aware if gMSA accounts are supported on Linux in general, let alone in ArcGIS Enterprise on Linux. Is there a tool or utility you've used to utilize gMSA accounts from Linux?

‎09-14-2022

I reviewed the attached spreadsheet and based on that, it appears the Nessus Scanners from Tenable are only inspecting the filename. I'm a bit surprised by that. I would have expected more in-depth examinations by the scanner. If you use another scanner like Logpresso, you should be able to confirm the log4j jars are patched. You are correct about how the patch handled the log4j jars files. For the log4j 1.x jars, the version was not changed but the vulnerable classes within the jar were removed (this includes the JMSAppender class). For the log4j 2.x jars, they were updated to version 2.17.1. Any log4j 2.x jars with the version as part of the filename were not deleted but all classes inside were removed. This was done to avoid potential conflicts with the patching process.

‎08-22-2022

Hi Kat, Yes, we are aware of this issue that has been logged as BUG-000151727. We've identified the problem and plan on releasing a revised version of the patch as soon as possible. Until then, there is not a workaround besides removing the patch. Jeff

‎01-21-2022

No, as of right now there are no plans to release a python script for the 1.x mitigation similar to what was done for 2.x.

‎01-18-2022

Hi Dean, No, Esri has not released an official mitigation script to address any of these log4j 1.x vulnerabilities. That being said, we are actively working on patches for all components of ArcGIS Enterprise that will update the log4j 2.x jar files to 2.17.1 and remove the vulnerable classes from the log4j 1.x jar files. We can't provide a release date for them but they are taking the highest priority right now. As you and Randall have mentioned, there are dependencies on some of the log4j 1.x so those jar files cannot just be deleted and replaced with the 2.x jar files.

‎01-14-2022

Unfortunately that is one downside to storing credentials for a secured service. When editing a secured feature service with stored credentials, I'm not aware of a way to capture the org member's username instead of the username from the stored credentials.

‎12-23-2021

Not sure if you've gotten this resolved yet or not. It sounds like when you stopped the ArcGIS Server service, the javaw.exe process did not stop correctly. This would keep a lock on those jar files and generate the error you observed. If you kill that process, that should allow you to run the script. To check if all processes are stopped after stopping the service, I use the task manager and sort the processes by the username. If you are using a unique service account for ArcGIS Server, it is pretty easy to confirm nothing else is running. This of course won't work if the service account is used for other services as well.

Online Status	Offline
Date Last Visited	Friday

My Ideas

Latest Contributions by JeffSmith

Re: WHY in Enterprise are sharing options limited when one does not own the item even if you are the ADMIN?

Re: Importing CA certificate failed

Re: Portal for ArcGIS Security 2022 Update 2 Patch causing 404 and 500 errors

Re: Portal for ArcGIS Security 2022 Update 2 Patch causing 404 and 500 errors

Re: FEDERATION - Unable to validate TLS certificate (10.9.1)

Re: Problems adding external WMS reference (Spain Catastro) in Portal

Re: Users don't automatically get added to AD-linked Portal groups on SAML signin

Re: Group Managed Service Account (gMSA) on linux

Re: Group Managed Service Account (gMSA) on linux

Re: Security scan on fully patched 10.9 Enterprise (Linux) shows log4j and other vulnerabilities

Re: Invalid URL for WMTS after Server Security 2022 Update 1 Patch install

Re: Log4j 1.x Enterprise Dependency Requirement

Re: Log4j 1.x Enterprise Dependency Requirement

Re: Using AGOL credentials to store created_user instead of portaladmin

Re: ArcGIS Server log4j vulnerability - running Log4Shell Mitigation Script

Re: ArcGIS Enterprise create idp user before first...

Re: how to best set up cross origin allow

Re: Store Credentials for AGOL service layer in Po...

Re: Web Adaptor will not load configuration page

Re: ArcGIS StoryMaps - Infinite login loop