I am calling a web service application (.asmx) running in a virtual directory on an IIS 7.5 (for development purposes I only have IIS 5.1 but am hoping for some help anyway). Calling my ws when running from within VS2010 System.Security.Principal.WindowsIdentity.GetCurrent().Name returns domain\windows user but when I call it through the virtual directory I get machine name\ASPNET.
For some reason is not allowed in the web.config on the final environment. The virtual directory has Integrated Windows authentication only.
Can anyone shed some light on how to get the current users windows username under the circumstances described?
Thanks in advance...
./CJ
Was allowed to use impersonation after all... now it all works
Related
We are encountering Kerberos and/or NTLM authentication failures in custom application packages orinally designed for Windows 7 using the WISE packaging Installer. On Windows 7 they work fine but they now fail on Windows 10. They fail both during installations on Windows 10 using the Microsoft SCCM tool, and they fail specifically when using Kerberos authentication to an SMB Share on the network durign the installation process. We can see inside the network trace that the client application fails over to NTLM from Kerberos durign the authentcation transaction. We are unsure why. We have a large scale Active Directory environment. Because the WISE package is comiled we cannot look into it. On successful Windows 7 machines, it appears the computer requires access to the Share while the package is being executed and the loggged-in user must have read and execute access on the SMB Share. We are able to access the same SMB Share using the Windows 7 system account but not when using the Windows 10 system account. Very odd! Is this a code issue inside the package? This may be important: The SMB share is using an DNS alias, not sure if this makes any difference. The real name of the host is different. When using the real name of the host instead of the alias the access issue appears to be resolved.
The network share wouldn't happen to be hosted by a non-Windows server by any chance, would it? If so, see if this article applies:
SMB file server share access is unsuccessful through DNS CNAME alias
Basically there was a change in the security model of Windows 10. Windows 10 by default won't request a Kerberos ticket for a DNS alias, but Windows 7 will. The SMB server is basically saying since you're not using my actual name (as shown by the service ticket), I won't allow the connection. Create a new SPN using the name that the successful Windows 7 machines are connecting with, but in SPN form. For example, if a Windows 7 is using something like this:
\servername.domain.com\sharename
..then find that name of the AD computer object representing the host and add a secondary SPN to that AD object like so:
HOST/servername.domain.com
I have a solution which basically contains three components:
• WCF Service that is hosted locally having a back-end SQL Server Express DB and this WCF service is hosted from a Windows Service
• A console application
• A Windows Store Application
This is what they are meant to do:
• WCF service his hosted locally and is used by the console app and the store app for communicating with the database
• The console app adds an image for processing to the database by contacting the WCF service
• The store app will at regular time look for unprocessed images in database via the WCF service and will process them
Now, the difficulty is:
• The WCF service is hosted successfully and is working absolutely fine and I can check that by hitting its URL http://localhost:8081/XYZ
• The console app is also able to submit images to the WCF service and add their local paths to the database
• The store app however always throws the EndpointNotFoundException when accessing the service at that same localhost path
What have I tried:
• I have tried almost everything from searching through stackoverflow to googling and haven't found a solution yet
• I was thinking that it might be a port issue and so I turned off the firewall to check this, but it did not work, and the store app kept throwing the EndpointNotFoundException
What have worked:
• The complete set-up has, however, worked perfectly on my machine. It is strange that its not working on my client's Windows 8 machine.
Point to be noted:
• The complete solution has been developed in Visual Studio 2013 and the App is for Windows 8.1
• I am not sure, but it seems my client has a Windows 8 machine and we are installing the app on that. (Possibly, that might be a problem. But I'll check)
If there is any help someone could provide me, I'll be really greatful. Thanks in advance!
This is expected. Windows Store apps cannot connect back to the local system in production. This loopback prohibition is disabled for debugging.
See How to enable loopback and troubleshoot network isolation
If your app is to be side-loaded rather than deployed through the store then see Using network loopback in side-loaded Windows Store apps
I have a service account in windows 2008 application server to achieve word to pdf conversion. 3-4 days back everything was working fine and all of a sudden the functionality shut down.
I dig into details. The information I got is as below:
When I log in with that service account and try to achieve that functionality, I'm able to do it.
When I log off with service account and try to achieve that functionality, I'm not able to do it.
Conclusion: Somehow the service account gets inactive.
The problem is very weird and i tried each and every combination of permission in Dcom config. Any help in right direction is highly appreciated. Thank a ton in advance.
You already tried to check the Password Never Expires and User Cannot Change The Password options in Active Directory Users and Computers?
Also, try to re-install the application on the machine. If the application cannot run as Windows Service, use the SRVANY.EXE utility to register you application.
We have a WCF service hosted in IIS that currently calls a VB6 DLL to do part of its job. This works fine, but we can't deploy the service to a 64-bit target environment without configuring IIS to run it in a 32-bit worker process.
I am currently investigating ways around that restriction. Porting the VB6 DLL to .NET is not possible for various reasons, so I created an ActiveX EXE wrapper around the DLL in VB6, so that the service can run in 64-bit and the VB6 parts in 32-bit.
When I tested the service I got this error:
Type: System.UnauthorizedAccessException
Message: Retrieving the COM class factory for component with CLSID {9AE7303B-D159-43F6-B1A5-52D297581820} failed due to the following error: 80070005.
After some Googling I found that this is due to either:
Calling an MS Office component
DCOM permissions not being configured
NTFS file permissions not allowing read/exec access to the IIS worker process identity (ASPNET in my environment)
Of these:
Definitely not applicable
Also not applicable; I am not hosting the EXE in DCOM or COM+, just a simple COM out-of-process activation
This looks likely; however, I checked the permissions, and NTFS reports that the Users group (which ASPNET is a member of) does indeed have read/exec access to the file
I tried calling the EXE from a unit test fixture, which is executed in my admin-level account rather than the IIS worker process account, and it worked fine, so the error is definitely something to do with permissions. I'm not sure what to do next. Can anyone suggest things I can check?
My test environment is Windows XP / IIS 5.1
UPDATE:
The IIS virtual directory is configured for Anonymous+Windows access; the WCF service uses only Anonymous authentication, the Windows authentication is for the VS debugger. Task Manager reports that the aspnet_wp.exe process is definitely running in the ASPNET account.
I explicitly granted Read and Execute access to the ASPNET and IUSR_<machine> accounts on all the COM exes and dlls involved. This made no difference.
I explicitly granted Local Launch and Local Activation access to the ASPNET and IUSR_<machine> accounts on the relevant interfaces in the DCOM configuration. This made no difference either.
As I see it I have 3 options:
Keep trying to get this working somehow.
Go the whole hog and host the EXE in COM+.
Give up. Tell users that the WCF service must be configured to run in a 32-bit app pool on 64-bit Windows.
Your error is an Unauthorized access exception. Therefore, the problem is probably rights related.
You could check what the security context of the 32bit worker process is.
Also check your event log, they may be information there about what account is being used.
Greetings,
we have to following problem.
Our application is deployed using ClickOnce. Everything is running fine and application is able to connect to the wcf service. The problem occurs when application is installed on FRESH XP machine without .net Framework and Windows Installater (that were selected in ClickOnce prerequities).
Application downloads .NET Framework 3.5SP1 and windows installer but then it cannot connect the the server. Reboot after install does not help.
The strange is that this application has been installed on 10 xp machines and 4 of them can connect to the service without a problem
Are there any dlls referenced in your application? You might want to check them (Under project's Properties\Publish tab\Application Files button) see if you missed to include the needed dlls or files.
alt text http://www.freeimagehosting.net/uploads/e8ff221e20.jpg
We ran into this and were forced to reinstall .net on some machines no idea why though.
This is a shot in the dark but have you tried depends.exe and see if it can profile what is happening.
Also Take a look at this blog and get a crash dump and see if you can use it to at least tell you what is complaining the loudest.
What do you mean when you say 'cannot connect to the server'?
a. The machine cannot connect to the install location and therefore the clickone app is not installed?
b. The app installs (along with the pre-requisites) and starts fine. Then it is unable to connect/communicate with your WCF services.
I presume (b) I just wanted to clarify.
What happens when you ping the machine the services are on from one of the failed install machines? Also what happens when you put the service url into a browser on one of the failed install machines? Can you see the wsdl?
Obviously your deployment package works because it works on those other machines (I assume it IS the same package all machines are installing?), therefore I doubt you are missing any dll's as a ClickOnce app should include all dll's it needs (sometimes you do need to tell ClickOnce explicitly to include).
Last question is, when the app tries to call the service, exactly what exception is it getting back?
I just remembered something which has caught me out in the past with some machines being unable to connect but others can...especially 'new' machines.
Check this file:- C:\WINDOWS\system32\drivers\etc\hosts
Check the contents on a machine that works and one that doesn't. We have some IP to machine name mapping going on that on new machines is not set and so the new machines cannot find the servers.