I'm deploying using VS2017, and MSdeploy WMSVC seems to be overwriting my IIS site settings being deployed to.
The site settings, in IIS manager, has IIS Authentication panel, Anonymous Authentication Credentials set as Application Pool Identity.
After deployment, all requests get 401.3 unauthorized error, because the Anonymous Authentication Credentials setting gets set to user:
Clearly this is getting overwritten because of a clash between SERVER specific settings and DEVELOPMENT specific settings.
In any MSDeploy scenario, what strategy can we use to prevent the target IIS settings from getting walked on by Development server settings? My first thought is, IIS first looks for site.config which would contain system.webService, then web.config updates/overrides any of those, ie <handler remove key="xxx" /> and so forth. Is this only solvable by XDT transforms?
In my opinion, the best solution to solve this is using web.config XDT transforms.
Since web.config file will also be published when deploy to the IIS server. If you have set the anonymousAuthentication setting in the web.config, it will use web.config setting instead of your server default setting.
Here is another solution(It will show the error page):
If you don't want to let the web.config to modify the default IIS setting, you could modify the feature delegation to disable override the setting from web.config.
You could find it from the IIS management feature:
Select read only:
Notice:
If you modify the Anonymous Authentication from the web.config. You will face below error:
Related
I need help regarding spring security cookie path.
We have 2 web applications running in tomcat, app1 and app2. Both using the same domain, like www.company.com/app1 and www.company.com/app2 . Everything working fine and perfectly in tomcat.
But when we migrate to WebSphere, it started give issue. The issue is when a user login to app1, app2 cookie got overwritten because WebSphere storing the cookie in root path / and both applications using the same domain will overwrite another application cookie. In tomcat it storing in application path like /app1 and /app2 so no problem.
I am able to configure the WebSphere to make it work by configuring the application cookie path. Please see https://serverfault.com/questions/461518/websphere-jsessionid-cookie-overwrite-between-two-apps-on-the-same-domain-diffe for how to configure in WebSphere.
Now my question is, I don’t want to configure this in WebSphere. How can I do this in application level like configure the Spring Security xml or any other place. We want to make this in application level is because it will more portable and behave same in all containers.
I have try to configure the web.xml by adding the following but it not working.
<session-config>
<session-timeout>720</session-timeout>
<cookie-config>
<name>JSESSIONID</name>
<path>/app1</path>
<http-only>true</http-only>
<secure>true</secure>
</cookie-config>
</session-config>
I am using the desktop version of Postman at a client site to test an API. However, I am unable to access any SSL sites in Postman, such as the Git Hib API: https://api.github.com/users/karlgjertsen
However, I can make the same API call through Chrome, so this is Postman specific.
I assume it is down to proxy settings, but I am not sure how to view or update these in Postman. Has anyone had any experienced something similar?
I turned OFF both Global Proxy Configuration and Use System Proxy in Settings->Proxy tab in Postman and it started to work.
This solved my issue :
The option "Respect HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment variables." was selected by default in the proxy settings. I turned off this option and it worked for me.
Follow these steps on postman -
Go to file=>Settings => Proxy (Tab) and uncheck the "Use System Proxy" checkbox. That should work
Posting as the other solutions presented in this thread did not work in our corporate environment. We have a proxy configured on the network which uses Windows Default Credentials (username and password) for authentication. For whatever reason the browser knows how to pass these details with each request but postman does not by default.
Solution was to update the Default Proxy Configuration under settings -> proxy -> Default Proxy Configuration -> Tick 'This proxy requires authentication' then enter Windows Username and Password. Leave Use the system proxy and Add a custom proxy configuration settings disabled.
From the Windows start menu go to Change proxy settings and configure the host and port there.
This turned out to be a local security policy that was applied to the machine in use. The local SSL proxy had a policy applied and it would not allow me to make a secure connection unless it was through a web browser.
I am getting below exception while deploying my application on WebSphere Application Server 8.5.5
java.lang.RuntimeException: SRVE8111E: The application, MyEAR, is trying to modify a cookie which matches a pattern in the restricted programmatic session cookies list [domain=*, name=JSESSIONID, path=/].
I found that if I remove below entry from my web.xml [session-config], then no error is shown with deployment and every things works fine.
<cookie-config>
<http-only>true</http-only>
</cookie-config>
<tracking-mode>COOKIE</tracking-mode>
The same ear is able to deploy and run perfectly with JBOSS and WebLogic server.
Please let me know what configuration change I have to do in which xml file to overcome this issue.
My application has application.xml, jboss-deployment-structure.xml and weblogic-application.xml.
Thanks in advance.
If you want the server to allow you to modify the session cookie it's using for HTTP Sessions, you can remove the cookie from Security > Global security > Programmatic session cookie configuration. in the WAS Admin Console.
But you shouldn't modify the session cookie.
I had the same issue in Websphere App Server and this was fixed after I changed the cookie path to the context root instead of the path =/. You could try the same.
Well, removing them from Global security is a solution, but this will impact other application also.
How I fixed this.
Changed the name of sessionId from default jsessionid to something else.
I have a web service running under IIS7 on a server with a host header set so that it receives requests made to http://myserver1.mydomain.com.
I've set Windows INtegrated Authentication to Enabled and everything else (basic, anonymous, etc) to Disabled.
I'm testing the web service using a powershell script, and it works fine when I run it from my workstation against http://myserver1.mydomain.com
However, when I run the same exact script on the IIS server itself, I get a 401-Unauthorized message.
In addition, I've tried installing the web service on a second server, myserver2.mydomain.com. Again I can call my test script fine from BOTH my workstation and from myserver1.
So it seems the only issue is when the client is on the same box as the web server itself - somehow the windows credentials are not being passed or recognized.
I tried playing with IE settings on myserver1 (checked and unchecked 'Enable Windows Integrated Authentication', and added the URL to Local Sites). That did not seem to have an effect.
When I look at the IIS logs, I see the 401 unauthorized line but very little other information.
I see basically the same behavior when testing with IE (v9) - works from my workstation but not when IE is running on the IIS server.
I found the answer after several hours:
By default, there is something called a LoopbackCheck which will reject windows authentication if the host header used for the site does not match the local host's name. This behavior will only be seen when the client is on the local host. The check is there to defeat possible reflection attacks.
More details here:
http://support.microsoft.com/kb/896861
The kb item discusses ways to disable the Loopback check, but I ended up just switching from using host headers to ports to distinguish the different sites on the IIS server.
Thanks to those who gave assistance.
Try checking the actual credential that is being passed when you are running on the server itself. Often times you will be running on some system account that doesn't have access to the resource in question.
For example, on your box your credentials are running as...
MYDOMAIN\MYNAME
and the server will be something like...
SYSTEM\SYSTEM_ACCOUNT
and so this will fail because 'SYSTEM\SYSTEM_ACCOUNT' doesn't have credentials.
If this is the case, you can fix the problem in one of two ways.
Give 'SYSTEM\SYSTEM_ACCOUNT' access to the resource in question. Most people would avoid this strategy due to security concerns (which is why the account has no access in the first place).
Impersonate, or change the credentials of the client manually to something that does have access to the resource, 'MYDOMAIN\MYNAME' for example. This is what most people would probably go with, including myself.
I have a FinalBuilder project where I deploy an ASP.Net website to a remote folder, configured as a website in IIS.
As part of my build script, I want to use the FinalBuilder action HTTP Get File to help determine whether my deployment was succesful.
I'm having difficulty, because the website is configured (under IIS 6) to use Integrated Windows Authentication, and anonymous access is not enabled.
Now the HTTP Get File action, has only a handful of properties, one of which is a security section, containing a UserName and Password. Great I thought! I can just put some valid credentials in there, which FinalBuilder will impersonate, whilst retrieving my file.
It turns out I was mistaken. I receive the following error:
Error retrieving url : Socket Error # 10061
Connection refused.
If I run the action without setting the Security Username and Password, I get the following error:
Error retrieving url : HTTP/1.1 401 Unauthorized Response Code : 401
Here are some facts to help with the context of my problem.
I'm running FinalBuilder 6 Professional, upon a Windows Server 2003 installation, and deploying my ASP.Net website to a remote IIS6 server within our corporate LAN.
If I configure IIS on the remote server to allow Anonymous access, I can run the HTTP Get File action without error. However, running this particular site with anon access is not acceptable in our situation.
Can anyone help suggest a workaround?
For a definitive answer, I think the Finalbuilder Forum is probably your best bet.
My guess, though, is that the HTTP library used by FB doesn't support Windows authentication, and is failing because no common authentication method can be negotiated. Since HTTPS isn't supported either by the 'HTTP Get File action', the possible workaround of allowing basic authentication on your site isn't a good idea, as you would be passing credentials over the network in plain text.
The only remaining workaround I can think of (other than waiting for a future FB release), is creating your own FB action to retrieve the file. Using the .NET Framework System.Net.WebClient, that should be trivial. Just start with a standalone EXE to make sure everything works, then refactor it into a 'real' action using FinalBuilder Action Studio (if that's even required: spawning an external EXE may work just fine in your case).