Results 1 to 9 of 9
  1. #1
    Join Date
    Jul 2003
    Posts
    70

    Unanswered: Blocking sa user

    Hi All,
    I have a hypothetical scenario. I have few developers who all know the sa password. I want to block one developer from accessing the SQL server eventhough he knows the sa password.

    Do we have any mechanism in SQL Server 2000 to block client based on the IP address of the client?

    SQl Server is installed on Windows 2000 server. It uses SQL Server & Windows authentication.


    Regards,
    Anand

  2. #2
    Join Date
    Feb 2003
    Location
    Brisbane, Australia
    Posts
    110
    Change the sa password

  3. #3
    Join Date
    Jul 2003
    Posts
    70
    Thanks for the reply.
    I know that would be the best alternative
    But currently I am not in a position to change it immediately.

    Can you suggest something else

    Regards,
    Anand

  4. #4
    Join Date
    Jan 2006
    Location
    USA
    Posts
    115
    sa login is built-in login as well as assigned sysadmin fixed server role. You can change sa password, but if someone knows the password he/she can login the SQL Server.

    Use mixed mode security or give separate SQL Login to the developers with the db_owner or db_ddladmin database role, according to your requirement.
    Rajesh Patel

    Everybody says - mistake is the first step of success, but it's not true. The correction of the mistake is the first step of success.

  5. #5
    Join Date
    Nov 2006
    Location
    UK
    Posts
    46
    How about VPN, router settings, IP or MAC filtering?
    Regards
    Kris Zywczyk

  6. #6
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    You can filter ports to keep an IP address from making any connection to a SQL Server database, but that's rather drastic for limiting a developer. There are solutions to this problem, but all of the ones that I can think of require intimate knowledge of the problem... I don't know of any generic answer to this kind of problem.

    -PatP

  7. #7
    Join Date
    Nov 2002
    Location
    Jersey
    Posts
    10,322
    change the f'n sa password

    sa shouldn't be used....some writers have even suggested creating a very strong password...write it down, put it in a safe and never use it..and create a new, "unknown" login that has sa rights
    Brett
    8-)

    It's a Great Day for America everybody!

    dbforums Yak CorralRadio 'Rita
    dbForums Member List
    I'm Good Once as I ever was

    The physical order of data in a database has no meaning.

  8. #8
    Join Date
    Dec 2002
    Posts
    1,245
    Quote Originally Posted by Brett Kaiser
    change the f'n sa password

    sa shouldn't be used....some writers have even suggested creating a very strong password...write it down, put it in a safe and never use it..and create a new, "unknown" login that has sa rights
    Yep. First thing I do. Select newid() (on a different server). Copy and paste results into the install screen. Forget about it. Never use sa for anything.

    Regards,

    hmscott
    Have you hugged your backup today?

  9. #9
    Join Date
    Jan 2006
    Location
    USA
    Posts
    115
    Quote Originally Posted by hmscott
    Yep. First thing I do. Select newid() (on a different server). Copy and paste results into the install screen. Forget about it. Never use sa for anything.

    Regards,

    hmscott
    Humm... really unique password..!
    Last edited by rajeshpatel; 12-09-06 at 00:54.
    Rajesh Patel

    Everybody says - mistake is the first step of success, but it's not true. The correction of the mistake is the first step of success.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •