Webdeploy is very convenient from Visual Studio 2010. Today I am using it to publish my project via a remote deploy agent (http://x.x.x.x/MsDeployAgentService) to a production web server facing Internet.
Although administrator password is required, is it a good practice to leave http://x.x.x.x/MsDeployAgentService accessible to everyone or should I care more about the security of this subpath so that it cannot be accessed from Internet?
If I need to allow deployment only from certain internal URLs, how do I secure the deployment agent service?
It seems pretty secure as a few shared hosts are using it for their clients.
Security note
Set it up so that you are using IIS managers and not Windows Logins.
There is an implicit restriction on what IIS managers can do, rather than Windows, and passing out Windows logins means access via RDP to the server (usually)
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 have a Shibboleth service provider (SP) served by a web farm with no outbound internet access (for security reasons). The web farm forwards authentication requests to the shibboleth daemon running on a computer that does have outbound internet.
Because of this separation, I'd like to minimize the installation on each box in the web farm. I have the following questions:
Is it possible to xcopy-deploy Shibboleth to the web farm, rather than using the installer? If so, what are the minimum files in addition to the isapi_shib.dll?
If using the installer on each server in the web farm is necessary, what folders/files can be removed post-installation? (For instance, I see I can disable the "Shibboleth 2 Daemon" service...)
And by-the-way I am using using http://www.testshib.org for integration testing.
I'm developing some web site that run on IIS 7 and can connect to SQL server via php. The problem is I think its not safe because everyone that know my public IP address can freely access my site (the site is not for public, but I need it to be accessible to some people). How can I add security to this website of mine?
I have search for some type of security like authentication in IIS, but I don't know what should be used. Can I just add id and password like when we try to open page for configure router (192.168.0.1) .
You can easily disable anonymous authentication and enable basic authentication in IIS 7 using IIS manager.
Here is a Technet link and an SO post with details:
Is it a standalone server or do you run the IIS server on a desktop?
If your the only one who should access your site you could also use Intergrated windows authentication (IWA). IWA is a feature of the IIS Server, so if you wan't to use is you should enable it first.
I've developed a solution and tested it. It's uploaded to Azure using the convenient method of publishing XML file. Now I realize that it's supposed to be put in on-premise local server (it's an internal application not requiring access to the Internet).
When I go to the server, I use the RDP to access a system. In there, I execute a connection to another RDP. The second system is the one hosting both SQL Server and IIS where the application will reside.
Is it at all possible to construct such a publish XML? If so - how? If not - what should I request form the IT department to open/install on the innermost RDP so I can shove in my stuff by the oh-my-god-I'm-so-lazy press of a button?
You must install webdeploy on your host machine. With IIS and webdeploy installed you can use same publishing techniques as you did with Azure.
I think it goes without saying that you must have direct access to host. If it's on external network you have to open webdeploy's and IIS ports, if you do not want to open this externally I recommend VPN (maybe basic point-to-point) that will create direct line between your dev and host machine.
What are the permissions needed for running delegated deployments, using MSDeploy, targeting a Windows 2003 Server / IIS 6.0 ?
EDIT: this is a duplicate of ... How to allow non-admin user to deploy web applications on IIS 6 using web deploy
IIS6 can't be published to directly via Web Deploy, so you will need to use Web Deployment Agent. Once you have setup the agent, the endpoint address should look something like this:
http://myserver/MsDeployAgentService
Note this is not an HTTPS address and does not explicitly specify a port. Also, the account publishing to this endpoint must have admin rights on the server (nasty, but necessary). Finally, make sure the "Web Deployment Agent Service" is actually running because it's not set to start automatically by default.