I've got a little server plugging along, with IIS and some other stuff. Is it possible to allow a second user access to the IIS Manager, with the ability to create and edit sites, but keep the two accounts' sites separate?
I'm not worried about security between the two accounts, just separating the two account's sites for neatness and so that one user doesn't accidentally change something tied to the other account. At the moment I have two users part of the administrators group, and if I open IIS Manager with either one they both show all the sites.
A similar question has already been asked: how to create hidden web site on IIS
Can you please expand the answer of that thread?
Update 1
Connecting to sites remotely would allow the other sites to appear hidden as you would only see the connecting site. See: How to use Internet Information Services (IIS) 7 Manager to connect remotely to your website.
Update 0
As for hiding sites and other features, check out: What is administration.config for IIS?
One little known feature of IIS7 is that it's UI is entirely extensible! This means that anyone can write a C# assembly and get it displayed through the IIS Manager UI. The possibilities here are endless, anything from someone writing a new certificate management system, a website provisioning system, etc.
I haven't found documentation stating that the actual sites can be hidden but it sounds like it should be possible.
An Overview of Feature Delegation in IIS 7.0 may also provide the ability to hide sites.
Other links:
How do I hide 'non-delegated' features in IIS 7?
Based on your description, Microsoft's documentation on Configuring Permissions for IIS Manager Users and Windows Users (IIS 7) might prove helpful. For instance:
Allow an IIS Manager User Account to Connect to a Site or an Application (IIS 7)
Note: For IIS Manager users to connect to sites and applications for which you grant permission, you must configure the management service to accept connections from users who have IIS Manager credentials. For more information about how to configure the management service, see Configuring the Management Service in IIS 7.
Configuring Permissions for IIS Manager Users and Windows Users (IIS 7) - Emphasis added.
Use the IIS Manager Permissions feature to allow users to connect to sites and applications in IIS Manager. Remove a user account when you no longer want the user to configure delegated features in a site or an application.
Permitted users can configure delegated features in any sites or applications for which you grant them permission. Users can be either IIS Manager users, which are credentials created in IIS Manager by using the IIS Manager Users feature, or Windows users and groups on the local computer or on the domain to which the computer belongs.
Related
I am currently running:
Windows Server 2016
SQL Server 2016
IIS
Cognos Analytics 11.1.7
SSO
SSL
MS Active Directory
This is a single-server install, so the content manager, dispatcher, and gateway are all on one Windows machine. On the ibmcognos application in IIS, Windows Authentication is enabled and Anonymous Authentication is disabled. In Cognos Configuration, "Allow anonymous access?" is set to False.
I want to make my Cognos offering available on the Internet. So I'm thinking I need "Allow anonymous access?" set to True and Anonymous Authentication is enabled. But I'm sure it's more complicated than that.
Here's what I'm thinking:
Add a Windows Server with IIS to my environment.
Install Cognos gateway on the new server.
Configure IIS for Cognos and allow anonymous authentication.
Configure Cognos (gateway) to point to my existing system.
Change "Allow anonymous access?" (on my existing system) to True.
For testing, can this all live on one server?
Install Cognos gateway into a separate folder.
Add a web site to the IIS web server.
Configure the new web site to use the new gateway and anonymous authentication.
Is that it? Is it that simple?
I know I'll need to adjust folder permissions in Team Content as appropriate to accommodate Everyone and still provide security.
I know there are risks concerning potential workloads on the Cognos server when I allow the entire planet access to it.
This turned out to be simpler. No additional install is needed. All that is needed is to change "Allow anonymous access?" to True on my initial configuration and allow Anonymous Authentication in IIS. Then all users get access to the objects that Everyone can see. To get access to internal-only content, they must click on the Personal menu and select Sign in. Not tested, but anyone not already authenticated in the Active Directory domain should get challenged for credentials.
I'm running IIS 7.0 on a Windows 2008 R1 Server and want to setup IIS Manager Users. Due to some fact, every last try to access the site is rejected (HTTP Unauthorized).
The following additional IIS components are installed:
Security\Basic Authentification
Security\URL Authorisation
Management Tools\IIS Management Console
Management Tools\Management Service
Then I configured the Management Service to use Windows or IIS-Manager-User Credentials.
I also added some IIS-Manager-Users and activated them on my Website.
On the Authentification Settings Pane, I disabled anonymous access and enabled basic authentification.
As a result, when browsing the website, a password is now required. The thing is, I can access the page with Windows Credentials, but not with the IIS Manager User Credentials. In this case the result is always HTTP 401 - Unauthorized.
What am I missing?
IIS Manager Users are meant for administration of IIS (aka management of the sites/apps) and not for access the server at runtime (normal browsing of content).
Having said that, you can make that work if your scenario is to use the same users for potentially administration (like using WMSVC) and runtime and I wrote a blog about it on 2008 on how to set it up:
http://blogs.msdn.com/b/carlosag/archive/2008/09/26/using-iis-manager-users-in-your-application.aspx
We have moved our .NET web app deployment to Microsoft WebDeploy 3.0, and the transition has gone really well.
We are able to quickly and simply deploy to dev, test, and soon, production. But we'd like to add an extra level of restriction for deployment to production. Partially for security, but mostly to avoid "oops, no I didn't." moments.
The user accounts that deploy to dev and test are domain admins. Is there a way to restrict who has access to connect to the WebDeploy service or who can publish? I'd like to remove Domain Admins from production WebDeploy, and add a deployment account used exclusively for this. But Domain Admins will still need pretty liberal access to the server, I'd just like to restrict them in WebDeploy.
[This seems to be a different question than most are asking, which is how to allow addtional, non-admin users access. I'd like to know how to disallow admins access.]
Since you have tagged with iis 7.5 I am assuming you are on IIS7. In that case you can use WMSvc service on the server for the deployment. [Web Management Service]. This service uses delegation to allow or disallow users. This is how web deployment works in a hosted environment.
You can by default give every dev access to a particular site or app under a site and give read only access to some. You can still have super user permissions to the admins by enabling a setting called dont apply delegation rules for admins. Here is an article that gives detailed description about this can be acheived.
http://www.iis.net/learn/publish/using-web-deploy/configure-the-web-deployment-handler
I have an application running on IIS 6.1 with .NET framework 2.
At IIS's Authentication, I had disabled Anonymous Authentication and enabled Windows Authentication (with NTLM on top). Because this application is for internal use only and the authentication will be based on user's NT account from AD.
When I tried to launch the application, everything is ok. But when I wanted to view other pages that are in the different folder with the default page, IIS keep asking the users to login. And when I tried to login with my NT account, it failed.
So I looked for the event log and found out the event ID is 5011, which is 'Web sites and Web applications depend on the availability of Internet Information Services (IIS) application pools. IIS application pools in turn depend on the Windows Process Activation Service (WAS). If WAS is not running or errors occur during the startup or shutdown of an application pool, Web sites and Web applications may not be available.'
I would like to let the user to browse the application without having the login window keep showing.
Please help.
Check that the user's domain accounts have file level permissions (Read only is sufficient) to the website files.
We have been running WSS 3.0 for our intranet. We are going to be moving our internet site to WSS 3.0. The vast majority of people will access the new internet site anonymously. My question is in regards to the few people who will need to authenticate so that they can access intranet material from the internet.
We are going to host the intranet and internet sites on the same server. WSS 3.0 has already been installed, updated, and configured for our intranet. What would be the best way to set up the internet site collection so that it can be accessed anonymously but also so that when a user authenticates they can access intranet content as well? Currently the only way to access the intranet is to be on the companies domain with credentials that have access to it. What we would like to do, if possible, is use the login form that is built into WSS to make access to intranet content available opposed to setting up a sub domain.
You may use SharePoint alternte mapping feature as described in this article.
Configuring Multiple Authentication Mechanisms with Alternate Access Mappings in Windows SharePoint Services 3.0
I'm assuming that your Internet site collection and intranet site collection are not the same site collection with what I'm about to write. I am assuming, however, that they are housed in the same web application. If that's the case (and I understand enough of the specifics), here's how you'd carry out what you're trying to do:
Establish a Web application to house your site collections. You've already taken care of this (since you have your site collections available to you internally). In setting up a Web application, it (by default) is exposed at a URL (or server:port) through the Default zone mapping. For our purposes here, we'll assume that this is the URL through which you want to access the site internally (on your Intranet).
In order to expose your site collections via the Internet, you're going to want to extend the Web Application housing them. This is done through Central Admininstration > Application Management > Create or Extend Web Application. In extending the Web Application, you're creating another IIS site with (ideally) a publicly-accessible URL that can be exposed to the Internet. You'll be asked to pick a zone as part of the process; given your needs, I'd go with "Internet."
At this point, the Internet zone (you just extended) is still setup to use Windows authentication and Active Directory as it's membership provider. Though you probably want to keep AD as a membership provider (based on what you've stated), you'll probably want to look at enabling Forms-Based Authentication (FBA) on your Internet zone. Microsoft has a video on that here: http://technet.microsoft.com/en-us/windowsserver/sharepoint/dd355701.aspx. Note: you won't want to use the SQL membership provider if you intend to continue using Active Directory accounts. Instead, you'll have to wire-in the Active Directory Membership Provider for FBA. Some info on that can be found here: http://blogs.msdn.com/solutions/archive/2007/08/27/forms-based-authentication-fba-in-wss-3-0-moss-2007.aspx.
At this point, your Default zone site should use NTLM and an intranet-available URL. Your Internet zone site should use FBA and have an Internet-available URL. You'll need to enable anonymous access on your public site collection for the Internet zone. This is done through a combination of Central Administration changes and changes from within the site collection itself (http://www.mindsharpblogs.com/ben/archive/2007/02/11/1557.aspx). Important point: when going into the site collection to enable anonymous access, be sure to go through the Internet URL; don't go through the default zone (i.e., the intranet zone).
With all of these things in-place and your site collections (or more specifically, the IIS site servicing the Internet zone Web application) wired-up to the outside world, you should be good to go.
I made a number of assumptions as I wrote this, so you may (obviously) need to adjust. Setting up anonymous access isn't overly hard, but there are a lot of steps to it. If you hit hiccups along the way, don't be afraid to search for answers. Many folks have done it successfully ... but more often than not, there are challenges along the way.
Good luck!
You can also create a web application for your intranet use, so user's who are in the domain get access through an internal URL authenticated, and then extend that web application for the extranet application for anonymous users....