I've been experimenting with Service Bus for Windows Server.
First some information about my environment.
I have two Windows 7 boxes (let's call them Host and Client). They both belong to a workgroup (no domain). Each machine has two user accounts (let's call them Admin and User) and the passwords match. On Host the Admin account is disabled and User is a member of the Administrators group. Service Bus for Windows Server is installed on Host. It was installed by the User account. The service runs under the User account credentials and User is listed as the ManageUser for the ServiceBusDefaultNamespace.
I've managed to get a simple Sender and Receiver working (hacked from the Azure Service Bus examples) when I run them both on the same machine under the same account that Service Bus was installed.
Then I tried copying the Sender to Client and running it. I had some problems with certificates but I've gotten past those. If I log onto Client as User the sender works. If I log onto Client as Admin the sender gives me a (401) Unauthorized. If I enable the Admin account on Host, then the Sender works.
All of the above makes a certain amount of sense. Host is trying to authenticate the request and when it finds the corresponding Admin account disabled it denies the request but it seems to create a slight inconvenience in that it requires me to have active accounts on all machines.
After a bit more digging, it seemed like I should be able to specify the account. When creating the MessagingFactory I'm creating a TokenProvider, and the TokenProvider allows me to specify a different set of credentials.
MessagingFactorySettings mfSettings = new MessagingFactorySettings()
{
TokenProvider = TokenProvider.CreateWindowsTokenProvider(
new List<Uri>() { rootAddressManagement },
new NetworkCredential( "Host\\User", "<User's Password>" ) )
};
But I still get the 401.
I guess I'm trying to figure out how to run (potentially) multiple Senders on different machines without requiring every account that a Sender might run under having an active account on the Host machine. Even in a domain-based environment it seems I'd run into this issue if the domain account under which the sender is running doesn't have privileges to access the host machine.
For workgroup machines, when specifying the network credential, don't add the host name, only the user. That should let your request be properly authenticated:
MessagingFactorySettings mfSettings = new MessagingFactorySettings()
{
TokenProvider = TokenProvider.CreateWindowsTokenProvider(
new List<Uri>() { rootAddressManagement },
new NetworkCredential( "User", "<User's Password>" ) )
};
This other thread has more information on the setup, if you still run into problems.
Related
I have a .Net Core 2.0 application that I host in IIS 7.
With IIS Express the application works fine and I'm able to connect to the database successfully. With IIS I get this error:
Cannot open database "Books" requested by the login. The login failed. Login failed for user 'DOMAINNAME\PCNAME$'.
My connectionString in appsettings.production.json file looks like this :
"ConnectionStrings": {
"BooksDatabase": "Server=PCNAME\\SQLEXPRESS;Database=Books;user id=iisAccess;password=iisPassword;Trusted_Connection=True;ConnectRetryCount=0;MultipleActiveResultSets=true"
};
What am I doing wrong and why does it say that the "login failed for 'DOMAINNAME\PCNAME$'" when I put the credentials user id=iisAccess;password=iisPassword; in my JSON file?
You are asking for Windows Authentication:
Trusted_Connection=True
Remove this part of the connection string and give it another try.
The reason for the error goes along these lines:
IISExpress runs as a normal process in your logon session. So it runs with your Windows Credentials. When your app is running inside IISExpress it is actually running under your credential, and when you connect to the database using Windows Authentication, is your login that SQL Server will receive.
The full IIS on the other hand runs as a service under a different session and a different user account. There are the application pools that also play a part and run under yet another account. But the main thing is that those default IIS accounts are local accounts, so they have no "visibility" to another computers. Hence when your app tries to connect to SQL Server, SQL "sees" the machine account, which goes by the name DOMAIN\MACHINE$.
Most likely, ASPNETCORE_ENVIRONMENT is not set correctly on the server (i.e. either not set at all or not set to Production).
On your server, edit the system environment variables and add one (if it doesn't already exist) with the name ASPNETCORE_ENVIRONMENT and the value Production. Also, edit the advanced settings of your app pool in IIS for the application and ensure that the key Load User Profile is set to True.
I have a simple VB.net console application that displays the current user, waits for key input, and then exits. It uses the following call to display the information:
System.Security.Principal.WindowsIdentity.GetCurrent.Name.ToString()
If I create a remote app hosting this application, and create an azure user that has rights to run the remote app such as;
thisisa#test.onmicrosoft.com
When this user connects to the remote app the output of the line of code above would look something like;
YLSDAAYU0007\thisisa_000
Is there anyway of reading the user running the remoteapp at the time? in this case, I am looking to obtain thisisa#test.onmicrosoft.com ?
Catalin from the RemoteApp team here. You have stumbled across one of our implementation details here :)
Windows does not allow automatic login with Azure Active Directory (AAD) users: they only allow users that have Microsoft Accounts or domain accounts in case the collection is domain joined. We are working around this limitation by creating a local user on the VM and logging in with that user instead of the AAD user.
If you have any more questions about this, feel free to contact me: catalda @ microsoft com
I'm just in the process of trying to properly configure asp.net 4.5 on our IIS servers.
I have been able to navigate and launch an ASPX page that contains no data conenctions sucessfully so I know that the application pool authentication to the local directories is working as it should.
Now though I have a seperate SQL server that is connected to the domain and have a connection string stored in the code that connects the ASPX page to the server using a trusted connection. When running in visual studio debug mode, the connection works fine - but at that point I assume it is using my login credentials.
My question is, when a user calls the aspx page via the browser when hosted on the new IIS7 server, which account is used to call the SQL server when using a trusted connection? - Is it the end users or is it a local account from the IIS server?
When I call a page with data connections embedded I get the error: Login failed for user ADMIN\PCNAME$ ... which is an indication that this is the account that it is using. However this account doesn't exist on the domain that I'm aware of. - Or does it ?!
Thanks in advance,
It will use the account that ASP.NET is running under, as you've worked out. What you usually should do is create a Domain Account (with the right privileges) and run your ASP.NET AppPool under that account. Then a Trusted Connection will use that account for connecting to the database, and as long as you've given it access (which as a Domain Account you can do) it should all work.
Added:
After some back and forth on comments, lets go back to the start: set the new AppPool to run with the domain users account, and recycle the AppPoolo. What is it that says the password is wrong? If it's IIS trying to start the AppPool, then it is extremeny likely that the Password you gave the AppPool IS wrong, or else that the password is set to change on first logon.
If its not IIS, but opening a Database connection, are you sure that the database allows this Domain Account access to the database and the tables within it it will need? What roles have you assigned to this account? Also, what SQL statement is it trying to execute (if it's got far enough to try and execute a statement at all)?
I suggest you put any response in you original question - comments get to be a drag if there are too many of them.
BLUF
Our application is attempting to write a file to a UNC folder using an ASP.NET web service running under .NET 4.5, IIS 7.5, and Windows Server 2008 R2. However, any attempt to write the file to the desired location results in an access denied exception.
The task seems simple however me and my team have been troubleshooting this for a while now and we are stumped as to what may be causing the error. Below are the details of our setup and what we have tried and found so far. Names have been changed to protect the innocent.
Environment Setup
The web server, mywebserver, has a website named My.Site.Com with a corresponding application pool named My.Site.Com. The application pool is configured as shown below.
.NET Framework Version : v4.0
Enable 32-bit Applications : False
Managed Pipeline Mode : Integrated
Name : My.Site.Com
Identity : ApplicationPoolIdentity
Load User Profile : False
The UNC path we are attempting to write to is \myotherserver\mydirectories\output where mydirectories is the actual share. On this share a domain group named mygroup-www has been granted full permissions to the share and all subfolders. The machine account (i.e., mywebserver) is a member of this mygroup-www group.
NOTE: For the moment, this UNC path actually lives on the same
machine, mywebserver. However, this will eventually be moved to a machine other
than mywebserver in our test environment and in the production environment
when that it is ready. Currently, I only have the one test environment to troubleshoot with.
The error can be replicated by executing the following code.
[WebMethod]
[ScriptMethod(UseHttpGet = false, ResponseFormat = ResponseFormat.Json)]
public string ExportReport(int reportId)
{
try
{
string output = ConfigHelper.OutputPath + "test.html"; // UNC path
string url = ConfigHelper.VirtualPath + "test.html";
string[] lines = { "Hello", "World!" };
File.WriteAllLines(output, lines); // Access Denied!
return url;
}
catch (System.Exception ex)
{
Logger.ErrorException("Error exporting report", ex);
throw;
}
}
Troubleshooting
Failed Attempts
We tried various combinations of group/user permissions on the folders (listed below). When running these tests we also ran Process Monitor. For each configuration we saw the same result. The w3wp.exe process attempted to create the file in the desired location but reported a result of ACCESS DENIED. The user of each configuration was IIS APPPOOL\My.Site.Com as expected.
Granting mydomain\mymachine$ full permissions to \myotherserver\mydirectories
Granting mydomain\mymachine$ full permissions to \myotherserver\mydirectories\output
NOTE: I have also tried modifying the code so that it would read a
simple file from \myotherserver\mydirectories\output. When
attempting to read the file, the process fails with an ACCESS DENIED
message as it did when writing the file.
Successful Attempts
We also tried several configurations that worked.
Grant the local IIS APPPOOL\My.Site.Com permissions
The first configuration to work was to grant the IIS APPPOOL\My.Site.Com full permissions to \myotherserver\mydirectories The file was successfully written however the process's user was quite unexpectedly a domain account that was set up for a web application on the same machine in another website. This remains very confusing but worked as the 'other' account also has write permissions to the share.
This won't work in production as we cannot use local accounts to grant access to networked resources but is an interesting data point nonetheless.
Change the App Pool Identity to Domain User
The second configuration that worked was to change the My.Site.Com application pool's identify to domain account that had full permissions to \myotherserver\mydirectories. This was a 'vanilla' domain account that was manually created by us. We did not capture what the user of the process was but that may be another useful data point.
This option may be possible, however it breaks away from best practices with IIS 7.5 and may not be allowed in our production environment due to fairly stringent IT policies.
Run the Site On My Development Machine
The third test was to run the site locally on my development machine, mydevmachine. My local IIS configuration is identical to mywebserver with the exception that I am running Windows 7 instead of Windows Server 2008. I granted full permissions for mydomain\mydevmachine to the \myotherserver\mydirectories and ran the application. The file was successfully written. According to Process Monitor the user for the process was correctly set to IIS APPPOOL\My.Site.Com.
Conclusion
We would like to enable write access as designed using the machine account of mywebserver. We have read ApplicationPoolIdentity user cannot modify files in shared folder in Windows Server 2008 and Permissions for Shared Folder for IIS 7 Application Pool Identity Across Domain and Application Pool Identities.
According to this information we should be able use the machine account to grant read and write access to networked resources such as the UNC path. In fact, I can do this in the desired manner when running the web site from my development machine.
There are a couple thoughts that come to mind. Perhaps there is something wrong with the machine account of the test web server. Or perhaps that 'other' software is interfering with the process somehow.
Any thoughts as to what may be causing this issue? What else should we do to troubleshoot?
Reboot your 'mywebserver'.
Marvel at the now mysteriously functional ApplicationPoolIdentity.
Install MS HotFix KB2545850 and learn the details about this bug in KB2672809 which also shows the steps to reproduce and demonstrate this apparently random problem. Direct download link here.
Speculate why Microsoft has not managed to release a normal windows update for this in the 3 years since that hotfix was published. While people still continue running into it and pulling their hair out because of this obscure problem.
Learn about the other folks who have shared and enjoyed this gift from MS that still continues to keep on giving:
IIS application using application pool identity loses primary token?
DirectoryServicesCOMException 80072020 From IIS 7.5 Site Running Under ApplicationPoolIdentity
ApplicationPoolIdentity cannot access network resources
ApplicationPoolIdentity IIS 7.5 to SQL Server 2008 R2 not working
Windows Authentication Failed when using application pool identity
IIS 7.5 stops using machine account to connect to network resource when using AppPoolIdentity
Your Windows 7 dev machine probably worked fine because it reboots more often than the server. Congrats on your very well written and thorough bug report. I rarely see that here.
I had similar problem accessing a network share using AppPoolIdentity in an ASP.NET application (access denied).
Using NetworkService account or other domain account worked but these were not the best solution.
I performed almost all the tests you did but finally found something that worked.
I figured out that the Network Service account was not used when accessing the shares, just like you did (i expected domain\machine$ account)
This worked for us:
On your IIS web site, go to Authentication and change the Anonymous Authentication item to "Application Pool Identity". It's by default set to "IUSR". This solved our problem.
Also maybe activating ASP.NET impersonation (still in Authentication menu) may help.
Thibault
I have faced same issue, I resolved by creating one domain account for each environemt (QA, STAGE, PRODUCTION). In Application pool identity I have set custom account and I used domain user for respective account. Now It gives me the ability to write and read the files from UNC Path.
I have a C# WCF web service hosted by IIS7 running on Windows Server 2008 R2. My web service needs to access a network share and so during Application_Start I execute the following:
NETRESOURE nr = new NETRESOURCE();
nr.dwScope = RESOURCETYPE_DISK;
nr.lpRemoteName = string.Format(#"\\{0}\{1}", MyServer, MyShareName);
nr.lpLocalName = #"X:";
string UserName = MyWebSvcLoginName;
string Password = MyWebSvcPassword;
uint result = WNetAddConnection2(ref nr, Password, UserName, CONNECT_UPDATE_PROFILE);
This has been working fine for 3 months. All of the threads in the web service process had access to the mapped drive. Now, all of a sudden, only the thread that called WNetAddConnection2 has the drive mapped. I am not aware of anything that changed in the server configuration. Are there any options that would prevent other threads in the process from seeing the mapped drive?
You need to look for the difference between what works and what does not. Things to check are:
Does the one that works running in a different application pool with a different identity. Has the identity that does not work lost some rights?
Does the one that works use a different user name and password to access the share. Has the passord of the user that does not work expired?
Do all map to the same drive letter? Is the drive being used for another share?