Domain Model

• 
  Hi Andrew,
  
  Thanks for your question. You're quite right, the Beta version of SQL Response does assume that you have such a login, and that all SQL Servers are on the same domain.
  
  Customers monitoring multiple domains can of course install one Incident Repository per domain, and connect to them sequentially using a single client.
  
  However, it sounds like your requirements are rather different. If SQL Response were to permit the user to specify a different Windows login for each server, would that satisfy your requirements? Or is Windows authentication not feasible between the Incident Repository computer and the monitored SQL Servers? If not on the same domain, are they on the same LAN? Are any protocols other than SQL communication open?
  
  All the best,
  
  Dan Archer
  Red Gate Software

  Dan J Archer February 06, 2008 07:27

  - 0 +
• 
  Dan
  
  Unfortunately, we're talking TDS over the internet to a designated port. On SQL Server 2005, we can create an endpoint that gives us an encrypted link since SQL Server authentication requires the password to go flying through the ether in plain view. (gulp). In a well-ordered universe there will be VPN access to the remote network, but I've yet to meet a SysAdmin who is capable of setting this up.
  
  There are ways of surviving, of course, and I can use all other Red-Gate tools remotely via TDS and SQL Server Authentication, as well as SMO. I can generallly get SNMP info and I can get Whatsup to poll information from an administration page in the public-facing website of the application in order to get alerts for serious problems. (Like, Death is a serious problem) I can get alerted into a catatonic state via Email-based SQL Server alerts, plus scheduled status reports.
  
  I may need to kill a Sysadmin or two before I can get an internet-facing socket through a firewall for the Incident Repository, unless I can provide elaborate justification to prove that an exploit is impossible.
  
  All these problems would be solved if one could set up a remote process that communicated to the repository via a webservice, or the like. I realise that this might upset the occasional DBA but normally these remote databases are serving public-facing sites, or have webservices set up anyway. They tend to be remote from your domain because they are as near as possible to the Internet backbone for bandwidth purposes. Besides which, Reporting Services has changed the DBA mindset towards WebServices. They're cool now.
  
  Andrew

  AndrewRMClarke February 06, 2008 08:18

  - 0 +
• 
  I would agree that the software must necessarily provide the ability specify a different Windows loing for each server as an option. We don't use SQL Server authentication, although I imagine there are other who are still forced to by vendors, legacy code, or poor judgement.

  broughtie February 06, 2008 10:17

  - 0 +
• 
  This is a very interesting discussion. I'd be very interested to know what configurations are typical for our customers, so if you do have issues in this area, or would like to comment further, please do. We definitely want to make it as workable as possible for people to use this tool the way they need to.

  Dan J Archer February 11, 2008 10:26

  - 0 +
• 
  We have a similar situation at my company; servers in different domains that need to be authenticated through their OWN process.
  
  I think what would be good is to provide for the ability to log in as:

  Username: DOMAIN\uname
  Password: pword
  

  That way, we could have everything monitored through the same incident server and not have to worry about chaining them together.
  
  Thanks!
  -Jim

  JTPanther February 12, 2008 12:44

  - 0 +
• 
  None of the production servers I administer are within my domain. I can't remember when I've been that lucky. Where a server is running a popular website, for example, we put it as close to the internet backbone as we can, in order to minimise connectivity costs, and that usually involves a managed service that is remote from the Windows Domain. Sometimes these servers are in predominately Linux environments. I once had to keep a check on intelligent telephony switches that had SQL Server 'embedded' in them. These certainly weren't connected to a windows network!
  
  I've worked in several places where the SysAdmins have identified the practice of making SQL Servers part of the domain as being a security risk, and there have been several instances where this has led to problems.
  
  If I've just been exceptionally unlucky in having to work outside the domain model, then I'll shut up. After all, I'm not short of ways of monitoring the health of my servers.

  AndrewRMClarke February 14, 2008 07:19

  - 0 +

Add comment

Please sign in to leave a comment.