How to use environment variable with IIS user - web-services

I have a WCF service that runs a .bat file. It works on my local system, but I have a problem with running it on the server (Windows server 2012 r2).
I've defined the ANT_HOME variable to server's environment variables and I've added %ANT_HOME%\bin to Path variable.
When I write "ant" to CMD on the server it works! But when I call the wcf service from somewhere, it doesn't work.
I found the following error in the log files:
'ant' is not recognized as an internal or external command,
operable program or batch file.
According to this log, I understand that IIS user cannot use the ANT_HOME variable which is already defined.
What I have tried so far:
identity impersonate
giving full permission to IIS user

What version of IIS are you running? If you are running a version where you can create a separate Application Pool for your service then do so and give this Application Pool an identity that has the right PATH or defines ANT_HOME for that user. I always like adding a Ping type method to all my services so I can ask the service who it is running as and where it is running. It is great for troubleshooting and testing WCF services.

Related

Click once application to connect to remote server

I have added this question on ServerFault but no one replied.
I have a .net application which calls a webservice deployed on my local windows server 2012 on IIS, and the sql server database resides on that server too. All employees connect to the same service and DB since we're all on the same domain, and I publish the app and webservice to the server through visual studio (2012).
Now I need to make employees access this application when they are outside the company's network, so I deployed the webservice on IIS on one of our remote windows 2012 servers, I created a public shared folder in my remote server and added to app webservice files to it and in visual studio I changed the publish method to web deploy and filled in the information as below:
Server: https://x.x.x.x/
Site Name: https://x.x.x.x/PublicFolder
Destication URL: https://x.x.x.x/PublicFolder/Application
When I click Validate Connection, it fails with the following message:
Could not connect to the remote computer ("x.x.x.x"). on the remote
computer make sure that Web Deploy is installed and that the required
process ("Web Management Service") is started. Learn more at:
http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_DESTINATION_NOT_REACHABLE.
Unable to connect to the remote server
Note that I tried to replace https with http and I got another error:
Could not connect to the remote computer ("x.x.x.x"). on the remote
computer make sure that Web Deploy is installed and that the required
process ("Web Management Service") is started. Learn more at:
http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_USER_NOT_ADMIN.
the remote server returned an error: (401)Unauthorized
I went to the previous link and I did what they suggested:
Create a separate user group MSDepSvcUsers on remote computer.
Create an local account A on both local & remote computer.
Add A to MSDepSvcUsers on remote computer.
Use account A to publish, this will allow you to publish without
needing to use built-in admin account.
but the same error (NOT_ADMIN) remained
UPDATE: I found another possible solution:
Add/modify windows registery key
“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\”
and set it “1”.
After I added this registry key, the error changed to:
site 'http:' does not exist ... #ERROR_SITE_DOES_NOT_EXIST
So now if I put wrong credentials, I get the unauthorized error, if I use correct credentials I get side does not exist error.
What should I do?
It worked!!
I mean the connection, it's now validated, all I had to do is change site name from "http://x.x.x.x/PublicFolder" to "Default Web Site\SiteName" !!
This was really confusing, finally got it!

change port in wso2 sample

I am executing sample programm of wso2. I have installed wso2is on different machine and tomcat is on local machine. I have changed localhost:9443 to my ipaddress(eg 192.168.1.xxx) from travelocity.properties and avi.properties. But when I execute sample from click on login button it always redirecting me localhost and giving error.
I think you need to try the following,
While the tomcat is running,
Open the travelocity.war with an archive manager
Edit the travelocity.properties file,
update SAML2.IdPURL value
eg : SAML2.IdPURL=https://192.168.1.7:9443/samlsso
Save and update the travelocity.com web app
Restart the tomcat server just to be sure (You don't really have to do this since tomcat hot deploys once it detects a change)
I tried this locally and it redirected me to the IP address I put in SAML2.IdpURL. Clearly the problem seems to be a configuration error on the travelocity.com web app side :)
You need to change <HostName> and <MgtHostName> attributes at repository/conf/carbon.xml of your Identity Server with your IP address. By default they are set as localhost, so when logging it will be redirected to location specified there.

Error registering REST service in ColdFusion 10

I'm having a problem registering a REST web service in the ColdFusion Administrator. I'm using ColdFusion 10 on a Windows server, and the error I get after trying to register a REST web service is:
Error registering REST service. Please ensure that you have entered a proper mapping and path.
Application CA could not be initialized.
Reason: class "com.sun.xml.bind.Util"'s signer information does not match signer information of other classes in the same package
class "com.sun.xml.bind.Util"'s signer information does not match signer information of other classes in the same package
I've tried registering a service on both a remote CF instance as well as my local instance. Locally I've tried just a real basic service - basically one CFC in an application all by itself, but still get the error. I am putting in both the Root path and the Service Mapping, as I do not have an Application.cfc in the application.
Any ideas?
This problem was caused by some custom JARs I was referencing in the ColdFusion Class Path in the Java and JVM settings in the CF Admin utility. I removed the references to the JARs and restarted the CF instance. Then I was able to successfully add the REST WS. I then re-added the JARs in the class path and restarted the instance. The proper solution is probably to recompile those JARs with the same certificate, but if you don't have access to the source code, this may be the only workaround.

SOAP client in IIS cannot access web services in Tomcat

I have IIS (localhost:443) and Tomcat (localhost:8080) both running on my local machine. The Tomcat contains Java web services and I can remotely debug it in Eclipse IDE. I have an application installed in my IIS and when I access the page of that application, it requests a web service in Tomcat.
The problem is that when I try to load the page (the one deployed in IIS), my Eclipse won't go to the break point, meaning no request was retrieved on the Tomcat side.
But when I try to execute a request using SoapUI, Tomcat receives it and it enters my breakpoint in Eclipse. (meaning that the web services are accessible)
I cannot debug the application in IIS so I cannot determine why it can't call the web service.
Do I need to setup Windows Firewall for it? I'm just running those apps in my local machine.
Any ideas?
I got it working. My problem was permission issues in c:\windows\temp directory. I found my answer here http://nishantrana.wordpress.com/2008/02/06/unable-to-generate-a-temporary-class-result1-error-cs2001-source-file-cwindowstempfilenamecs-could-not-be-found-error-cs2008-no-inputs-specified/

Windows Integrated Authentication fails ONLY if web svcs client is on same machine as IIS server

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.