I have a need to do automated testing of a configuration of WCF bindings. I wrote a test that, in it setup, picks a random port number and binds to it with a WSHttpBinding. The test runs a ServiceHost for the duration of its execution and then shuts it down. This works, but then when the build agents try to run the test, I get this error:
System.Exception: Unable to set up service host ---> System.ServiceModel.AddressAccessDeniedException: HTTP could not register URL http://+:52361/Test/. Your process does not have access rights to this namespace (see http://go.microsoft.com/fwlink/?LinkId=70353 for details). ---> System.Net.HttpListenerException: Access is denied
Is there any way to work around this? Can this "urlacl" mechanism be disabled??
UPDATE: This was a wild goose chase, as it turns out. This wasn't the error that was happening on the build agents. I flubbed it when gathering that information. Turns out the build agents are running elevated and don't run into the urlacl problem. The actual problem I was encountering was that a NuGet reference somehow hadn't had its corresponding assembly reference added to the .csproj file. How the tests worked locally, I don't know!
The error is "The process does not have permission to access this namespace".
You can try the following methods.
Make Test public
Run the service as administrator
Run the command prompt as administrator, add URL to ACL netsh http add urlacl url=
https://www.codeproject.com/Questions/441371/When-Hosting-the-WCF-service-i-got-exception
WCF ServiceHost access rights
Related
When I used the workflow feature of NebulaGraph Explorer, the task reported the following error:
handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain?
How to resolve the error?
You need to reconfigure the permissions to 744 on the folder .ssh and 600 on the file .ssh/authorized_keys.
In the workflow/dag controller, it's leveraging SSH to do some of the RPC call(dirty but works), which requires ssh key based authentication.
To debug this, we just need to login to the workflow machine and try manually perform the ssh login with exactly the same user and host(even when it calls itself, SSH is still needed here), the tips are to add -vvv arguments to show in the verbose mode where it could go wrong as #lisa liu posted, it could be permission issues of the corresponding files or other cipher handshake issues.
I''m trying to get log output (Console.WriteLine(..)) in my Docker logs, but I'm getting zero avail.
I've tried:
Console.WriteLine(..)
Trace.WriteLine(..)
Flushing the console, flushing the trace.
I can see these outputs in a VS output window when I'm debugging, so they go somoewhere.
I'm on windows Container, using microsoft/aspnet:4.7.1-windowsservercore-1709 and net4.7
These are the logs I get on container start
docker logs -f exportapi
ERROR ( message:Cannot find requested collection element. )
Applied configuration changes to section "system.applicationHost/applicationPools" for "MACHINE/WEBROOT/APPHOST" at configuration commit path "MACHINE/WEBROOT/APPHOST"
You have many good lateral options, like self-contained/server-contained executables (eg. Dotnet Core using microsoft/dotnet:runtime would proxy Console.WriteLine by default off the dotnet new web scaffold). Zero-configuration STDOUT logging has never been a common approach on IIS, but these modern options adopt it as best practice (logging should be a transparent backing service).
If you want or need a chain of three programs/assemblies to get your web service up (ServiceMonitor, W3SVC, and finally your assembly), then you need something like this: https://blog.sixeyed.com/relay-iis-log-entries-to-read-them-in-docker/
Overriding the entrypoint to tail more logs than the image does by default is unfortunately a common hack (not just in Microsoft land). So, in your case, I believe you need at least a trace listener config to emit Trace.WriteLine, and then the above approach to emit it: https://learn.microsoft.com/en-us/dotnet/framework/debug-trace-profile/how-to-create-and-initialize-trace-listeners
All, According the WAS.The document says the worker process is managed by WAS .
But I found when typing w3wp /? There is a debug flag.
-debug
This option launches a worker process using the default
application host config file. By default, it will use
site id 1.
What does mean start worker process in debug mode? In what case we want to start a work process with debug option ? thanks.
Added
I didn't known why I got a exception when run w3wp.exe -debug.
ERROR: There has been an error during processing of this command.
Please check the event log and see if any errors or warnings have been
logged.
When I checked the log. It looks like:
The World Wide Web Publishing Service failed to set the application
pool for the application '/xxxx' in site '1'. The data field contains
the error number.
According to http://support.microsoft.com/kb/183480 it switches the security context of the running user which is not its normal mode of operation - I suppose this would make it easier to then attach a debugger and other utilities.
Having some issues with MSDeploy on a windows server 2008 box, the internal service is throwing a 500 error without putting anything in the server's event logs.
I'm attempting to setup automated deployments using MSBuild/TeamCity/MSDeploy, and this is basically the current halting point, has anyone come across this issue before?
Thanks, Ed
To find out why you are getting this error you should enable logging.
First, enable Failed Request Tracing for the web management service. You can see how to do this by referring to the "Optional: Set Up Tracing" section of this article:
http://learn.iis.net/page.aspx/984/configure-web-deploy/
The "frebs" can be found in:
C:\inetpub\logs\wmsvc\TracingLogFiles\W3SVC1
Open each of the frXXXXXX.xml files with IE and it'll use the freb.xsl transform to generate a nice report.
Don't delete freb.xsl when you're done, it doesn't always get recreated.
Then turn on logging for the web management service:
http://technet.microsoft.com/en-us/library/ff729437(WS.10).aspx
You want to have the following registry entry configured:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IIS Extensions\MSDeploy\1]
"EnabledTraceLevel"=dword:00000002
"EnabledTraceSources"=dword:000001ff
You can fiddle with the tracing levels/sources to increase and decrease the verbosity of the logs.
As per the article the management service logs are written to:
%WINDIR%\ServiceProfiles\LocalService\AppData\Local\Temp\WMSvc.log
The Goal
I would like only a certain group of users (who are in an Active Directory group composed of users from two domains) to be able to execute a web script, in http://www.site.org/protected, after being challenged for authentication.
The Setup
Windows 2008, IIS 7. User Account Access has been disabled, as it is a pain and sometimes causes perfectly reasonable things to fail. The server is part of a domain I will called LITTLEDOMAIN. We have a trust with BIGDOMAIN.
I have a group, called "LITTLEDOMAIN\can-use-this." In that group are the members LITTLEDOMAIN\me and BIGDOMAIN\me. I did the bit in Active Directory where the server now allows that group to authenticate against another domain (BIGDOMAIN).
The application pool for www.site.org runs as "NetworkService."
The dirctory has the user SYSTEM, the user NETWORK SERVICE, the group Enterprise Admins, and the group LITTLEDOMAIN\can-use-this with at least Read and Execute permissions.
In IIS 7, I have disabled all forms of authentication for that directory but Windows Authentication. As to Authorization Rules, All Users are Allowed.
The Error
When I use, say, FireFox, visit the URL http://www.site.org/protected, and am presented with a challenge, I can enter the username LITTLEDOMAIN\me and my password, then see the minimal HTML generated by my very simple Python script, which is basically a "Hello, World" with a timestamp thrown in so I can make sure caching of the page does not occur. If I use BIGDOMAIN\me, I receive an HTTP 500 error.
Diagnostics Performed
The passwords for LITTLEDOMAIN\me and BIGDOMAIN\me are the same; this has been checked.
I look in the HTTP logs and see the "500 0 267" for "sc-status sc-substatus sc-win32-status" in the HTTP logs. A "net helpmsg 267" from the command line gives me "The directory name is invalid."
I added Failed Request Tracing Rules and see the same unhelpful message in the XML: "The directory name is invalid. (0x8007010b)"
I have turned on file object auditing in the policy for that server, then set the auditing for the directory and the files within it to have all failures for "Everyone," but nothing shows up in the Security section of Event Viewer. I was able to cause other failures, so I know that failure auditing is working. This suggests that the system is not even getting to the point where the file is being accessed.
I gave, temporarily, the group LITTLEDOMAIN\can-use-this full control over the C:\TEMP directory, on the off chance this was in use. I recycled the application pool. The same error occurs. I tried this in C:\Windows\Temp as well, to no avail.
The Question
How can I find out "well, WHICH directory name is invalid?" It's pretty obvious that something, somewhere along the line, wants permissions for BIGDOMAIN, but I cannot figure out where.
The missing component, in addition to an audit policy and Failed Request Tracing, is Process Monitor. Not Process Explorer, but Process Monitor.
Run Process Monitor for three or so seconds, just long enough to get your request in, and have it fail. Use Failed Request Tracing to get the process ID that failed. Use Process Monitor's filter to show only events where the process ID appears -- you can then see where it fails.
Then set auditing on that directory to see what account is being used.
It appears that IIS 7 is returning to the root of the webserver when looking at a protected subdirectory. Odd.