I have the following configuration for a web site:
Two Web front-ends (e.g. machine names: WFE1 & WFE2) 1 SQ
One SQL Server Database cluster (e.g. machine name: DBCluster)
All machines are in the same domain (e.g. MyDomain) running Windows 2008 R2 Enterprise and SQL Server 2008 R2.
I am in the process of deploying a web application that uses the Application Pool Identity. I have named the pool MyWebApp, which translates to the name, [IIS APPPOOL\MyWebApp]. When I try adding this user to SQL Server I get an error:
Windows NT user or group 'IIS APPPOOL\MyWebApp' not found. Check the name again.
The script that I have used to create the account in SQL Server is:
CREATE LOGIN [IIS APPPOOL\MyWebApp]
FROM WINDOWS WITH DEFAULT_DATABASE=[MyDatabase], DEFAULT_LANGUAGE=[us_english]
GO
I imagine the problem is occuring because the IIS account is a local account which is not visible to the SQL Server box.
Can someone please shed some light on how this problem can be resolved? Is using a domain account my only option or can I still get the application pool accounts to work?
I imagine the problem is occuring because the IIS account is a local account which is not visible to the SQL Server box.
That's exactly the problem. The IIS AppPool account only exists on the web server. If you were able to add this account to SQL Server, you would be authorizing an IIS AppPool that is running on the same machine as SQL Server. (I suspect it might still fail.)
The most secure solution would probably be to do as you say - create an account on the domain, give that account appropriate permissions on the database, and run the AppPool using that account's credentials.
However, if you'd still like to do it, you need to authorize the computer that the AppPool is running on - ie, DOMAINNAME\ComputerName$ (note the $ at the end).
Take a look at this article for more information (specifically, the section titled Accessing the Network).
I think that's a bad idea, however, because it authorizes any program running as NetworkService to access the database - not just your web applications.
Related
Ok, I have followed the steps from https://learn.microsoft.com/en-us/sql/linux/sql-server-linux-active-directory-authentication?view=sql-server-2017 to try and fix this issue as well as the SUSE/Redhat documentation for connecting to an AD server.
The servers are on the domain, I can log into the servers with my domain credentials but when I attempt to login to SQL as a domain user ( that is a Sysadmin on the SQL Server ) I get a the Login failed, the login is from an Untrusted domain and cannot be used with integrated authentication ( Error 18452) when attempting to use SSMS from a Windows box that works if I log in with a local account from it. When I log in as the domain user on the linux box I get the SSPI Provider: Server not found in Kerberos database and Cannot Generate SSPI context. Iif I use sqlcmd for a local user connecting to the FQDN of either server it connects fine. I haven't touched Linux from an Admin standpoint in over 15 years.
This is on both a SUSE 12 SP2 and a Redhat 7.5 server in our test environment. Not a big deal for me but our users are complaining because they now need a local account to log in for testing purposes instead of just using their domain accounts like the Windows side of things. Any help is greatly appreciated, most of what I am finding online just points me back to the Microsoft document and I have basically rebuilt the servers a couple times trying to add it to the domain before installing SQL and also after installing SQL to see if that made any difference, get the same error both ways.
Here is the scenario:
A web server is running on IIS 8.5 using AppPoolIdendtity to pass through the credential to connect to Reporting Service which is remotely installed in a MSSQL Server.
The reporting service has added the machine account DOMAIN\MACHINENAME$ to the system role assignment from http://MSSSQLRS/ReportServer as System Administrator like this:
The permissions granted to user ' are insufficient for performing this operation. (rsAccessDenied)"}
Testing local MSSQL server is smooth with local access. However, whenever the connection is established from the IIS web server. The "rsAccessDenied" error came up as DOMAIN\MACHINENAME$ user.
Not sure what else is wrong either on the WEB IIS or MSSQL server....
Sounds like RS Windows NTLM is not configured correctly. See this article.
In our current Production Setup, we have setup SSRS and have been able to successfully use the SSRS reports in our .NET Web Application since years. We have used Impersonation in Web.Config (there might be other solutions available, we had to go with this) as shown below.
<identity impersonate="true" userName="domainname/username" password="password"></identity>
This solution worked well becuase our Active Di
rectory and SSRS server are located in the same Network / domain.
Now, as part of our Azure migration, we have migrated our SSRS server to an Azure VM. and we are able to view the reports using Report Server Manager within the VM. Now, when we access the Web Application (App Service - Web App), we are getting the following error. Below is the updated impersonation attribute that we have used.
<identity impersonate="true" userName="username#ouremailaddressdomainname.onmicrosoft.com" password="password"></identity>
"Could not create Windows user token from the credentials specified in the config file. Error from the operating system 'The user name or password is incorrect"
Obviously, this is because of the fact that we don't have a Active Directory domain setup in Azure. Below are my questions.
Can we utilize the users available in the default Directory that gets created on Azure?
If yes, how do I specify the impersonization?
Thanks,
Prawin
With your planned setup you cannot use identity impersonation. This is because the AppService Web Apps do run in an isolated sand-boxed environment which cannot be part of a Windows Domain.
You have couple of options:
Change the reporting server to use mixed mode Authentication and create local for the SQL Server login and user with appropriate permissions. Then configure your reporting application to provide these SQL Server credentials
Move your Web Application to same VM (will not require Domain environment) as your Reporting Server (or just the part which deals with the reports)
Move your application to a separate VM and utilize the Azure Active Directory Domain Services to make the VMs part of same domain (an overkill IMO)
I would vote for the first option, as it requires least changes and leverages PaaS services (App Service). Everything else is overkill or just an abuse of the cloud platform.
I use windows xp and IIS 5 for web development. For database connection the credentials are set up as Integrated Security. It works fine our our DEV server (IIS 6) where they have configured the App Pool to run under the context of a domain account which has dbo access on the database. I myself also have dbo access in the database.
But when I run from my localhost the database connection failed (under Integrated Security=true) saying user '' has no previleged. So its passing a blank string as user instead of my logged in domain accountj ("domainname\myname"). How do I configure my localhost IIS so that it passed my logged in domain account as a user to the sql server? Basically I'm trying to silumate the apppool on IIS-5in my local machine.
I tried changing the "Log on as" on World wide web services & IIS Admin on my local machine services console, restarted it and did an IISRESET. Nothing seems to fix the problem.
Also I tried putting my domain user name (domainname\username) and password in the connection string by removing integreated security=true. Still that also not works
I am an administrator on my local machine. I tried different things like making aspnet user an administrator,log as as service etc etc with no luck
Please advice me how to configure IIS5 to run under a different account. thanks in advance
You need to set the user for anonymous login to be the domain account. I forget what tab it is on but it is there somewhere.
I think this link will point you in the correct direction
http://support.microsoft.com/kb/310344
Use IIS Express -- it is IIS7 for XP.
I have recently had some problems that I think might be helped by debugging my ASP.NET MVC application in IIS instead of with the default ASP.NET Development Server. However, when I try this the application can't access the database server (MS SQL Server 2008 Express) - it works fine on the Development Server though.
The error I get is
Cannot open database 'myDbName' requested by the login. The login failed.
Login failed for user 'NT INSTANCE/NETWORK SERVICE'.
I assume it worked before because the development server accessed the database through my user account, and not via the network service like IIS.
I tried adding the user NETWORK SERVICE to the database, but it turns out I don't have the user privileges to do so - it doesn't matter that my Windows account that I log on to the server with is admin, or that I run the program in an administrator context. I just can't add another user to the DB.
How do I solve this problem?
You could change the user that IIS runs under: it's a setting in the properties for the ApplicationPool that your web site's running under.
We do this all the time as it gives us better control over user access - that NT INSTANCE/NETWORK SERVICE account's a bit too magic for my liking...
NETWORK SERVICE is a special account. If your database server is on another machine from your IIS server, you need to add the account:
\$ as a user for the database. So if you're on a IIS Server called LISA on the SPRINGFIELD network, you would need to grant access to SPRINGFIELD\LISA$ to your database. Note the dollar sign which denotes your user as a machine account and not an actual person.
If your database server and your IIS server are one and the same, grant access to the account "NT AUTHORITY\NETWORK SERVICE". That's the whole name of the account. And that should work.
Are you running a non-english Operation System?
For some reasons, the account name of "NT Authority\Network Service" has been localized in other languages.
Sadly, a lot of programs have the account name hard coded to the english name, and won't find the Network Service when running on foreign versions of Windows.