Unable to Store Credentials with secured feature service

[AllenScully2]

Attempting to add  ArcGIS Server 10.9.1 secured feature service to AGOL as an item, using URL.  

I can add the service to a map, enter credentials, and they are accepted, save the map, no issues.  But when I add the item and say 'save credentials' it fails, says invalid user name or password.  The error details are attached.

We have investigated ArcServer config, webadaptor and IIS settings, reverse proxy settings - to the best of our knowledge this should work - and we use this fairly simple workflow on our current production environment (which is 10.7.1) - So I am left to wonder if this is a bug for 10.9.1, or something with our reverse proxy passing credentials?  But you CAN pass credentials, AGOL just can't save them.  

Thanks -

Allen

[MiguelParedes]

Greetings @AllenScully2 

When adding the ArcGIS Server service to your ArcGIS Online org, do you see the option for saving credentials?

If not, please check the following Tech Support article for guidance: The option to store credentials is not available when adding secured services in ArcGIS Online.

Hope the above is of assistance.

[AllenScully2]

Thanks Miguel - 

I do see that option, and when I activate it, enter credentials, all seems well.  It's when I get to the final step to save the new item in AGOL when I get the helpful message 'An error has occurred' - 

So AGOL can see the service and even pass credentials, but will not save them for whatever reason.  

We have the same set up our current Prod  system, with a 10.7.1 ArcServer/Web Adaptor set up using the same reverse proxy entry.  The only difference we can see is that the one I am testing is using Enterprise 10.9.1

[Gordon_Aberdeen]

Same here, even with SSL and all other requirements..

[JohnHo2]

Were you ever able to resolve this issue?

[MasonCordell]

For what it is worth, I have run into this issue. Turns out that my password had multiple '-' characters in it, and AGO decided to add a space before one of them. I noticed it on both Google Chrome and Firefox by using the browser's inspect tool and looking at the console logs. It also passed the password in plaintext, very cool.

[MiguelParedes]

Greetings @MasonCordell 

That is quite interesting.  Would you elaborate a little more, please?  When you say that your "... password had multiple '-' characters in it, ..." do you mean something like "my--password", or was it "-my-password"?
Also, by the browser's inspect tool, do you mean Developer Tools?

[MasonCordell]

Hello Miguel,

Yes, I do mean the browser Developer Tools. I often use them to inspect what's getting sent around. And yes, a hypothetical password like 'This-is-my-password123&' In this particular case, the odd bit was that it transformed it to 'This-ismy-password123&'. Once I changed the account password to a string of random numbers and characters, it passed to the next (white, static, never loading screen). I tried this both with uBlock Origin on (originally) and then off on a fresh load of the page and the behavior did not change.