I'm trying to ensure my ASP.NET 4.0 application runs under an administritive account. I've got this in my web.config:
<identity impersonate="true" userName="Admin" password="myadminpassword"/>
'Admin' is the local administrator account on my server (Windows Server 2003 SP2, running IIS6).
But, 'SYSTEM' still gets returned from Environment.UserName when I run it.
Am I doing something incorrectly, is there anyway to verify that the impersonation is actually working? This is possibly the cause of a wider issue I'm seeing, so I want to ensure that I'm using impersonation correctly.
Update
I've also tried outputting
System.Security.Principal.WindowsIdentity.GetCurrent().Name
But, this also returns 'NT AUTHORITY\SYSTEM' as the username so it looks like impersonation isn't working or something is over-riding my web.config?
Thanks.
As this is an internally facing application, I just set the Identity of the Application Pool to the account I want to run under - this resolved my issues.
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'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.
I am trying to use msdeploy on my web servers using the /MSDEPLOYAGENTSERVICE method and it is continually saying i am not an admin and not authorized but i am using the administrator account and am using the correct password. Internally if i try the webdeploy.axd it works but that method is not an option for me due to port concerns.
Here is one of the command strings i use
"%ProgramFiles(x86)%\MSBuild\12.0\Bin\amd64\msbuild.exe" ..\mysolution.sln /t:Clean;Rebuild /p:Configuration=%CONFIG% /verbosity:m /fileLogger /maxcpucount:4 /p:DeployOnBuild=true /p:PublishProfile=%CONFIG% /p:MSDeployServiceURL=http://%SERVER% /p:UserName=Administrator /p:Password=%PWORD%
Here is another one that is returning the same issue:
msdeploy -verb:sync -source:webserver,computername=%MACHINE%,username=Administrator,password=%PASSWORD% -dest:webserver 2<&1
This happened after i updated msdeploy to version 3.5 and moved my development environment to vs2013. Unfortunately i can not downgrade either of these. Aside from those changes nothing else has been changed.
As always asking the question has reveled the answer.
If this group policy key is set to 'Guest Only' msdeploy will NOT work.
I switched it back to 'Classic' and now it works properly.
Computer Configuration\Windows Settings\ Security Settings\Local Policies\Security Options\Network Access: Sharing and security model for local accounts.
I know i said nothing changed but my admin seemed to have forgotten about that change. He has since been feed to the sharks with laser beams on their foreheads.
First off, I can connect to both databases with SQL Server Enterprise Manager, so I know the servers are up and available. One of them is SQL1, the other is SQLTEST.
In my program when I use the following connection string, it work connects just fine:
conn = New DBConnect("Data Source=SQL1;Initial Catalog=SignInspection;Integrated Security=SSPI")
However, if I change SQL1 to SQLTEST the connection times out I don't get any errors other than the timeout error.
I can run the profiler on SQLTest and see that it is most definitely NOT even attempting to connect. Nothing happens at all, not a peep, nor hellow.
Any ideas? Thanks
EDIT:
Well, it's a moot point now because I got authentication working properly on our SQL1 server.
I'll post the configuration here so perhaps someone else can benefit.
First off, the web server is running IIS and .NET. Users are logged in to the intranet using Active Directory, and the .NET page needs to retrieve their log-in credentials (username most notably). The database is SQL Server 2005, running on a different machine. But the .NET app needs to impersonate as another user to connect to the database.
To successfully do both of these things go to Windows > Run, enter inetmgr and hit run. Navigate to the site and right click > properties, then click on the tab titled Directory Security, click Edit.., make sure only Integrated Windows Authentication and Digest authentication are enabled. Enter your proper AD realm and click OK. Apply the settings/hit OK.
In web.config you need the following lines
<authentication mode="Windows" />
<identity impersonate="true" username="myDomain\MyUserName" password="123mypasswordgoeshere">
replacing, of course, myDomain\MyUserName and 123mypasswordgoeshere with the username and password that has login rights on both your domain and your sql server. The connection string can probably be modified, but this is mine and it works:
Server=SQL1;Database=SignInspection;Trusted_connection=True;
These are the steps that worked for me and hopefully they'll be of use to someone else.
When you connected with the enterprise manager, was that from the same machine as you're running the VB.Net code on?
Otherwise, it can be quite a few things, ranging from firewall or DNS as mdma mentions to being setup with the wrong network protocol or maybe not accepting remote connections.
This article contains a list of things to look at (it's for SQL 2000 but it's something to get you started at least).
The obvious question - does SQLTEST have a database called "SignInspection"? Also do you log on to SQLTEST via SQL Management Studio using Windows Authentication or SQL Authentication? I would expect if either of these were the problem you would get an exception, but its worth checking.
I've created a custom Web Part for SharePoint that interacts with SQL.
Everything worked fine on my DEV server.
After I moved the WebPart to the client's server I started having problems.
I get Error Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection when I'm trying to open the WebPart.
I've searched for solution for a few hours by now and everything I have found doesn't seem to work in my case.
This is how my connection string looks like:
<add name="MyDataEntities" connectionString="metadata=res://*/MyDataModel.csdl|res://*/MyDataModel.ssdl|res://*/MyDataModel.msl;
provider=System.Data.SqlClient;provider connection string="Data Source=ServerName;Initial Catalog=DBName;
Trusted_Connection=yes;Integrated Security=True;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient" />
The SharePoint Web App with the web part and SQL DB are on two different machines.
Here's what I've tried:
1). Made sure SQL uses Mixed mode authentication
2). Made sure the account I'm using has rights to access SQL
3). Tried replacing Integrated Security=True; in the connection string with the User ID = UserID; Password=Password; where UserID and Password were the account IIS is running under.
I ran profiler while clicking on the link and it looks like the app is not using the account’s credentials and is trying to log in anonymously.
Any help is appreciated, I'm desperate because this must be up and running by tomorrow.
Thanks in advance!
Try SPSecurity.RunWithElevatedPrivileges: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsecurity.runwithelevatedprivileges.aspx
This method will run code as the ASP.Net application pool identity. Wrap your database calls with it.