Ive created a app in asp.net using c# that needs to create folders on a number of network shares. Ive configured the app pool account to use a domain account and given that domain account the correct permissions to the network share folder. When i run my code im getting the following exception. Any ideas?
Exception: System.ComponentModel.Win32Exception
Message: Logon failure: unknown user name or bad password
You should create an account on the network that has the relevant access to that share and then set your application pool to use that identity.
This way, all requests from your application will appear to be that user.
Take care with this approach, however, as if anyone changes the password to that account, you will need to update it within your IIS
OK seems I've been a bit of a chump. Seems there was some code I wrote (cant remember doing it) that impersonated the account I had set for the custom app pool but with the old password. Simply commented out the code and it now works as expected. Note to self!!!!!! Must read stack trace more carefully in future.
Apologies for wasting your time
Related
I have a website in IIS 6.0 using an application pool with a custom service account. When I browse the website, I get an error "service unavailable" and the error in event log says
The identity of application pool 'SampleAppPool' is invalid, so the World Wide Web Publishing Service can not create a worker process to serve the application pool. Therefore, the application pool has been disabled.
I think the utility "Aspnet_regiis" can be used to grant access to an account to IIS metabase according to this article, but is that the right way to fix this issue? Because this utility is used for multiple things and may do more than just granting the permissions to the account, or should I just add the account manually to IIS_WPG group?
When I see this in IIS 6 and the user has a custom app pool identity, the problem typically originates in the entry of credentials in the app pool properties. So there are generally two origins for the issue.
One is a simple typo in the credentials, unfortunately the form validation is not very good in IIS 6, so I often will have users change the identity of the app pool, then immediately check that the credentials "took" and/or check the System event log for W3SVC and related errors.
The second specific cause I see in this scenario is when people enter an Active Directory user, they sometimes forget to add the domain name. (e.g. DOMAIN\Username). Which leads me to the next point, the IIS_WPG is the builtin local group which grants members the required ACLs to run as an app pool identity. The aspnet_regiis.exe -ga grants the same thing to users, but IMO it is best suited for use when the IIS_WPG group is not an option. Also a dedicated app pool user account is generally a good idea. If the AD user password is changed, you'll bring your app to its knees until you again re-enter the credentials in the IIS Manager.
Edit: I added some para breaks to make this chunk more readable.
I had this same problem and I resolved it by starting the application pool. Ours was stopped even though IIS was running.
"The identity of application pool 'SampleAppPool' is invalid..."
Every time I have had that error, it was because the user name and password where not correctly entered in the application pool. This happens also when you import the pool settings from another server. Reentering the password in the application pool identity configuration has always solved the problem.
Once you get that right, you will probably meet the second problem you are describing, but that's an unrelated issue. It can be fixed as you describe, or even manually granting the required access permissions to the application pool identity.
If you are connecting to a remote machine using one or more remote access tools, take note: your keyboard mappings may be getting screwed up somewhere along the way!
In my case, I tried typing out certain letters of the password in a plain text editor on the remote machine (not necessarily in the same order, to retain security). When attempting to type the dollar character, I found that if I used the left shift key I got a "$" but if I used the right shift key I got a "4".
Once I had that figured out, I could enter the correct password for the Application Pool Identity. (Note: when filling out the identity section, IIS does not validate the password you enter against the user identity, only that the two passwords you enter match each other).
I am trying to write to a file on a server (web05) from a classic asp site running on Windows 2008 serer on IIS7 (webadmin). This fails and web05 logs an anonymous logon attempt during the course of the save operation.
Webadmin's site is running on an app pool in classic mode with a domain user as the process account. The process account has rights to "Trust this user for delegation to any service (Kerberos only)". The same applies for the web05 and webadmin servers.
The site is using Windows Authentication and the idea is that when I log on the site with my domain user, the rights of my user should define what I am allowed to do in the context of the IIS site. If I turn on Basic Authentication, everything works fine.
I have also used setspn.exe to add an SPN for the URL. If I type setspn.exe -L webadmin, I get:
HTTP/webadmin.companyname.com
TERMSRV/webadmin
TERMSRV/webadmin.companypub.local
HOST/webadmin
HOST/webadmin.companypub.local
So from what I understand the SPNs are set up correctly.
If I run processmonitor on webadmin while the save operation is executed, it says that the process is indeed impersonating my domain user - but getting "Access denied" (and as I said before, web05 logs an anonymous logon attempt).
Any idea what causes this?
Kind regards,
Simon
It sounds to me like you're a little confused over impersonation. The process isn't impersonating the domain user account its simply running as that user. There is a difference.
When a request arrives into ASP it will then impersonate a user and the thread handling the request will be running under the security token of the impersonated user. Its quite possible to have the same process impersonating multiple different users in multiple threads. In most cases where the anonymous user access is enabled this user is the Guest level IUSR account. Its most likely that its under this user your code is attempting and failing to run.
However if anonymous is turned off for the resource being accessed or the IUSR account does not have access to the resource then the a 401 response is sent back, with some indication of what authentication protocols it will accept. The browser may then attempt to authenticate the connection using either the current users credentials or request some credentials from the user.
You don't specify exactly how you are attempting to save file. Its worth pointing out couple of things though.
ASP code exection which may subsequently result in an access denied will not use the above mechanism to try to resolve the user.
Once a connection is authenticated it often continues to be re-used for subsequent requests (which is counter-intuative to the knowledge the HTTP is a "connection-less" protocol).
I am trying to clean up my previous questions. This answer is not sufficient to answer the question above, but I concluded that it is better to provide some insight than none. If op disagrees, please take necessary action.
This is a way back - but I recall wanting to run kerberos authentication on this app. The problem turned out to be that I tried to do kerberos outside the firewall. The app would work fine within the domain and firewall of the server's home domain but failed whenever requests came from outside.
I did a lot of chatting with an Irish technician in Microsoft, and he taught me a little about the limitations when using Kerberos. The reason I wanted to use Kerberos was that I didn't like the thought of Basic Windows authentication being unencrypted.
Good luck with your Kerberos quest :-)
I ran into this same issue and it turned out to be a simple change to the application pool. If enable 32-bit applications is set to FALSE then I recieved a prompt to login to the machine. Setting this value to true fixed the issue.
I recently had to change my active directory account password.
Ever since then I am unable to deploy BizTalk projects or put my Receive Locations in the stop state (Sendports & orchestrations is fine).
I noticed that my Enterprise Single Sign-On Service isn't running, if I try to start the service it complains about a login failure.
The thing is, you would think that it used my account to start this service and that it can't login anymore because of some old password or something. However I run the service with another user, namely: BiztalkUser. This user is set on the service and u can also see him in the biztalk server configuration.
Anyone have any ideas what I have to do? Cuz I can't do much anymore now.
The procedures for changing service accounts and password is clearly documented by Microsoft http://msdn.microsoft.com/en-us/library/aa561505(BTS.10).aspx please follow the steps outlined under "Enterprise Single Sign-On Service on Master Secret Server" to correct your issue.
I agreed with the first paragraph of answer 1. That would be the first option I would look to correct the problem. The second option would be, restoring the master secret server.
See below;
Open a command prompt - Navigate to C:\Program Files\Common Files\Enterprise Single Sign-On\
Type in command - ssoconfig -restoresecret SSOXXXX.bak
(Where XXXX is a randomly generated name created with SSO was installed. This is the SSO back-up file)
Enter the password - (Again you entered/created/accepted this when configuring SSO in the BizTalk configuration.)
Additionally you should create a new backup file if you have changed the account the SSO service runs under.
To create a new back-up file - ssoconfig -backupsecret latestbackup.dat
If SSO is running under your account and it stopped working when you changed the password, you need to update your password on the service's credentials. You can do this in the serivces control panel. If you have other BizTalk items running under your account, you will need to update them as well... host instances, application pools, etc.
BizTalk User may not not have the necessary permission to run SSO. I'd suggest put the account back in that worked. Comb the error log for other messages to help you diagnose th eproblem. For furtherhelp, I'd suggest posting more specific details of your current problem here (ie. Error Messages, Log Files, etc.).
I have written a web service that reads from a message queue.
This works fine under Cassini.
Now that I have deployed the service under IIS, I receive an error message when the service tries to access the queue:
The queue does not exist or you do not have sufficient permissions to perform the operation.
I have set the anonymous access user on the IIS virtual directory to be my own domain account, which is a member of the administrators group on the local machine. I have granted this same user full permissions on the queue, as well as NETWORK SERVICE and ASPNET.
I still get the same error message.
I have also tried disabling anonymous access on the virtual directory and connecting to the service using my own login details - to no avail.
Any help with this problem will be greatly appreciated!
I have also tried various combinations of:
and
With testUsr having full permissions on the queue. I have added permissions for the user and ASPNET on the MSMQ store folders on C:\
My understanding of the problem is that the process trying to execute the code is running as a different account under IIS than it does under Cassini.
The problem was that regardless of which user I impersonated - I always got the same error message - even when the user was a member of the local and domain administrator groups, and this user had full permissions on the queue. i.e. It is barely possible to assign more rights to a user.
It turns out, that using a FormatName for the queue, rather than a path name (myMachine\queueName) has solved the problem...
FormatName:DIRECT=OS:myMachine\myQueue
I am uncertain as to exactly why this is the case. Reading up has showed that when a path name is used, there is a necessity for an AD lookup, and although I think that the users that I have been testing with should have rights to do this, perhaps there is something missing.
However the immediate problem is solved and that's good enough for me.
When I access file whith UNC file path from asp.net, I found the following problem. Logon failure: unknown user name or bad password. Pls help me.
The problem may not be with the UNC nature of the path you're trying to access, but with the security credentials. If, for example, you are running your asp.net application under the System account, then you won't be able to access network shares because System is a local account (not a domain account).
I suggest you check in inetmgr under which user your application pool is running (under the Identity tab). Try using a domain account that can access that share.
The solution is held under the impersonation and delegation functionality of asp.net. There are certain constructs which provide a token based security scheme to call a file.copy operation for example with the target being a UNC location. You can check it here.
The account "in charge" when the file access request is issued simply must be lacking credentials to access the share / resource found at the UNC location.
You first need to determine which account is effectively used, as this may vary, and provide the relevant privileges. By default most programs, including .NET programs (to a lesser extent) will run in the security context of the account which launched the program, however this doesn't hold, in many situations, for example if the program is a service of sorts, or if it uses some DCOM objects, or if it impersonate some other accounts etc... Also .NET has a relatively sophisticated system of delegation/impersonation.
One way to diagnose this issue is to add auditing at the level of the UNC file/directory. Upon failure this will leave a event which should show the login name of the account which tried to access the share.