Sql Server In Domain Controller

  • What is the advantage of SQL Server is running on the domain Controller?.

    i have two server, which is not in domain, they are running in workgroup and in DMZ Network.

    Server Details:

    Windows Server 2008 R2

    Sql Server 2008 (Sp3).

  • I am not sure I understand because you are asking for advantages when SQL Server is running on the domain controller. SQL Should not be in the domain controller.

    If the question is what are the advantages of running SQL Server in a domain, then the answer would be less complication when doing Authentication for anything. For example Back up security is easy to set up when it has to write to a Shared path. Replication security is easy to set up when in a domain. That is applicable even when connecting by windows authentication. If a windows authenticated user is trying to connect to sql server in a domain, not much complication. You just need to have to create the login on the SQL Server.

    Advantage of having it out of Domain is better security. Only a certain number of local accounts can log on to the SQL Server in a DMZ.

    -Roy

  • If the SQL Server is on the domain then it's easier to use Windows authentication to connect to the server. Windows authentication is more secure than SQL authentication if the users will already have domain accounts it lets you avoid creating additional accounts.

    Any particular reason that the server is running in a DMZ? Most places would consider that a security hole because people outside your network can access SQL and typically that gets filtered through an application so requests are known to be legit.

  • cfradenburg, You can have windows authentication with the Servers in DMZ. I have to contradict you completely. DMZ is the safest place to put your SQL Server. No Access to the SQL Server unless specified.

    -Roy

  • Dhirju (12/2/2011)


    What is the advantage of SQL Server is running on the domain Controller?.

    i have two server, which is not in domain, they are running in workgroup and in DMZ Network.

    Server Details:

    Windows Server 2008 R2

    Sql Server 2008 (Sp3).

    The only advantage to running SQL on the domain controller (and not a different server in the Domain) is reduction of hardware cost. I prefer to keep the two servers separate.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • i m new in sql server DBA. So please forgive me if i ask stupid question.. 😉

    recently we done setup of our new servers, and i have two Production sql server to manage.

    1st one will be connect to Application Production server, and 2nd one will be backup of 1st Sql server.

    and i have plan to configure database mirror

    so thats why i m asking..

  • If you are planning to have Mirroring, it is easier to have both the SQL Servers in the same domain.

    -Roy

  • The DC shouldn't be a huge load. I assume you have other DCs on your domain, or a small domain that's not too active.

    Running anything on the SQL Server instance takes memory/CPU/network/Disk IO away from SQL, which reduces performance.

  • thanks Roy..

  • Thanks Steve and Roy .

    i have lots of questions in my mind to ask. 🙂

    Please keep me guide as a mentor.

  • Roy, can you detail why you would put your SQL servers in the DMZ, as I too, would consider this as a massive security issue.

    Typically the DMZ is outside of your firewall and internet facing this in itself for me is a no.

    We usually run on a 3 zone rule, DMZ, open (general user machines), closed (servers), there is a firewall between each zone and everything is VLAN'd, where we have to implicitly grant access on the firewalls to allow users or DMZ servers any access to the closed zone making it more secure.

    Would love to hear your thoughts on this.

  • The DMZ is a semi-secure area on your network. It's a buffer to your main network.

    The typical configuration is:

    Firewall -> DMZ subnet -> Firewall/router -> main network

    Putting a SQL Server on the DMZ makes some sense. It prevents any traffic from crossing to the main network. It can limit access for accounts that are hijacked. However if you have a SQL Server that has privileged information, you might put it on the main network (or another subnet), with only access to this server from specific machines in the DMZ to that server.

    It doens't necessarily become an issue to have SQL Server on the DMZ, but I wouldn't consider it the "most secure" place to put it.

  • My Apologies when I wrote DMZ is the safest place to put SQL Server. My mind read Work group instead of DMZ. My apologies again.:blush:

    What I meant was putting SQL Server in a Work group is the best way to do it.

    -Roy

  • Roy Ernest (12/2/2011)


    What I meant was putting SQL Server in a Work group is the best way to do it.

    With the DMZ comment I assumed there was something I was missing since I haven't dealt with DMZ's much. However, I'm missing completely how putting SQL in a work group as opposed to joined to a domain is better. My assumption is that the post (both original and what you're referring to) is about workgroup vs domain. If, like SQLRNNR and Steve addressed, this is about having SQL on the domain controller as opposed to on a different server but still joined to the domain then I completely understand that.

  • When you have a SQL Server in a domain, all power users have access to the OS of the server hosting SQL. If any of the these users get compromised, they can quite easily put that user as a Sysadmin into your database.

    In the case of having a SQL Server in work group, there will be only limited amount of local users created that have admin privilege. The power admin in a domian does not have unlimited access tot he Server in a work group.

    -Roy

Viewing 15 posts - 1 through 15 (of 15 total)

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