I just deployed a Power BI report server on SQL Server 2017 which is working at Windows Server 2016. The server is running on my local network. Which mean it does not have a domain. Is it possible to apply AD authentication in this case? (The Azure AD has already been created, and I just want to apply it to the report server.)
I had read the following document:
https://learn.microsoft.com/en-us/power-bi/consumer/mobile/mobile-oauth-ssrs
But I think this cannot help in the local network case since it requires a domain.
Related
When trying to connect to a SQL Server database, there is an option to connect via SQL Server authentication, but the only option I have with Analysis Services is connecting via Azure Active Directory or Windows Authentication (which I don't think I have).
However, every time I enter in my Microsoft user/password it just keeps prompting for it again and again, going in an infinite loop:
How do I actually connect to SSAS from SSMS?
Note:
Authentication type, Active Directory - Universal with MFA support, is recommended.
Follow the offical document(Manage Analysis Services), it works for me.
Currently I have two Azure VM's, one for the ASP.NET application (VM1) and another with SQL Server 2017 (VM2).
At the moment, the application on VM1 connects to VM2's SQL Server using SQL Server authentication, but now I want to change it to Windows authentication. I found this on the Azure website about how to connect:
Virtual networks also enables you to join your Azure VMs to a domain. This is the only way to use Windows authentication to SQL Server. The other connection scenarios require SQL Server authentication with user names and passwords.
https://learn.microsoft.com/en-us/azure/virtual-machines/windows/sqlclassic/virtual-machines-windows-classic-sql-connect
But there is also a website forum ask to use Azure Active Directory domain in order to achieve this.
I am confused regarding this, can anyone help me with a description how to connect my VM1 application to VM2 SQL Server using Windows authentication?
I have followed these steps https://www.windowsazure.com/en-us/manage/windows/how-to-guides/capture-an-image/ to capture an image of a VM. Used sysprep as mentioned and I was able to replicate the VM. The problem is that when I rdp into the machine, I can't connect to SLQ Server. Login fails for Windows Authentication. Usually this means that the SQL Server is on another domain, but in this case the error is on local machine.
So my question is, how to capture an image of a VM with SQL Server in Windows Azure and ensure that I can login with Windows Authentication at least when deployed?
I don't think you can, I think you will need SQL Server Authentication before sysprep (I haven't tested this), as far as I know this is the same on-premises and not an Azure feature per se...
If you run sysprep on Windows, you shouldn't have any expectations that the current principals provisioned in SQL Server will continue to work. SQL Servers references Windows accounts by their SIDs and running sysprep on Windows will create a new set of SIDs for the Windows account. Therefore, you will have to re-add them to SQL Server as you've discovered.
Adding a solution that worked for me, in case anyone facing same problem and haven't found any working solution.
After creating an Azure VM from the Image based on a generalized VM (sysprep run):
Launch SQL Server Configuration Manager.
Navigate to SQL Server Services.
Right click on SQL Server (SQLEXPRESS)->Properties from the right side panel.
Select 'This account:' and enter details of current VM Administrator credentials.
Apply changes and restart SQL Server.
Now, try connecting to the SQL Server. It should work.
I am taking a Windows Azure introductory course and one of the prerrequisites for it is to have installed SQL Server 2008 R2 on my machine.
When I'm installing SQL Server in the Server Configuration section it asks for 2 users: one for the SQL Server Agent and other one for the SQL Server Analysis.
I am a begginer, so that's why I'm asking you to recommend me wich users should I use. And also, is it possible to change the users after installation?
Thanks in advance.
Yes, you can change the user after you install those services. The services will run using those accounts and therefore the services will have the same rights as the accounts.
For DEV/test you can use the local system account.
For production you should create a dedicated domain account for those services.
The best account to use in this instance would be The Network Service Account.
Be aware that the Local Service account is not supported for the SQL Server or SQL Server Agent services.
The Network Service account is a built-in account that has more access to resources and objects than members of the Users group. Services that run as the Network Service account access network resources by using the credentials of the computer account. The actual name of the account is "NT AUTHORITY\NETWORK SERVICE".
Network Service Account is the only account which is supported by SQL Server and SQL Server Agent Services, allows for network file system access i.e. SSMS DBA tasks, and yet still avoids using a Local System Account.
http://msdn.microsoft.com/en-us/library/ms143504(v=sql.105).aspx
To change which account the service runs under, do so in the same GUI that you are currently using inside SQL Server Configuration Manager
I am trying to use IIS 7.5 Application Pool identity as login on SQL Server 2008 R2 so that my ASP.NET web app can connect to the database...
Using this approach worked fine on my local dev machine (IIS 7.5 and SQL Server 2008 R2 on same machine).
However, when I try to set up the same on production (IIS and SQL servers are separate) I am unable to add "IIS APPPOOL\MyAppAppPool" login to SQL Server 2008 R2.
Notice that in either case you cannot use "Browse..." when creating a login in SQL Server since "IIS APPPOOL\MyAppAppPool" user identity is dynamic (or "special")...
Any ideas?
Update:
For more info on Application Pool Identities see here.
From article:
Whenever a new Application Pool is
created, the IIS management process
creates a security identifier (SID)
that represents the name of the
Application Pool itself. For example,
if you create an Application Pool with
the name "MyNewAppPool," a security
identifier with the name
"MyNewAppPool" is created in the
Windows Security system. From this
point on, resources can be secured by
using this identity. However, the
identity is not a real user account;
it will not show up as a user in the
Windows User Management Console.
That articles states (under "Accessing the Network") you still use the <domainname>\<machinename>$ aka machine account in the domain.
So if both servers are in "foobar" domain, and the web box is "bicycle", the login used to the SQL Server Instance is foobar\bicycle$
If you aren't in a domain, then there is no common directory to authenticate against. Use a SQL login with username and password for simplicity
Edit, after comment
If the domains are trusted then you can use the machien account still (use domain local groups for SQL Server, into which add a global groups etc)
As for using app pool identities, they are local to your web server only as per article. They have no meaning to SQL Server. If you need to differentiate sites, then use proper domain accounts for the App Pools.
You can't have it both ways...