ADF and REST sites sharing the same secured ArcGIS map service?-Should be possible according to 3.6 Release Notes
The release notes for Essentials 3.6 indicate Essentials now supports connections to ArcGIS Services using Windows Integrated Security. If I'm interpreting this correct, this means REST sites can now access ArcGIS Map Services that are currently secured with Windows security.
In a separate post I was told, "Essentials will now alternatively support ArcGIS Server services that are secured with Windows Integrated security."
Unfortunately, no indication was given as to how I would go about accessing the services in REST Manager to set up the site. REST Manager is apparently defaulting to looking for SQL Server user stores for secured map services. I've searched all the documentation associated with 3.6 but I haven't found anything describing how to use this new capability.
This is a capability I would really like to take advantage of! How can I use this new feature? Is there any documentation?
-
Thanks for the detailed reply, Jonathon. Unfortunately, it doesn't "just work" for me.
Essentials and AGS are installed on the same server. The Windows user has permission to access the services in question. Even with those requirements met, there are no services displayed as available in the REST Manager. The rest of the map services on the server have been configured to allow any authenticated user to see the services. None of those are displayed, either.
I configured the ArcGIS/REST directory in IIS to use Integrated Windows Security so I could verify the security settings were at least working properly through a browser. The appropriate account was able to see the secured REST endpoint through the browser but still not through the REST Manager interface.
After that I disabled security in AGS and restarted the services. With security "off" I set up a test site using the previously secured map service. After everything was set up and working I re-enabled security. When I opened the "Map" link in the REST Manager I got an error indicating the connection to the now re-secured service failed, even though it should be accessible to that login.
At this point it appears version 3.6 is behaving exactly the same as previous versions of GE REST Manager did on this server, with regard to accessing Windows secured services.
0 -
The REST endpoint is accessed initially by the EssentialsAdmin user, not by the logged in user. So it is a requirement that this user be given access to the mapservices, even when ArcGIS Server and Essentials are installed on the same system. Sorry if this was unclear.
If you are using the group 'agsadmin' to control mapservice access this should already be the case. If you are not then you will have to add EssentialsAdmin to whatever group you are using.
0 -
I was using the agsadmin group to control the map services, however, the EssentialsAdmin account was not a member of that group. I added it, but it didn't make any difference, I still do not see any services in REST Manager.
Would the fact that the EssentialsAdmin account already existed from the installation of a previous version of GE cause a problem with 3.6 being able to use Windows secured services? Does a clean install of 3.6 put the EssentialsAdmin account in different security groups than previous versions?
0 -
It does sound like this should be working. Make sure that in your IIS configuration the ArcGIS Server REST application has Windows Authentication enabled, and Anonymous Authentication disabled. This is important, as otherwise the application will default to anonymous authentication and fail.
If you would like to start up a support case (send an email to support@latitudegeo.com), one of our technicians would be happy to take a look at your setup in person.
0 -
I finally got a configuration that displays Windows secured map services in the REST Manager, but this was not something that just works out of the box. At the very least the following needs to be done before REST Manager will see the Windows secured services:
1. Add the "EssentialsAdmin" account to the "agsadmin" group. (It isn't there by default.)
2. Enable Integrated Windows Security in the IIS Manager for the rest directory in the ArcGIS directory
3. Disable Anonymous Authentication in the IIS Manager for the rest directory in the ArcGIS directory
4. Add the agsadmin role to the "Allowed Roles" for the map service desired.Now the problem I'm having is Silverlight. The REST Manager will create the viewer.xml file, but then displays an error message:
"Unable to load viewer configuration. The file 'http://<servername>/Geocortex/Essentials/<instance name>/REST/sites/TestSite/Viewers/Viewer/VirtualDirectory/Config/Viewer.xml' or one of the referenced external configurations could not be read or has errors. See log file for more details."
The REST log file has a similar entry that says:
<Event Timestamp="2011-12-29T15:26:53.9306355-06:00" Level="ERROR" Identity="Super"><Message>Error occured during REST request: The site with ID "TestSite" failed to initialize. Refer to the logs for more details.</Message></Event>
There isn't anything in the IIS logs related to this error. What log file is this referring to?
Even though an error is displayed, the viewer.xml is created. I’m speculating there’s another permission problem somewhere related to the default viewer file paths, so I granted the EssentialsAdmin full access to the Silverlight Viewer directory, but that didn’t make any difference.
Also, I noticed that after I got the services working, when I logged in to REST Manager with Firefox I was prompted for a login for the Map Preview window (which appears to be a small Javascript viewer). Since Firefox didn’t pass any Windows credentials, the viewer prompted me a second time. When I enter my credentials a second time, the preview window is populated. That leads me to believe Silverlight isn’t going to work…
Before I waste any more time on this, is the Silverlight Viewer even useable with this configuration?
0 -
The Silverlight Viewer is certainly usable with this configuration. The identity of the user will be attached to all requests to ArcGIS Server, and if that user is allowed to access the services they will be able to see the map. Depending on the web browser used, and whether the access is internal or external, they may be prompted to authenticate. Internet Explorer on an internal network will generally pass the credentials along without the user having to type them in.
The issue with the viewer.xml file may not be related to Windows security at all. First of all, check whether Geocortex Agent is running when you create the viewer, and restart this service and try again if it is not. If you continue to receive this error, the likeliest cause is a permissions issue. Check the file permissions for the 'Sites' folder within 'REST Elements' in your Essentials installation directory. In a default installation 'Essentials' should have 'Read & Execute' access, and 'EssentialsAdmin' should have full control. Make sure these settings are propagated to all files and subfolders of this folder. Also note that the users you need to give access to will change if you have changed the identities of the Essentials application pools in IIS.
The log file referred to is the REST log. You'll find this in ..\REST Elements\REST\App_Data\Logs. The SYSTEM log is the one you are interested in, and it should contain further details about the cause of this error. If there are no log files at all, it is a sure sign of permissions not being set correctly as specified above. The same permissions are needed for this folder, but they need to be set separately as this folder is not part of the 'Sites' directory structure.
0 -
The Geocortex Agent is running. The file permissions are correct and propagated to the files and subfolders. I have not changed the identities of the application pools in IIS.
I decided to look at this from a browser perspective. The bottom line here is there is a problem when I compare the ESRI REST endpoint with the GE REST endpoint. As long as "Domain Users" have access, I can expect both endpoints to be accessible. The problem is when I restrict access to the map service to a specific role (security group). The ESRI REST endpoint behaves as expected, the GE REST endpoint does not.
For example, if the map service is set up so “Domain/Account_A” is in a role that has been granted access to the map service, the ESRI REST endpoint will display in a browser when “Domain/Account_A” is logged in on the PC. If we also have an account "Domain/Account_B" that is not in the role that was granted access, "Domain/Account_B" will not be able to see that same ESRI REST endpoint in a browser.
However, using that same scenario, when the REST endpoint generated by GE is accessed by "Domain/Account_A", I get a “ 500 – Internal server error. There is a problem with the resource you are looking for, and it cannot be displayed ”. The log file indicates the site failed to initialize. This even happens when using the link provided in the REST Manager.
The account I’m logged in with during these tests (which would correspond to "Domain/Account_A") is a also member of the agsadmin group, so regardless of the other roles involved, I would expect this to work because the agsadmin role has been granted access to the map service.
In other words, the problem appears to be that the GE REST endpoint is inaccessible to the account, even though the same account can access the ESRI REST endpoint the GE REST endpoint is based on.
0 -
Is 'EssentialsAdmin' in a role that has been granted access? This is the user that is creating the GE REST endpoint, and if it is not being constructed you should look at the access of this user, not the user sitting in front of the computer.
As stated above, it does not have to be made a domain account to access services on another server -- a local user with the same password will work as well.
0 -
Yes the EssentialsAdmin account is in a role that has been granted access to the map service. We established that some time ago. The problem is not that GE REST endpoint isn't being constructed, because it is being constructed.
The user sitting in front of the computer is precisely where I need to look because that is where this is failing.
I'm going to try explaining this another way. Here are the steps I've followed:
1. Add the "EssentialsAdmin" account to the "agsadmin" group.2. Enable Integrated Windows Security in the IIS Manager for the rest directory in the ArcGIS directory
3. Disable Anonymous Authentication in the IIS Manager for the rest directory in the ArcGIS directory
4. Add the agsadmin role to the "Allowed Roles" for the map services desired.
5. For this scenario, let's say two security groups exist. One for all users, the other for a small group of users that will use this specific application.
a. For all user access, I am using the "Users" Windows security group that is local to the server (because "Domain Users" is a member) and adding that to the map services for the base layer.
b. For the more secured map service I created a new security group (we'll call it "AppUser") with a small number of domain accounts added to it. That "AppUser" role was added to the map service that needs tighter security.
c. Remember that agsadmin was already added to both map services.
6. Launch GE Manager and create a new site.
7. Add the map services. Both are visible in the manager.
8. Finish the site creation.
So far so good. Both services are added and can be viewed in the GE Manager preview window. The next step is where the problem can be seen.
9. Click the "Site Info" tab in GE Manager
10. Click the REST URL link. An error is displayed indicated the site cannot be initialized. (I concluded this is the source of the error I originally posted about when I tried to edit the viewer.)
11. I changed the Authentication for the "rest" directory for this site to Windows Authentication, thinking that would force a prompt, but the error remains.
12. I removed the more tightly secured map service from the site. The URL now works with the more secured map service removed.
The steps above indicate the "EssentialsAdmin" account has access, or I wouldn't see the services in the GE Manager.
The fact that I can browse to the map service ESRI REST endpoint with my login tells me the account I'm logged in with (which is a member of "AppUser") has access to the secure map service.
It appears to me that the ability to access the more tightly secured map service via the applied role is not being passed on to the GE REST endpoint.
0 -
As I continued to work with this I discovered that it wasn't the inclusion of "Domain Users" in the map service role that was granting access to everyone but rather "NT AUTHORITY\Authenticated Users" on the local machine that was granting access to everyone. ("NT AUTHORITY\Authenticated Users" is included in the local "Users" security group.) I left "NT AUTHORITY\Authenticated Users" in the role for the secured map service so I could at least finish working on the site.
Since we have a secured map service, we also want the site secured. I added Windows security to the site only to find that the site wasn't accepting any log ins. At that point I remembered a previous thread where a poster said he was instructed to change the identity of the application pool to "Network User" when using Windows security on a site. After I did that, the site login worked.
With everything now working as expected, I went back to the map service and removed "NT AUTHORITY\Authenticated Users" from the security role and tried the site again. This seems to work as expected now.
Unfortunately, now my workflows no longer work with "NT AUTHORITY\Authenticated Users" removed from the role on the map service. The workflows do still work in the simulator. It appears the workflow is failing at the Query Task when run from within the site. The advantage I thought Windows security might provide does not appear to exist.
0
Du måste logga in om du vill lämna en kommentar.
Kommentarer
10 kommentarer