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.
Related
I created few web applications for the one app service plan. For all these apps I am seeing one FTP url. Issue is that when I go to the URL, I can see one "Site/wwwroot" folder which only shows one application.
Isn't is possible to access FTP of other web applications?
All applications works fine. I don't understand how this FTP is being created. If it's showing just one application in FTP, what criteria is based on that? I am seeing the 1st application based on the alphabetical order.
The FTP Url is same for all the sites in a stamp and will be same even if you create multiple app hosting plans as long as the hosting plans are in the same stamp. A stamp is a collection of servers and roles in a particular datacenter.
So how azure connects to the right site - the distinction here happens when you provide the user name for the site that you are trying to connect. The user name has the form sitename\$sitename when using publish credentials and has the form sitename\username when using deployment credentials and this name is used by app service to identify which site you are connecting to.
http://weblogs.asp.net/bleroy/azure-web-sites-ftp-credentials has more details.
Also read https://github.com/projectkudu/kudu/wiki/Deployment-credentials to understand difference between the two kind of credentials.
So just specify credentials in this way and you can connect to your sites using ftp.
Hope this helps
I created a web application using Asp.net web api in azure and i want to consume it with a web role application ! what is the difference between web application and web role and what should i do ! thanks
An azure webapp is a website you host on azure as a normal website.
you don't really have a lot you can do with the machine. Just see it as normal website hosting.
A webrole is part of a cloud service. Which is a bit more flexible. Web roles allow you to install for example applications on the vm you are running your application. The state of the machine is not held so if the machine goes down you lose all data you stored on it. In fact you upload a sort of zip package with the application inside. This installs the app and when something goes wrong a new machine is started and the package is installed again on that new machine. This is also 'an issue' with azure websites.
Here is a good link with some more info + with info on virtual machines which is in fact a layer lower, meaning that you have more control over the machine.
https://azure.microsoft.com/en-us/documentation/articles/choose-web-site-cloud-service-vm/
In most of the scenarios Azure Web App is what you should use. It provides all the capabilities required for almost all websites.
However, Web App may not work in few scenarios e.g.,
When you have a dependency on software or library that you need to bundle with your code
You need to RDP into the machine for some purpose
...
In those scenarios you will have to depend on Web role.
We are running into an issue when we try and setup a new SSRS Application within Central Administration.
I am able to set the Name, App Pool, Configurable App Pool Account, Database Server, Database Authentication, but unable to set the Web Application Association.
The first time I setup the Application it allows me to select the Service Application Sites. When I return back to the Properties, Above the Web Application Association I get this message:
"There are no web applications available to associate with this sql server reporting services server application."
I am suck and cant seem to get this resolved. Has anyone came across this issue before?
You have to approach this in a different way; instead of configuring the associated Web Applications within the Service App. Config, you change the Service Application Associations (Central Admin > Application management > Service Applications > Configure Service Application Associations)
Once there, click on the Application Proxy Group that you're using - in my case, this was 'default'.
That will then pop open a window - "Configure Service Application Associations". Simply untick your old SSRS Service Application and tick the new one.
While it doesn't solve your exact issue... A combination of this and another proxy group might do what you want.
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.
We are looking to replace our normal Win2008 R2 IIS server with a Azure Cloud based solution. Our Current use scenario is something like this:
Server A
Hosts 7 Websites.
All Websites are Managed and Maintained with Visual Studio 2010. They are Web Projects, not Web Services. Each of the Sites has unique domain names. www.comanyA.com, www.companyB.com Intranet.companyB.com, etc. There are three sites that are SSL enabled and have Verisign Certificates.
The Sites consist of many asp, aspx and image files. We also create file content on demand (Excel Exports) that users can then click to download. We also make a Connection to a SQL Server for Back-end Data. We would need a Secure Connection to a SQL Azure DB and or an On-Premiss SQL Database (depending on when we move our SQL to SQL Azure).
I Would also need the same Security Permissions setup so all the users have the same permissions that they do for the Existing IIS Server. So I'd like Active Directly Integration.
I'd really rather not have a VM Image that is just running in the cloud. I don't want to have to maintain the OS level of stuff, (Updates, etc)
Is this something that Azure Compute can do for me?
Thanks!
This is not actually a single question. The only real question here that I see is
"Is this something that Azure Compute can do for me?"
And answer is - depends :) To very high degree, Azure compute might and will help you!
To solve challenge #1 (Multiple Websites / no ssl) - the easieast. Check this and that blog posts.
Challenge #2 (Connecting to SQL Azure / On-Premise SQL Server) - second easiest. SQL Azure still supports only SQL Server Authentication and it requires encrypted connection. As for connecting to On-Premise SQL Server, you can use Windows Azure Connect (and here). You can even domain-join your compute instances in the cloud.
Challenge #3 (Active Directory integration) - part of it described in Challenge #2 - domain join your roles! But you could also review the Windows Azure Access Control Service and its ADFS integration.
Challenge #4 (Multiple SSL Enabled sites behind same endpoint). Well, this is the trickiest! In Windows Azure everything lives behind a load balancer. So, you could generally define only one standard HTTPS (on port 443) endpoint. And that's it. Although, you could now have separate SSL certificate for each different SSL enabled site, this is not possible in Windows Azure. For this to work in Windows Azure, you need a Subject Alternative Name certificate (here, here and here are just some examples).
Hope that this helps!