I am a bit new to this VB.NET application stuff. I currently try to develop a application using Microsoft Visual Basic. Net with Remote SQL Server 2005.
In my application include user login using Username and Password. The application will use from many branches. Every branch have their own Username and Password. I create User Master table in SQL Server Database with SLN, User_name, Password, Branch, Note fields.
Now I want to design a VB.Net Form in my application where I can get all Username and Branch login status in a DataGridView like....
Header - *Branch Username Status*
Value - Kolkata U00001 Logged
How can I get this? If any senior vb.net developer or expert solve the same i will be very thanks full to him. Thanking you.
Here is some SQL to extract the current users:
select distinct DB_NAME(dbid),loginame, dbid
FROM sys.sysprocesses
where [dbid] not in(0,1,4) -- exclude list
Note there are two levels of security in SQL Server - SQL Security and "Integrated" security. The latter uses the windows login, SQL Security is managed by you within SQL Server. It looks like you intend to add an SQL user/login named for the branch with a defined password that everyone in the branch will use. Not a great idea IMO. You can use integrated security and add each windows user to SQL server and then add the SQL users to security groups to control access to the SQL objects. This would require each user to authenticate with your windows servers first locally before they can connect to the remote server.
I'd highly recommend you upgrade to at least SQL Server 2008 R2.
Related
I have a contractor who I want to give access to a website that connects to a database. I need to create a SQL Server user that can connect and read and write to the database.
However, I don't want this user to be able to connect to the SQL Server via something like Management Studio. Are there permissions that need to be enabled or disabled to accomplish this in SQL Server Management Studio?
SQL Server Management Studio (SSMS) is basically a normal client that makes SQL statements in the background. If you create a login in the SSMS, then no magic happens, but a CREATE LOGIN. This can be recognized by the fact that there is (almost) always the possibility to generate the appropriate SQL statement via "Script as", which is normally done in SSMS via the graphical user interface.
If you would lock out SSMS, then other clients as well. And even if there were a setting, there are other possibilities via Powershell and the like. So this is not the way to go.
I suppose you don't want the contractor playing around on the SQL server just because he got access to a database? He is allowed in the house, but not in all rooms....
In other words, it can only be done via permissions, where there is a login to connect to the SQL Server on the one hand and a database user who gets access to the database on the other hand. Therefore there are authorizations on SQL server level (login) and database level (user).
CREATE LOGIN testlogin WITH PASSWORD = 'wowThisIsKewl';
GO
USE [YourDatabase]
GO
CREATE USER [dbuserlogin] FOR LOGIN [testlogin] WITH DEFAULT_SCHEMA=[db_owner]
GO
Each login belongs first to the SQL Server role "public", unless additional or different authorizations are granted. You can connect to this role, but e.g. you can not create databases, perform backups etc.... Just try it out.... =)
At the same time DB_OWNER at database level allows the login to read and write data, etc. and more.
We have dedicated cloud server hosting SQL Server 2014 and Microsoft Dynamics CRM 2016 which is working without issues.
I have got a query that gets data out of the FilteredOpportunities view that I can run in SQL Server Management Studio as a windows user but not a SQL User (displays only column names), when I try to run it in SQL Server Management Studio on my laptop using the sql user (can't use windows authentication as it is not on the same domain), it only returns the column names and nothing else.
The account has every permission that you could possibly think of granted to it to try and get the data out but it wont budge.
You cannot query CRM's filtered views with a SQL-user. For that you will need to use a windows user.
If you want to query directly with a SQL-user, you can use the underlying dbo.OpportunityBase-table. This will not apply the CRM security model.
Instead, you might want to consider using one of the CRM webservices for supported access to data with the security model enforced. If your purpose is to get data into Excel, it is directly supported to use the web services. See Export to an Excel dynamic worksheet.
I have found the answer. A bit clunky bit it works. I can conenct to the database with a SQL user (because i cant use windows authentication as I am on a different domain) then I can add code to the top of my exsisting code to impersonate a user with the rights to read the data. For those wondering the code is:
DECLARE #uid uniqueidentifier
SET #uid = convert(uniqueidentifier, '((UID of the user you want to impersonate))')
SET CONTEXT_INFO #uid
I've been searching everywhere but it seems as nobody has my problem. I recently created an Azure SQL Database and I have not had luck at all with figuring out what to do with the error 18456. I Many times I've seen the "Just right click the database and go to properties and security" but there is no security. In fact there seem to be a lot of things I don't have when I right click. I barely know anything about any of this though, so I've tried quite a few things. At one point I thought I needed to use the sample adventure works. but that wasn't it. So I'd be really grateful if anyone helped.
[SSMS Version: 16.4.1]
[Azure SQL Database: Server Version 12]
Picture of my properties menu in SSMS(SQL Server Management Studio)
]
Picture of my right click
]
Your error is common, but the way you solve it on-premise or using virtual machines (Infrastructure-as-a-Service, IaaS) is different than how you would solve it for Windows Azure SQL Database (WASD). WASD is a Platform-as-a-Service version of SQL Server. The SQL Instance is logical, so you have to change some of your thought processes. One of the chief ways you'll need to change your thought processes is in how you manage your SQL Databases.
When you're in WASD and you create a database, you're asked to create an administrative username and password. Using that account you can deploy the schema of your database as well as SQL Authenticated Users and permissions. You don't have permission to change the instance's authentication types, that's why you don't see an option for security when you right-click on the instance name and choose properties.
The following steps are how you would create a new LOGIN to allow this new user to authenticate to the virtual instance. After you've created a LOGIN, you then need to create a database USER for this LOGIN. With this USER, you can then assign permissions for what this USER can and cannot do.
Adding Logins for your Windows Azure SQL Database
A few notes before we get started. In the following code anything in angle brackets (< and >) mean this is a variable you can change. So would be the username you want to create for your Entity-Framework application. would be the password you want to use for your .
Use your administrative credentials to connect to your instance. This account has permissions to control everything about your database. When you connect, you should find that by default you've connected to the master database on that instance. If not, use the drop-down at the top of SSMS to change to master. "USE master" will not work.
From this connection, the following T-SQL will create your Entity-Framework's username and password.
CREATE LOGIN [<username>] WITH PASSWORD = '<password>';
At this point, if you were to try and connect to the virtual instance with this and , you could connect to your virtual instance, but not any database on this virtual instance. Your error message would say something like:
The server principal "" is not able to access the database
"" under the current security context....
You need to take at least one more step before this user can connect to your user database.
Now, from that same SSMS script window, change the database to the user database () you're granting access to. This will be the database you want your Entity-Framework application to use. Remember, use the drop-down at the top.
First we will create a database user for the login created in the previous step.
CREATE USER [<username>] FOR LOGIN <username>
Then, we will allow this to connect to your user database , the database you want the Entity-Framework application to use.
GRANT CONNECT TO [<username>]
At this point, your new username can log in to the virtual instance and connect to your user database.
Now, you will need to add any other permissions this user will need. For example, if your will only need read permissions, you could get away with adding the user to the db_datareader database role. Add those permissions now.
Special note about connection and connection strings
Your user is now setup to connect to your user database. That means in SSMS if you try and connect with your Entity-Framework user, there is an extra step to your connection dialog box. Before you click Connect, you have to hit the Options button.
Since your user cannot hit master, you have to tell SSMS you want to connect to the user database first and avoid hitting master. By default, SSMS will try to connect to your SQL instance's master database first.
You have to enter the name of the database in the "connect to database" entry. After you've entered the database, you can then hit connect.
I'll guess that in your application it already had the "Default Catalog=" value set to your user database, and you were able to connect. Setting this value in options is like setting that "Default Catalog=" value.
I hope this helps you in breaking into WASD a little more.
EDITS: attempting to add clarity to the differences between IaaS SQL Server instances and PaaS Windows Azure SQL Database. I previously missed the FOR LOGIN clause on the CREATE USER statement.
I have Windows server 2008 with MS SQL Server 2008 R2 standard edition.
On Windows server I created a local group and added domain users into it.
On SQL server I create a login mapped into the windows group.
For this login I created user mappings for several databases with public roles.
Each databases table has grant to select for public role.
The problem is the domain users can select data from all tables except one database.
I compared setting for all databases. They are the same.
Is it a way to check security setting like I can check a database consistency using DBCC CHECKDB or something?
After using "SELECT * FROM fn_my_permissions ('Accounts', 'OBJECT')
ORDER BY subentity_name, permission_name;" the problem disappeared. I used a lot of other functions to check the security settings (e.g. sp_helpuser, sp_helprolemember), so I am not sure which one really helped.
Anyway somehow the problem got fixed.
I am attempting to migrate from SQL Server 2005 to SQL Server 2008. Both of these database instances are hosted on 3rd party shared servers that I do not have full permissions to. They are using mixed mode authentication.
I am running into trouble setting up the new database the same way the old one was set up. Specifically, the new web-based control panel doesn't allow a dbo to be specified when creating a new database and then when using Red Gate SQL Compare to sync up the schemas I am having problems because some objects (that don't explicitly specify dbo in the script) are being created with the prefix of the user account rather dbo.
I have poured over the documentation trying to find a way to force my login "user1" as dbo to the "db1" database. I came to the conclusion that the script should look like this:
ALTER AUTHORIZATION ON DATABASE::db1 TO user1
Before running this script, the login "user1" already exists, but is not a user for database "db1". Note I had to submit this script to the support of my hosting company in order to run it. According to the hosting company the statement successfully executes, however when I compare the databases using SQL Compare the user "user1" has not been physically added to the database like it was under SQL Server 2005. When trying to add it using the script:
CREATE USER [user1] FOR LOGIN [user1] WITH DEFAULT_SCHEMA=[dbo]
I get the error message:
"The login already has an account under a different username"
I have tried dropping all of the other users from the database, but the error message still persists - which I find odd.
While I could just fix the scripts by explicitly specifying dbo, this would inevitably be a time bomb waiting to go off because if any new script were introduced that didn't explicitly specify dbo there would be a failure during synchronization. Since some of the scripts are from 3rd parties, this is not a good solution.
So my questions: Is there another statement that I need to run in order to add "user1" to the database as a user that is dbo? Is there anything that has changed in the implementation between SQL Server 2005 and SQL Server 2008 R2 that could cause these inconsistencies?
I am unfortunately not able to test to find an answer to the second one because I don't have another SQL Server 2008 database to test with and I don't have full access to do anything I want on this one.
The old database was created through a control panel which forced dbo to be specified and the new one doesn't allow dbo to be specified when creating a database.
From what i have gathered the following should suffice.
ALTER USER [user1] WITH DEFAULT_SCHEMA=[dbo]
The create wasnt working as it already existed.