We seem to have problems with this. Is it possible to register a database to ArcGIS Server using OS credentials instead of saved DB credentials and then edit that service from Portal. Our attempts seem to have failed in this regard. This causes an issue because the CreationUser/LastUser will show the saved credentials not the actual editor if using Editor Tracking
Solved! Go to Solution.
Joe,
We are using SQL Server 2014 with Windows Authentication for our enterprise geodatabases and are at 10.4.1 for the web GIS. What worked for us was to grant the service account running ArcGIS Server read/write access to the databases we needed to edit from a feature service. Once this was working, ArcGIS Server started writing the proper username from Server/Portal into the editor tracking fields. Note that we are using domain accounts in production but I remember testing this successfully with a workgroup account as well.
Levin Conway
Yes, it is possible to use OS authentication in Editor Tracking to capture the OS user making the edits. When you say your attempts have failed, do you mean your attempts at registering a database using OS credentials with Server, publishing a feature service, or editing the feature service in Portal and seeing the Editor Tracking fields populate with the user making the edits? Is the Server federated with Portal, or is it standalone? If it's federated, are you using IWA for the security for Portal? If not, are you using IWA for the security for Server?
Jonathan,
I have the same question. Is there a white paper or some other documentation available that addresses these specific questions?
The documentation on setting up editor tracking goes through the steps required. Once it's set up on the feature class, restart the service if one already exists or publish your service. Note that unsecure, or open services, won't record a username since there's no credentials passed along with the edit request, thus no way to determine who made the edits.
I have had issues registering data with these connections. But in this case the edit operation simply failed. We receieved a message, "Layers are not accessible to Portal for ArcGIS. Thus editing will be disabled on these layers" I am not 100% sure the issue was with the OS authentication, but it seems changing it to DB authentication has fixed the issue. I will go back and play around time permitting and see if I can replicate the error
Joe, are you on 10.4? That error typically comes up when you use services from an unfederated Server configured with IWA, and it shouldn't be related to how the Server accesses the data, (OS or DB authentication). The client, (in this case Portal), won't know how the data is accessed. If you're on 10.4 for Portal, then you can take a look at setting up trusted servers:
Configure security settings—Portal for ArcGIS (10.4.1) | ArcGIS for Server
For Trusted Servers, configure the list of trusted servers you wish your clients to send credentials to when making Cross-Origin Resource Sharing (CORS) requests to access services secured with web-tier authentication. This applies primarily to editing secure feature services from a stand-alone (unfederated) ArcGIS Server or viewing secure OGC services. ArcGIS Servers hosting services secured with token-based security do not need to be added to this list. Servers added to the trusted servers list must support CORS. Layers hosted on servers without CORS support may not function as expected. ArcGIS Server supports CORS by default at versions 10.1 and later. To configure CORS on non-ArcGIS servers, please refer to the vendor documentation for the web server.
The host names need to be entered individually. Wildcards cannot be used and are not accepted. The host name can be entered with or without the protocol in front of it. For example, the host name secure.esri.com can be entered as secure.esri.com, http://secure.esri.com, or https://secure.esri.com.
Joe,
We are using SQL Server 2014 with Windows Authentication for our enterprise geodatabases and are at 10.4.1 for the web GIS. What worked for us was to grant the service account running ArcGIS Server read/write access to the databases we needed to edit from a feature service. Once this was working, ArcGIS Server started writing the proper username from Server/Portal into the editor tracking fields. Note that we are using domain accounts in production but I remember testing this successfully with a workgroup account as well.
Levin Conway
One we created a domain user to run AGS and then added that database I got everything to work as desired. Then I could register an OS connection and publish the services correctly.