In Collector, if a user downloads a web map containing secure ArcGIS Server services, and then collects some data, could that user encounter problems with synchronizing if their password changes?

[BrittanyMcKnight1]

Hello, 

We have been encountering some odd sync issues with Collector (iOS) that appear to be related to a user's credentials.

Several of our web maps contain secure ArcGIS Server (10.3.1) services. Our ArcGIS Server site is secured using Windows users with AGS built-in roles. Our department requires that a user's password be updated every six months. 

We have observed that if a user has downloaded a web map, collected some data, and then tries to synchronize edits after changing their password, they will receive a prompt from ArcGIS Server for their credentials. These prompts will persist, even after the user inputs their credentials (updated password as well as old password, if they remember it). It appears that Collector is looking for the password used to download the data, which has expired, whereas ArcGIS Server is looking for the user's current (updated) password. Unfortunately, this causes an endless cycle that eventually prompts us to manually recover the data from the user's device. 

To avoid this issue, we have been messaging out to our end users that they need to synchronize any pending edits as well as remove the download features, prior to updating their password. At which point, they can re-download the features. 

A similar situation has occurred with our other ArcGIS Server (10.3.1) environment that is secured using AGS built-in users and roles. In this situation, we have users who forget to synchronize their edits prior to signing out and handing over a shared device to one of their colleagues. When this second user tries to synchronize their edits, they are prompted for credentials. The only problem is that this prompt is actually for the first user's credentials, which is not apparent to the second user, and so the second user will enter their credentials. In order to resolve this, the first user must log back in, synchronize their edits, sign out and then hand over the device back to the second user, so that they can synchronize their edits. 

So, I guess my question is, does Collector preserve/maintain the user credentials that were used to download the data and if so, must these credentials match those on the server-side in order to synchronize? I believe this is the case, because I observed the same token returned in the generateToken request being passed for the createReplica and submitJob requests. I just imagine that this is further complicated with the addition of token expiration.

Thank you in advance for the help! 

[ScottFierro2]

We were using 10.3.1 as well for Collector with iPads for our end users and currently upgrading to 10.5. I can say we have seen similar issues as you.

The password change issue unfortunately is something I am not sure will go away anytime soon. The reason behind that is when the users download for offline use a replica GDB is built on the ArcGIS Server which is essentially a snapshot of the SDE at time of download. This replica mirrors the SQLite database that is loaded onto the users device. So the issue seems to lie within the replica on the ArcGIS Server because it stored the credentials at time of creation and expects to be able to pass that between the user and the backend environment. The cases you have where the user can remember old password but still doesn't work would be their credentials working from the local device to the replica but then failing on the server authentication and possibly with your DB authentication if using AD there as well.

Unfortunately, would say it sounds like you are doing all you can and we actually include this as part of our initial training event with end users.

With regards to the second issue, have you attempted doing a hard app close between the 1st and 2nd user?

Can't say we have seen issues with this but again we have a very specific workflow that at training defines to users exactly what steps must be done prior to going out and upon return. We have seen some sync issues in the past where user was logged in and downloaded offline map fine, got back to office went to sync and it fails with log messages tied to error matching replicaID. Having the user double tap the home button to do a full hard close of the app, sign back in and sync seems to resolve the issue. We've only had 1 time this didn't resolve things and as best we can tell it's tied to local caching on the iPads that's outside of ESRI's control because we have worked through a few of these events with the support guys and had zero luck explaining or finding the root cause. Anyways, that's why I'd be curious if the hard close would resolve things in your situation because despite our stringent workflow we have had users forget to sync come back 3 days later after others have used it, logged in and realized they had not sync'd so they sync at that time but there were no issues with others ability to use the device.

I'd say you are right with regards to token generation and expiration. Inevitably there will be mistakes and situations and all we've done here has been to stress the importance of the rigorous workflow we have laid out for the users in order to ensure their work doesn't get lost/corrupted and that everyone can use things when they need to.

[BrittanyMcKnight1]

Hi Scott, 

Thank you for the reply and for confirming that you have experienced similar behavior. I appreciate the detailed explanation.

 I agree that this behavior with stored passwords will likely not change. I'm just glad to know that it wasn't an error on our part. 

Also, thank you for the suggestion regarding the 'hard close' of the app. I want to say we had tried this when we were encountering the issues with the shared device, but still its a great suggestion and definitely one of those 'best practices' to put into place. 

Thank you again!