Using Azure Resource Manager.
I have an Azure SQL Database resource, and even when I delete all "allow" firewall (on the sql server's blade) rules, my VM is still able to query the SQL DB.
EVEN when I set "Allow Access" to no for the ip address of the VM, I can still query the DB. How??
Is this because Azure automatically allows resources in the same Resource Group to access it? Even without explicit Firewall allow rules?
Under the Firewall section of the SQL Server blade, there's a switch called "Allow access to Azure services". Having this on will allow any Azure resource to access get through the firewall (they will still need your username and password of course to actually access the server). This includes Azure resources on other people's subscriptions. See this answer.
I had this turned on and that's why my firewall settings made no difference for my VM's.
Not exactly sure what's happening with your specific situation, security-wise, but Resource Groups have nothing to do with it. Resource Groups help organize resources within a single container, where you can manage those resources better (e.g. add users to the Resource Group without adding them to the rest of your subscription). They don't play a role in communication between Azure services.
Related
I created SQL account for an application but how do I restrict or deny the same account not to connect the database using SSMS or Azure data studio by the developers since the developers can view the user information in web.config file.
Thanks,
Sandeep
You can use Azure Active Directory to authenticate your app, so that you don't need to write the username and password in config file.
With Azure AD authentication, you can centrally manage the identities of database users and other Microsoft services in one central location.
Benefits:
It provides an alternative to SQL Server authentication.
It helps stop the proliferation of user identities across servers.
It allows password rotation in a single place.
You can read more details from this document.
Basically the answer to your question is... You can't...
There is no way to identify the client of a certain connection in Azure SQL. What you can do, for example, is restrict access to a certain server using s firewall. But if your dev env is on the same machine as your SSMS that won't work because you're then blocking the dev env as well.
In that case, the best practice is to create a dev database to which all devs have access. In that case, it doesn't matter for you everyone knows the password because it's the dev database.
For production environments, you need to treat database credentials as secrets and thus make sure they are stored in a safe place. When you're using Azure, the KeyVault may be a good place to store the password. This KeyVault has a fine grained way of allowing access to secrets for individuals as well as IT systems.
How can I RDP to an Azure box using an account I created in Azure? I don't want to go down the route of syncing directories or anything. Just simply want to be able to create accounts in Azure that can be used to access Azure servers.
This is a basic centralised authentication model and I am sure I am just missing something. Surely Microsoft can't expect us to add a bunch of users and service accounts on EACH server we create and manage passwords etc as entirely separate entities.
By "Azure Box" I assume you mean an Azure VM running Windows. There's nothing "magical" about these VMs. If you want central user management instead of relying on local user accounts you need to add it to an Active Directory domain. And if you want sync between this Active Directory domain and the Azure Active Directory for your tenant, you need to set up Directory Sync.
One cannot do this (without resorting to directory synchronisation). A Configuration Management tool such as SaltStack/Chef/Puppet seems a leaner fit than creating a traditional AD infrastructure.
I have been allocated the responsibility at work of revising the current reporting services authentication process. The aim is to maintain the necessary level of security and also simplify the maintenance/configuration of granting access to the individual reports.
I do NOT have access to the domain controllers to be able to modify or create new AD groups. I have to work with the groups/users that currently exist.
In terms of authentication, it seems that I have the option of using either:
Windows authentication
SQL Server authentication.
Both the report server and the report database will reside on the same server. With this in mind, I understand that Windows authentication is probably a better solution as there is no need to maintain a separate SQL Server table of Users (and their passwords). Granting access to a report once it has been deployed on the report server, would simply involve adding the user/group to the report (load the report in a browser and access the Properties\Security option).
Using the second option of SQL Server authentication does not seem as appropriate as using Windows authentication for the reason the report server and report database are on the same box.
I am using SQL Server 2000 databases. The version of reporting services I have installed is Microsoft SQL Server 2008.
Please could someone let me know if my thinking is correct (i.e. I should go for Windows authentication). Cheers.
Jimmy
Sql Server authentication is not an option for users connecting to SSRS. It is an option for SSRS connecting to databases where it will get its data.
So bottom line, yes, you need to use Windows Authentication for user connections to SSRS. You can use special user names such as "Authenticated Users" or "Everyone" in SSRS to allow broad access.
I understand that you don't have access to AD, but managing the user accounts' membership in AD groups would be much easier than tracking and managing individual access in SSRS.
But without the AD access you can still add Windows/AD accounts to the report permissions and use those. You just create a more complex system, since you need to manage permissions for every individual separately. You can group the reports in folders and secure the folders: the reports can inherit that security.
I need to add a user (\network_service) to a different computer's sql server logins.
How can I do this? I am attempting to search for the account, but it is not finding it.
In SQL Server:
Security >
Right-Click Logins >
Click "Search" >
attempt to find \\<computername>\network_service
attempt to find \\<computername.domainname>\network_service
attempt to find <computername>\network_service
...nothing is working. I am searching under "all locations".
This is to get a dotnetnuke website running with using a separate server for its sql database. Supposedly, I need to add the NETWORK_SERVICE account as a sql server login.
Any ideas?
http://msdn.microsoft.com/en-us/library/ff647402.aspx
Network Service on one computer is Network Service on all; It is a limited-privilege, authenticatable user account common to all Windows NT machines. So, you should be able to simply grant the DB server's Network Service user access to the DB, and then applications, whether local or remote, that are authenticating themselves as Network Services should get the same access.
Is it wise to use Domain Administrator as a SQL Windows Authentication log-in?
No. Local admin, perhaps, yes: never domain admin
For example, xp_cmdshell would allow complete control over AD and your environment. CLR code could do the same. Although these are disabled by default, you can't rely on that to protect your entire network.
Edit:
Logging in as a user as domain admin is no different to using Exchange or similar with the same acount. For SQL Server. no extra rights are conferred or implied because all permissions are defined within SQL Server.
So if you only have a "SQL Server Admin" group as sysadmin, and the domain and local admins are not in this group or set up as logins, then they get normal user rights as per their login. Or they can't even connect.
Of course, as domain or enterprise admins they could just add themselves to the "SQL Server Admin" group... but this requires an extra step and restricts your sysadmin to the correct admin group.
After all, you wouldn't let me as SQL God near your Exchange server...
I think some of the posts have assumed you mean to run the SQL Server service under a domain administrator account (which I agree, would be a security hole), but as you have said in your clarification, it is just to log in to do stuff against the database, I don't see a problem with it....As long as the user in question (I'm guessing it's you here), knows not to drop the production database etc.!
Certain things you need to do against an install require DBA priveleges, if you acquire those by being a domain admin, then what difference does it make?
a. If you have no security problems than - it doesn't matter.
b. if you are connected to the internet, you shouldn't. someone can attack your domain using holes in sql code if the app you're using uses the domain admin authentication. or if someone get access to your administration machine.
c. there is no linkage between domain admin and sql server admin - so why do it ?
Just to be clear - It is not wise !
In my opinion, I wouldn't use an Administrator account for anything management related (that's my Linux background telling me that root accounts shouldn't be used).
It depends a lot about - well - your size and security practices. It does show a security risk, but whethe rit is wise o wnot depends on the rest of the setup.