Using a Library I found from Microsoft, I have been attempting (with C#) to provision email accounts for my users with Live#Edu and the library uses remote PowerShell sessions to do this. I have wrapped the PowerShell calls with a using() { } block that impersonates a local administrator account. When I run the code on my own development machine it works great and provisions the account on Live#Edu, yet when I run the same code on the production server I get an Access is Denied error from PowerShell.
What I just noticed is if I change the IIS Application Pool user on the server to my own domain account everything works fine on the production server, but leaving it as ApplicationPoolIdentity does not work. So it appears that even though in my code I impersonate a local administrator, those credentials are not being passed on to the PowerShell session. Oddly enough, when the scripts run on my own machine, also under ApplicationPoolIdentity, there is no problem and that leads me to believe that the script is actually running under my own account on my machine (and I am a local administrator).
I did have the code spit out the value of $env:username and it gave me the machine name and I was expecting it to give me the actual username it runs under since that is what I get when I type that command directly into a PowerShell window.
When logged in to the remote server interactively using the credentials that I have been impersonating in code, I can manually type all of the PowerShell cmdlts into a PowerShell window and they work fine.
I don't want to have my IIS Application Pool always running under an administrator account as that sees foolish so is there a way of running the PowerShell script as an administrator that goes further than the current impersonation that I am doing?
UPDATE:
There was an odd thing that happened that sees to work as a solution for me. After deploying my code to the server I created added a local administrator account. I then went to the IIS Application Pool and changed the owner from ApplicationPoolIdentity to the admin account I just created. After that the page would work fine to run the PowerShell script. I already knew this from before, but didn't want to have IIS using an admin account. I then proceeded to set the Application Pool back to ApplicationPoolIdentity and removed the Local Admin account and the page still works!? I restarted IIS, and the Web Server itself, and everything works. All I can think is that moving the Application Pool over to an Admin account changed some attribute in the App pool permanently. I have now put a modified question on ServerFault.
Turns out the issue had to do with the Load User Profile option in the IIS App Pool for my app being set to False on the server (False is the default for Windows Server 2008). After reading up on this property I am not entirely sure why this matters for my scenario, but that was the one setting different in IIS on my local machine from what the Web Server had. Now all the PowerShell calls work flawlessly on the server.
Related
Question edited to show some new screenshots of my attempt to give DefaultAppPool access to the database...(the rest of the question is the same, and unchanged):
The rest of the question, unchanged:
Database access was not a problem with the built-in IIS Express, because my program was running under the user logged into windows. I am new to Web Development.
With Windows Home, you are not allowed to use Windows Authentication--the option is not even present when you go to add\remove feature, and consensus is that you have to upgrade your OS for this to be available.
Hence, the program runs under the app pool account.
So I tried to go into SQL Server and give IIS APPPool\DefaultAppPool account access, but it would not let me.
So I went ahead and turned on impersonation, so that it will run under IUSR account, and I gave that account access to the database, as per screenshots.
But the program still crashes and reports that, "Login Failed..."
How do I run the program in IIS and not IIS Express?
As far as I know, there is no need to use impersonation to access the sql server. The reason why you get account not found error is you use the wrong application pool name.
If you type in the {yourcomputername}\DefaultAppPool, it is not regarded as the application pool identity.
You should use IIS AppPool\DefaultAppPool instead of the {yourcomputername}\DefaultAppPool.
Details, you could refer to below image:
We are using ASP.NET Identity 3.
Our users are randomly getting signed out automatically. To reproduce this issue, I tried application restart, all users signed out, even those who had checked Remember me.
It only happens in Production, works fine on development environment.
Update:
We have only one server in production.
You will need to configure data protection in the production server. I assume that in your local machine the website runs as a local user so the registry hives can be created and read. While if you run it as a user without a local profile (default IIS app pool user option), it may not have the permission/s to create or read the keys required. You'll need to run this provisioning script in that case.
Have a good read about their guide on Publishing to IIS. That step is documented there.
The production machine might be using multiple servers. In that case, the server to which a user first connects might not be the same server to which that user later connects. In that case, if you are using session IDs, you must keep user sessions in sync across servers.
I have a problem, and have scoured the web for a solution without luck. I therefor hope of a genius reads this and have useful answer to my problem.
I have a domain (“MyDomain”) and a server (“StandAloneServer”) outside “MyDomain”, but on the same physical network. On “StandAloneServer” there is a local user (“LocUsr”) that is used to run a service, and has rights to start and stop that service.
From a computer that resides inside “MyDomain”, I can access the “StandAloneServer” via RDP by using the IP address for the “StandAloneServer” and the credentials for “LocUsr”.
So far, so good - Now my problem occurs.
I would like to make a small program, that can be run on a computer that resides inside “MyDomain”, that can start and stop the service on “StandAloneServer” using the credentials of “LocUsr”. In this way a person with limited credentials and knowlagde of RDP and services can start and stop the service when needed.
All impersonation examples I can find builds on that the user to be impersonated is a member of “Mydomain” or that the program runs on the same computer as the local user – neither of this is true in my case.
How do I impersonate a local user that resides on a remote server, so that I can start and stop a service on the same remote server?
Try using psexec. This tool worked great for an application I was recently involved with for remotely restarting applications by impersonating the local user on a given pc.
Also WMI was a tool used in the project.
Here is an article on remote commands
Just remember that these tools are quite finicky and are unforgiving about syntax.
If you need a bit more, I would be happy to expand my answer
I'm trying to use a network path (create directory, write and read files) from a Web Service in ASP.NET.
Everything works fine from my office where the network path is in the same LAN of my laptop, but when I try to connect to the network path through a VPN, the creation of a directory fails with "Access to path is denied" error.
The strange thing is that from Windows Explorer I can perfectly access such path, given my VPN credentials, that I stored in Windows Credentials Wallet.
I also tried to set my IIS App Pool Identity to 'Network Service' but no luck.
Can you help me please?
Thank you very much
EDIT:
When I try to execute a statement like
Directory.CreateDirectory(#"\\my\network\path");
from a simple console application project in my Visual Studio 2010 it works perfectly and the directory is created.
The problem is when I hit such a statement inside the business logic of my web service that is running under local IIS (and which I'm connected to via "Attach Process..." debug tool in VS2010)
I may not have all the details of what you're asking straight, but if you're running this service via Visual Studio and VPN, take a look at this great article, at CodeBetter.
runas /netonly /user:domain\username “C:\ProgramFiles\Path\to\your\visualstudio”
I don't have the computer I have this on in front of me, but I recall that I created a batch file and ran it to start VS and Sql Server Management Studio, and it works like a charm.
If I've misunderstood the issue, sorry for the noise.
Sounds like when you are running locally, your local domain account is the context under which everything is being ran. When running the console app, it is still running under your user context since you initiated the application. When running in IIS, you are correct in that the app-pool account is being used, and the networkservice account has some pretty low privileges.
Instead of using a highly privileged account (such as yours), would impersonation solve your issue? Any work that needs to be done over the VPN can "wrapped" in a context the appropriate permissions. Here is another SO article on using impersonation, which I have implemented for related things:
How do you do Impersonation in .NET?
See Matt Johnson's answer where he creates a custom Impersonation class. Use that in a using block, then do your network stuff. It uses the advapi32.dll with p/invoke to do this kind of user account voodoo. He put together a NuGet package as well which may save you some time:
https://www.nuget.org/packages/SimpleImpersonation
I have a .net/C# application when launched on a test server running VMWARE / Windows Server 2008, receives a USERPROFILE Environment Variable pointing to C:\windows\system32\config\systemprofile, but other applications seemingly built in a similar fashion inhert the correct value of C:\Users\{username}.
A slight twist - the application receives the correct value when run locally on my development machine. So I'm thinking this is a profile/registry issue with some combination of setting in my app.
The issues is manifested when you attempt to open an OpenFileDialog or similar. You get the exception "Location is not available: C:\Windows\system32\config\systemprofile\Desktop refers to a location that is unavailable..."
Any ideas?
UPDATE: The application is WPF running web services against IIS via WCF. Locally in development I am using IISExpress. I've found that after touching the WCF services in the client, the application inherits the APPDATA and USERPROFILE of the IIS AppPool the services are running under. If I adjust the AppPool values to use my user account instead of ApplicationPoolDefault and set LoadUserProfile = true - things work. Obviously this is a bad thing. As an alternative, I cache off the environment variables when the WPF app runs, and after it initially connects to WCF, I reset the variables. This appears to get around the issue but I'd like to solve it a better way but I have no idea what is influencing this behavior in WCF and my IIS Services.
It might have to deal with what account the web app is running under in IIS. You can change it from the default "Network Service" account to an actual user account.