January 15, 2008 at 8:42 am
Comments posted to this topic are about the item You are a SQL Server developer who is...
November 15, 2011 at 12:27 pm
I don't agree with this answer at all. Partly because I would never dream of shipping a file with real live passwords in it, partly because I believe that it's likely that the developer doesn't even know what the password is for the SQL username (if he even knows that SQL username) that the client is going to use.
I don't much like the statement in the explanation that the solution is to use integrated authentication. That involves setting up trusts between the client domain and the server domain, unless client and server happen to be in the same domain. If they are in the same domain or have such trust relationships, someone at the client can log into the server (using remote desktop over a secure VPN) and download the DLU file, so the transfer can be perfectly secure: integrated authentication isn't actually needed when it's possible; and if they aren't, integrated authentication won't work anyway - it's only potentially useful when it isn't possible.
Yes, integrated authentication would be preferable if the necessary trusts are there; but then the developer can't test with the right usename, because he surely isn't going to have the password for an NT login used by someone at a remote client site. Anyway, what's the problem with shipping the DLU files with a dummy username and password which definitely won't work - that should be tested before shipping - in the case where the trusts between the domains don't exist and letting the remote client supply an SQL username and password by editing the DLU text. Shipping real live username and password in a DLU file would be just plain insanity, the developer should be able to have confidence that the people responsible for deployment are not stupid enough to commit such an error.
Tom
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply