Setting Site security using Windows Authentication
I'm trying to lock down a site to a specific department using the Windows Authentication option in GC 3.4. It seems very simple - enable security in the site, choose Windows Authentication and then add the Active Directory role names on the Site Permissions tab. When I do this, the Silverlight viewer challenges me for a user name and password. Although I enter what should be a valid response, the challenge comes back two more times, then errors out.
I have tried roles that I am a member of and my individual account (domain\user name).
I think I must be missing some other setting, perhaps for IIS. We are running Windows 2008 R2 on the web server. I have disabled Anonymous Authentication and enabled Windows Authentication in IIS for the Default Web Site\Geocortex virtual directory. That virtual directory is set to use the DefaultAppPool which is running under the ApplicationPoolIdentity identity.
I saw some references to change the app pool identity to Network Service. Can anyone verify this is the correct thing to do?
What else needs to be configured?
Thanks,
Pat K - Napa County
-
Hi Patrick,
Can you tell me if you are able to browse the Essentials Sites directory through our REST API? i.e. go to: http://yourmachine/Geocortex/Essentials/REST/sites. Also, what browser are you running?
Thanks,
Jeff
0 -
Jeff,
Thanks for replying. I did get this worked out through Tech Support. The fix was a combination of the following:
IIS - enable Windows Authentication for the REST folder. Another forum post lead me to believe it was the Geocortex folder. Also, configure this folder to use the EssentialsAppPool3 app pool.
Web.Config file - Edit the EssentialURL in the web.config file under REST Manager to remove the full domain name. It should be servername instead of servername.co.napa.ca.us . I'm not sure this made a difference, but I'm including it anyway.
App Pool - Set the EssentialsAppPool3 app pool to run under the Network Service identity.
Role Names - use the actual role name from Active Directory instead of the display name. We had been using the display name in our Web ADF apps. These role names included special characters, specifically a dash (-). They were created this way for sorting. For example, - GIS Group was the display name for a role containing the GIS personnel. This worked for Web ADF, but not REST. We had to use GISGROUP which is the actual role name. We also had to preface the user or role name withe domain name. For example, DOMAINX\GISGROUP .
Hopefully, this will help someone else. It would be great if the GC documentation and/or knowledge base could be updated to make it more complete.
Pat
0 -
Thanks for posting this, Pat. I've been trying to sort out the same problems with IIS on 64-bit Server 2008 R2.
It seems the key to getting this to work is the use of the Network Service (or other builtin account)identity for the EssentialsAppPool3 application pool. However, the changes above did not behave in a consistent manner the first time I did that configuration.
For example, I made all the required changes and things seemed to work well initially. Unfortunately, for reasons I could not determine, the security settings simply quit working properly. Firefox always worked properly, but IE would sometimes prompt for a login, other times just open the site, even for an account that was not granted permission. It was too inconsistent, so rather than waste any more time, I rebuilt the site and re-applied security. I also set up a new application pool for that site only. So far, that configuration continues to work as expected.
One other problem I've encountered, if Anonymous Authentication is disabled for the REST directory, the site manager cannot edit the viewer. If I need to go back and change the viewer config, I have to make the change in IIS first to allow Anonymous Authentication.
Documentation for this really does need to be updated. I used the same steps that were covered in the training class I attended. Those steps worked in the training environment, which I think was Windows 7, but definitely are not working with any of the Windows 2008 servers I've tried.0 -
Steven - things have been pretty stable for us. I would agree that the Network Service identity is the key. As far as your Anon Auth problem, we have avoided that by making all our edits in our Dev environment which doesn't have the same security as Prod. We're mostly just copying files to Prod and not using the Manager for anything.
Pat
0 -
The key to getting Windows Security to work is the setting of the App Pool identity to Network Service. The reason for this is that 'Network Service' is by default allowed to talk to Active directory to authenticate you, while the local 'Essentials' user is not. You could create your own custom domain user, and give it the proper credentials to talk to Active Directory, but there is usually little point to this, as 'Network Service' works fine and there are no drawbacks to its use.
The other key point mentioned here is that it is the actual name of the group and not the display name that is needed, and this must be prefixed with the domain name -- DOMAIN\GISADMIN. The other items mentioned in this thread should not have an effect on the functioning of Window Security.
0
Please sign in to leave a comment.
Comments
5 comments