AD group has dbowner access to DB. How can I stop users from accessing from outside the application.

  • What am I missing. An application uses the users AD ID to execute against the database (read, write, create temp tables, execute procs). The users are all part of a single AD group and that group is granted dbowner access. (I have no control over the 3rd party application). How can I prevent these same users from accessing the database via any other application? With dbowner access they could access via SSMS, Toad or any number of other programs and do who knows what. All they need to know is the server name.

  • You don't. You've opened the floodgates.

    However, there's a hardware mechanism you can use if you've got a centralized N-Tier and these users aren't running the app off their PCs. Firewall your SQL Server and only allow particular IPs to access it, and then open up those IPs that the application/N-Tier resides on.


    - Craig Farrell

    Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

    For better assistance in answering your questions[/url] | Forum Netiquette
    For index/tuning help, follow these directions.[/url] |Tally Tables[/url]

    Twitter: @AnyWayDBA

  • If there are other DBs which are legitimately accessible by users, you can't.

    If there aren't, and if you can authorization to modify your firewall policy on the server, then look at firewalling off connections from everything but the DBAs and the app servers. Of course, if the DBAs aren't in their own vLAN, then this may not be an option, either.

    The question I have is why does a group have dbowner access? Is this required of the app? If so, have you pushed back with the developer of the app?

    K. Brian Kelley
    @kbriankelley

  • It is required by the app and yes I have pushed back but gotten nowhere. Even if they weren't I would still have an access issue. Looking at the firewall option.

  • from the TSQL side, you could create a logon trigger that checks the application name and the login name both.

    you could make sure the login is using a specific application name, or the opposite: the login is using something it shouldn't be.

    while you could rollback their connection, i might consider just monitoring non-compliance and reporting violators.

    here's just one example of the many logon trigger examples found here in the forums:

    http://www.sqlservercentral.com/Forums/Topic1199139-149-1.aspx#bm1199153

    Lowell


    --help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

  • Thanks, this looks like something that will work for us.

  • Bear in mind though it's trivial to spoof the application name.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • I use a logon trigger for situations similar to this

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

  • Try creating a second AD Group and assigning the users you don't want to have db_owner access to that new group. Assign new permissions to the database via the group level and the problem is resolved.

    At lease, if I understood the problem correctly.....

    We had a similar problem whereby an application had to have SYSADMIN rights on the instance and DB_OWNER on the database. It wasn't negotiable and the vendor wasn't prepared to rewrite their code.

    We didn't buy the App.

  • I suppose you could set the application up to use a different account and set a windows shortcut to the application to run it as that account. Expect lots of support issues from users who redo their shortcuts though.

  • As others have mentioned, I've run into this situation before and with the application running from a web server in our case. For security our SQL Servers run in their own VLAN with all traffic being managed by the firewall so it's really easy to restrict access by source IP or MAC address so that only approved servers can communicate with the SQL servers. We even went so far as to put in specific rules so a live web server couldn't connect to a PreProd SQL Server, and vice versa.

Viewing 11 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply