So what I need is a remote/cloud Windows Server that I can connect to using RDP (or another remote connection program) where I can create users, groups, basically everything I could do with an on-premises Server instance. What I need though is to be able to setup all the office computers to authenticate through the cloud AD. I have no clue how to do this. I cannot have a Server running on-premises, period. Just need something where I can connect each computer to the remote domain/forest, hopefully using an IP to the server, and then have the employees be able to logon to any domain-connected PC using their credentials. Thank you for any and all answers! -Scott
You need Azure Active Directory. You can control everything with remote management in the way you have described. Per the provided link, "Azure Active Directory (Azure AD) provides an easy way for businesses to manage identity and access, both in the cloud and on-premises."
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.
I have looked everywhere on Stack Overflow and I have not found an answer that closely compares to my scenario, so please bear with me.
The issue is I was recently given a development server at work and I have to migrate my current project (which I have on SQL Server Management Studio running on SQL Server Express) so that it is hosted on that server. I was just given the server name and authorized access to it. So I can connect to it through Remote Desktop Connection (RDC), but I am clueless as to where to go from here.
I have tried going in through RDC and opening Management Studio from there but when plugging in my server name and using Windows Authentication it doesn't let me in. And I can't use SQL Server Authentication because I'd have to be actually in to be able to create an SQL login.
How can I connect to this server through Management Studio?
The server is in the same network? In the management studio, in server name, you can put a IP address or computer name.
Do you know if SQL is even installed on the server you are tasked to deploy to? You are able to "connect" to SQL Express locally because the instance is installed on your local machine. You will need an instance of SQL installed on the remote machine to be able to use SSMS to connect to the remote instance.
If you are attempting to connect to an already created DB that you have been using the credentials are the same, if you know the address and you have the ports opened on your computer to allow the connection. If you are going to start a new DB on the server, then you will have to connect via AD credentials IF your admin has given you the proper access. I personally suggest using AD credentials to create connections, it's just a lot more secure.
If you are trying to connect to the local db, then it should be on the drop down list on the log in screen.
You are going to have to talk with your admin who set it up if you are still having problems.
You might have to Enter your Server Details in the Hosts File on the Current Application Server
For Accessing Hosts File,
Go to Run and type drivers and Hit Enter. Go to the etc Folder and you will see hosts file in the Folder.
At the End of the File Enter the Server IP And Server Name
Save the file and try Logging into the Server Management Studio again
Hopefull, this would help
I've inherited a VB.Net Windows forms application that is used across several hundred remote sites. On the remote sites the application connects locally to a local SQL server instance using the currently logged in Windows user at the workstation - this all works fine.
The application however also needs to connect to a remote SQL server - currently this is done using a set of connection strings and sql authentication. The DBA wants to move away from using SQL server authentication and make everything Windows authentication.
Clearly, adding hundreds of users to the remote DB is not an option. Therefore I need to be able to use the currently logged in user if connecting locally to a local SQL server and a different Windows users (which will have permissions to the db server) if I am connecting remotely.
Does anyone have any suggestions of how this can be done or can suggest an approach.
Thanks
Since both servers are on the same domain, create Active Directory Groups for the application, put the users' Windows logins into the groups, and then give the 2, 3 or 10 or whatever app-specific AD groups permissions in the databases. If you're using stored procedures, create a database role for each AD group, grant the DB role execute permissions, and add the AD groups to the DB roles.
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 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.