• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

SQL Server - what's the point of database users?

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    SQL Server - what's the point of database users?

    I seem to be able to do everything with just the login.

    Why have the overhead of creating database users too?

    I'm sure there are more complex scenarios than mine where this would be needed.

    #2
    Originally posted by Freaki Li Cuatre View Post
    I seem to be able to do everything with just the login.

    Why have the overhead of creating database users too?

    I'm sure there are more complex scenarios than mine where this would be needed.
    because you may not want some users and systems anywhere near certain information
    merely at clientco for the entertainment

    Comment


      #3
      Originally posted by eek View Post
      because you may not want some users and systems anywhere near certain information
      Why not just give everyones sysadmin privileges?

      Oh hang on......
      Originally posted by Stevie Wonder Boy
      I can't see any way to do it can you please advise?

      I want my account deleted and all of my information removed, I want to invoke my right to be forgotten.

      Comment


        #4
        Originally posted by Freaki Li Cuatre View Post
        I seem to be able to do everything with just the login.
        Exactly. That's the point of users - most won't need to do everything.

        Comment


          #5
          Originally posted by mudskipper View Post
          Exactly. That's the point of users - most won't need to do everything.
          No, but I can set all that at the login level.

          Let's suppose I have an AD group called CUK Users and I want that group to be able to have read/write privileges on a database called CUK. All I do is map the login to that table and add the db_reader/db_writer roles for CUKUsers.

          I've still got everything else locked down - the login can only run queries on CUK. And I haven't had to create users to do this. So, why would I create users in this scenario when the login seems to do everything?

          Comment


            #6
            Originally posted by Freaki Li Cuatre View Post
            No, but I can set all that at the login level.

            Let's suppose I have an AD group called CUK Users and I want that group to be able to have read/write privileges on a database called CUK. All I do is map the login to that table and add the db_reader/db_writer roles for CUKUsers.

            I've still got everything else locked down - the login can only run queries on CUK. And I haven't had to create users to do this. So, why would I create users in this scenario when the login seems to do everything?
            audit trails?
            merely at clientco for the entertainment

            Comment


              #7
              I don't know SQL Server. Is Users a synonym for Schemas, like in oracle?

              Comment


                #8
                Why do you need the user context to reach the DB at all? In a multi-tier application you tend to do all the auth in the middle tier/webserver/etc and just have an application identity connect to the DB.

                Or do the users need access to the DB using SQL Mgmt Studio, Excel etc?

                Matt

                Comment


                  #9
                  Originally posted by Freaki Li Cuatre View Post
                  No, but I can set all that at the login level.

                  Let's suppose I have an AD group called CUK Users and I want that group to be able to have read/write privileges on a database called CUK. All I do is map the login to that table and add the db_reader/db_writer roles for CUKUsers.

                  I've still got everything else locked down - the login can only run queries on CUK. And I haven't had to create users to do this. So, why would I create users in this scenario when the login seems to do everything?
                  Fine, if you are using AD. But most of my clients won't let AD near SQL Server. I suppose they are worried about network admin users blowing away databases.

                  Not being a DBA its not something I worry about.
                  McCoy: "Medical men are trained in logic."
                  Spock: "Trained? Judging from you, I would have guessed it was trial and error."

                  Comment


                    #10
                    Originally posted by Freaki Li Cuatre View Post
                    I seem to be able to do everything with just the login.

                    Why have the overhead of creating database users too?

                    I'm sure there are more complex scenarios than mine where this would be needed.
                    Do your databases have a guest user? If you remove that then they would probably need a 'proper' user.
                    i.e. can you get access to one DB, and restrict another, all using just the login?

                    Comment

                    Working...
                    X