I'm trying to login in ArcGIS Enterprise, using a fairly standard call:
gis = GIS(portalUrl, user, pass)
This used to work, but now I get an error:
2023-03-07 10:08:59,110 - DEBUG - Connecting to portal: example.com
2023-03-07 10:08:59,114 - DEBUG - Starting new HTTPS connection (1): example.com:443
2023-03-07 10:09:00,029 - DEBUG - https://example.com:443 "GET /portal/info?f=json HTTP/1.1" 500 7058
2023-03-07 10:09:00,035 - DEBUG - https://example.com:443 "GET /portal/rest/info?f=json HTTP/1.1" 500 7058
2023-03-07 10:09:00,042 - DEBUG - https://example.com:443 "GET /portal/sharing/rest/info?f=json HTTP/1.1" 200 139
2023-03-07 10:09:00,048 - DEBUG - https://example.com:443 "GET /portal/rest/services?f=json HTTP/1.1" 500 7058
2023-03-07 10:09:00,157 - ERROR - Please ensure gssapi is installed
2023-03-07 10:09:00,171 - DEBUG - Traceback (most recent call last):
File "D:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\lib\site-packages\arcgis\auth\_auth\_winauth.py", line 75, in __init__
creds = gssapi.raw.acquire_cred_with_password(
File "gssapi\raw\ext_password.pyx", line 75, in gssapi.raw.ext_password.acquire_cred_with_password
gssapi.raw.exceptions.BadNameError: Major (131072): An invalid name was supplied, Minor (2529639136): Configuration file does not specify default realm
During handling of the above exception, another exception occurred: Traceback (most recent call last):
File "D:\Data\MOR\Migratie\Download-wf5.py", line 45, in <module>
main()
File "D:\Data\MOR\Migratie\Download-wf5.py", line 33, in main
gis = GIS(settings.ARCGIS_PORTAL_URL, settings.ARCGIS_USER, settings.ARCGIS_PASS)
File "D:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\lib\site-packages\arcgis\gis\__init__.py", line 585, in __init__
raise e
File "D:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\lib\site-packages\arcgis\gis\__init__.py", line 524, in __init__
self._portal = _portalpy.Portal(
File "D:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\lib\site-packages\arcgis\gis\_impl\_portalpy.py", line 205, in __init__
self.con = Connection(
File "D:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\lib\site-packages\arcgis\gis\_impl\_con\_connection.py", line 344, in __init__
self._create_session()
File "D:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\lib\site-packages\arcgis\gis\_impl\_con\_connection.py", line 691, in _create_session
self._session.auth = EsriWindowsAuth(
File "D:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\lib\site-packages\arcgis\auth\_auth\_winauth.py", line 84, in __init__
raise Exception("Please ensure gssapi is installed")
Exception: Please ensure gssapi is installed
A few things to notice:
This is on a client's environment, so I'm not sure if anything relevant has changed recently. One thing that did change is an upgrade to ArcGIS Pro from 3.0 to 3.1.
I'm seeing the same issue on a machine that I just upgraded to 3.1 A script that I run daily broke and I tracked it down to the GIS call like you found. Looking at my custom Python env and the default, it looks like the package it's looking for is requests-gssapi, which is installed by default. I tried updating, and un-installing/reinstalling the package. The former had no effect, the latter wouldn't let me uninstall.
I'm pretty sure the upgrade is the culprit. I'm weighing whether I'll lose more by uninstalling and going back to 3.0 or sticking with 3.1 until we have a fix.
I've found a workaround for now. It appears that the issue is limited to accounts trying to authenticate against Active Directory. Built-in Portal users are working correctly, so I created a new user just to run Python scripts and stored the credentials in a profile. My script is running correctly now. I'm not 100% sure it's necessary, but I also assigned the new user a Pro license to make sure it could use the API.
I'm also working with tech support to see if we can resolve the gssapi issue.
Thanks for your response, it's good to see I'm not the only one having this problem.
In the environment I'm working on, only AD users are allowed to login, so unfortunately a built-in user is not an option for me.
Please keep us informed if tech supports finds a solution!
Getting the same errors 5-17-2023. Anyone have updates on how to overcome this issue with AD users?
@SeanO_Neill Ultimately, Esri tech support determined it was out of scope. I don't fully agree, but I've got to go with that. I'm considering logging a bug on the github page. The bit of code that handles the Windows authentication has definitely changed. Just for kicks, I followed the error chain to _winauth.py in C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\Lib\site-packages\arcgis\auth\_auth. The error is happening in the EsriWindowsAuth class. I compared the code in this class for the 3.1 install and a machine that's still on 3.0.3, and this class has changed substantially. There's no attempt to import a package called gssapi in the older one. If I were braver, I'd try swapping the old code in to the new _winauth.py file, but I don't feel like voiding my warranty.
Interestingly, gssapi is included in the new site packages and I can import it from the Python script window. I still get the import error, though.
Looking at that code block some more, I realized that just because the exception returned by the try/except block says "Please ensure gssapi is installed") doesn't mean that the problem is with importing gssapi. It turns out, that's not the issue.
Looking at the error messages again, I realized I was overlooking the core error, which happens a few lines after importing gssapi and generates the error message in @BerendVeldkamp 's original post:
gssapi.raw.exceptions.BadNameError: Major (131072): An invalid name was supplied, Minor (2529639136): Configuration file does not specify default realm
This is a gssapi error, so the "Please ensure gssapi is installed" is a red herring. To me, this supports Esri having made an error in the code somewhere. I'll definitely be filing a bug report.
@JCGuarneri Thanks for that update. I will also pursue a bug in git and see if it goes anywhere. This is extremely frustrating for such a fundamental operation. -And nice reconnaissance!
I could have sworn I tried this before, but I'm finding it works properly if I try authenticating as "user@domain" but not if i use r"domain\user".
For me this does not work...I did see your post about hard coding the creds and I'm going to investigate that. Thanks for all the input on this issue...