SQLServerCentral / Article Discussions / Article Discussions by Author / Discuss content posted by Duncan Pryde / Connection Problems / Latest Posts

RE: Connection Problems

Kenneth.Fisher — Fri, 11 Feb 2011 10:50:43 GMT

Good question. I appreciate the update of information. I use sp_change_users_login fairly frequently. I'll miss the report option though.

RE: Connection Problems

jts_2003 — Fri, 11 Feb 2011 09:42:18 GMT

Good question - we've been hit by this problem too and it can be a right pickle to sort out!

RE: Connection Problems

SQLRNNR — Tue, 08 Feb 2011 12:06:06 GMT

Thanks for the question

RE: Connection Problems

Duncan Pryde — Tue, 08 Feb 2011 11:18:34 GMT

[quote][b]marklegosz (2/8/2011)[/b][hr]Regarding SQL logins, I think the point here is to use them as a last resort when no other options are available.In a web server/db server example, you could only allow the web server to communicate with a 'data broker' https web service, and then use windows authentication to permit that broker to connect to the SQL database. You could then use a client cert to secure the data broker web service, and only load that cert into the account that runs your app pool, making sure your website is the only website in that app pool (IIS solution).But yeah with a vendor supplied solution you can often be left with no other option.[/quote]Interesting ideas, thanks. I'd never come across anyone doing it like that before, but it does make sense.

RE: Connection Problems

marklegosz — Tue, 08 Feb 2011 10:12:59 GMT

Regarding SQL logins, I think the point here is to use them as a last resort when no other options are available.In a web server/db server example, you could only allow the web server to communicate with a 'data broker' https web service, and then use windows authentication to permit that broker to connect to the SQL database. You could then use a client cert to secure the data broker web service, and only load that cert into the account that runs your app pool, making sure your website is the only website in that app pool (IIS solution).But yeah with a vendor supplied solution you can often be left with no other option.

RE: Connection Problems

Duncan Pryde — Mon, 07 Feb 2011 12:24:11 GMT

[quote][b]RichB (2/7/2011)[/b][hr]Ah, not the missing option of 'wtf are you using sql logins in production for anyway?'What with them being inherently, disgracefully insecure.For anyone that hasn't I strongly recommend using your favourite packet sniffer (wireshark for instance) to trace the local network while you log in with a sql login. Filter it for login packets... and watch in wonder as your password flies across the network in plain text! <_<[/quote]So what do you use when you've got an application on a standalone (non-domain) web server connecting to a DB server behind a firewall? Mirrored local accounts? I keep looking for decent ways to avoid using SQL logins in this scenario, but nothing I come up with seems to work as well or be as easy to maintain.

RE: Connection Problems

UMG Developer — Mon, 07 Feb 2011 11:55:09 GMT

[quote][b]RichB (2/7/2011)[/b][hr]For anyone that hasn't I strongly recommend using your favourite packet sniffer (wireshark for instance) to trace the local network while you log in with a sql login. Filter it for login packets... and watch in wonder as your password flies across the network in plain text! <_<[/quote]Is that true even if you are using encrypted connections?

RE: Connection Problems

sknox — Mon, 07 Feb 2011 11:39:30 GMT

[quote][b]SanDroid (2/7/2011)[/b][hr][quote][b]RichB (2/7/2011)[/b][hr]What with them being inherently, disgracefully insecure.[/quote]Are you talking about the fact that they have to be stored in plain text in connection strings that are at the Least a read only file for all users?[quote]Filter it for login packets... and watch in wonder as your password flies across the network in plain text! <_<[/quote]Ok, you are talking about the same limitation all network applications that use login packets to support application user logins stored in the application. SNMP, POP, SQL, FTP, NNTP, etc...IMHO: If your network security is so lax that just anyone can install and use a packet sniffer to get this data, there is not an application security issue. :w00t:[/quote]Yes there is. Just because you also have a network security issue doesn't mean that the application security issue can be ignored. That's why when possible you use secure versions of those protocols (usually the same protocol encrypted via SSH or SSL). Or you use alternative authentication mechanisms like Windows-based authentication with Kerberos as opposed to SQL user logins.Yes, we use some SQL logins here, but only when the application requires it and only after evaluating other options and mitigation opportunities. It is a serious security issue, and hiding it under network security issues does nobody any good.

RE: Connection Problems

SanDroid — Mon, 07 Feb 2011 11:31:33 GMT

[quote][b]RichB (2/7/2011)[/b][hr]What with them being inherently, disgracefully insecure.[/quote]Are you talking about the fact that they have to be stored in plain text in connection strings that are at the Least a read only file for all users?[quote]Filter it for login packets... and watch in wonder as your password flies across the network in plain text! <_<[/quote]Ok, you are talking about the same limitation all network applications that use login packets to support application user logins stored in the application. SNMP, POP, SQL, FTP, NNTP, etc...IMHO: If your network security is so lax that just anyone can install and use a packet sniffer to get this data, there is not an application security issue. :w00t:

RE: Connection Problems

UMG Developer — Mon, 07 Feb 2011 11:19:53 GMT

Thanks for the question, it is good to bring up the deprecation of features, and show the alternative.

RE: Connection Problems

Michael Poppers — Mon, 07 Feb 2011 11:08:30 GMT

[quote][b]Ronald H (2/7/2011)[/b][hr]Exactly a scenario that happens in our environments. Thanks for the question![/quote]Ditto x 2 :-).Re the question's phrasing and its choices: since its "you" can successfully connect to Dev using "MyUser", wouldn't the two choices which submit a <NewPassword> make no sense? I answered the question correctly, but I'm just wondering if the right answer could be chosen merely based on that type of analysis of the question. Thanks.

RE: Connection Problems

SanDroid — Mon, 07 Feb 2011 09:35:43 GMT

Nice question even if it was long winded. IMHO: Two points is a lot for a question that should be asked and answered correctly at any DBA interview.This was the first DBA incident I ever had to resolve professionaly. I even got a contract once because the DR plan for a fortune 500 company did not include fixing SQL logins once databases had been restored from Tape to a new server on new hardware in a new domain. FUN!:cool:

RE: Connection Problems

jeff.mason — Mon, 07 Feb 2011 09:04:57 GMT

[quote][b]RichB (2/7/2011)[/b][hr]Ah, not the missing option of 'wtf are you using sql logins in production for anyway?'What with them being inherently, disgracefully insecure.For anyone that hasn't I strongly recommend using your favourite packet sniffer (wireshark for instance) to trace the local network while you log in with a sql login. Filter it for login packets... and watch in wonder as your password flies across the network in plain text! <_<[/quote]As long as we have vendor apps, or we have people connecting from non-Windows sources, they will be a necessary evil....

RE: Connection Problems

RichB — Mon, 07 Feb 2011 09:01:45 GMT

Ah, not the missing option of 'wtf are you using sql logins in production for anyway?'What with them being inherently, disgracefully insecure.For anyone that hasn't I strongly recommend using your favourite packet sniffer (wireshark for instance) to trace the local network while you log in with a sql login. Filter it for login packets... and watch in wonder as your password flies across the network in plain text! <_<

RE: Connection Problems

Duncan Pryde — Mon, 07 Feb 2011 08:58:21 GMT

[quote][b]getoffmyfoot (2/7/2011)[/b][hr]Such a bummer to me that the sp_change_users_login option is going to be phased out without a "decent" alternative - consider the scenario that exists in my environment where there lots of sql server logins, and (esp. in dev), you don't document the passwords for them, which makes the ALTER USER solution difficult to pull off. Plus, using sp_change_users_login 'Report' lets you see specifically which users are orphaned before you dive into trying to fix them.[/quote]You don't need the password of the login in order to use ALTER USER. But I agree the report option is pretty handy. Without that you'd need to run the actual SQL statement that sp_change_users_login uses:[code="sql"]select UserName = name, UserSID = sid from sysusers where issqluser = 1 and (sid is not null and sid <> 0x0) and (len(sid) <= 16) and suser_sname(sid) is null order by name[/code]

RE: Connection Problems

Surii — Mon, 07 Feb 2011 08:48:12 GMT

Nice question.. And thats exactly a perfect example before reading about Contained Databases in sql server "Denali".

RE: Connection Problems

Brandie Tarvin — Mon, 07 Feb 2011 08:47:32 GMT

I have to agree. I like being able to cursor through the proc, having all the orphaned users fixed automatically without any typing. I just open up my saved cursor, execute it, and everything gets fixed.

RE: Connection Problems

getoffmyfoot — Mon, 07 Feb 2011 08:44:41 GMT

Such a bummer to me that the sp_change_users_login option is going to be phased out without a "decent" alternative - consider the scenario that exists in my environment where there lots of sql server logins, and (esp. in dev), you don't document the passwords for them, which makes the ALTER USER solution difficult to pull off. Plus, using sp_change_users_login 'Report' lets you see specifically which users are orphaned before you dive into trying to fix them.

RE: Connection Problems

jeff.mason — Mon, 07 Feb 2011 07:24:35 GMT

I knew exactly what the problem was and could not find sp_change_users_login, so I read the answers to decide which tried to do the same thing and got it correct. To me the value of the question is to educate that the old way we did it is going away.And as for making the SID identical, well, yeah, this would be the IDEAL way to do it but in the real world, you won't always be administering servers you yourself set up if you get my drift. Always need to know your options.

RE: Connection Problems

Abi Chapagai — Mon, 07 Feb 2011 06:53:01 GMT

Good Question. These type of questions will help all of us bursh up our knowledge every day. Thank you again!!!

RE: Connection Problems

rmechaber — Mon, 07 Feb 2011 06:45:53 GMT

Great question, thanks.Minor clarification: the 2 hyperlinks listed at the bottom of the explanation didn't contain a notification about future deprecation of the SP (not that I could find, anyway).That note [u]is[/u] present on the page for sp_change_users_login at [url=http://msdn.microsoft.com/en-us/library/ms174378.aspx]this location[/url].Rich

RE: Connection Problems

Brandie Tarvin — Mon, 07 Feb 2011 06:34:45 GMT

[quote][b]Hugo Kornelis (2/7/2011)[/b][hr][quote][b]Toreador (2/7/2011)[/b][hr]I wonder why they are withrawing this procedure?[/quote]If I have to make a guess, it is probably because over the past years, there has been a consistent move away from stored procedures toward "real" SQL syntax. [/quote]Real SQL? Why in heavens name would any of us want to use "real" SQL? (And does it taste better than the genuine fake SQL?) :w00t:

RE: Connection Problems

Brandie Tarvin — Mon, 07 Feb 2011 06:32:34 GMT

[quote][b]Toreador (2/7/2011)[/b][hr]I always use sp_change_users_login in these circumstances...[/quote]Ditto. I did get the correct answer, but that's not been my first choice of resolution in these instances.[quote][b]Toreador (2/7/2011)[/b][hr]I wonder why they are withrawing this procedure? Anyone know if the replacement command does all the security checking that the procedure does?[/quote]And ditto again. I didn't realize (until I checked BOL) that this was deprecated. I haven't read page 2 of this thread yet, so if someone's already answered these questions, thank you. If the questions haven't been answered, could someone enlighten us?

RE: Connection Problems

Hugo Kornelis — Mon, 07 Feb 2011 05:52:28 GMT

[quote][b]Toreador (2/7/2011)[/b][hr]I wonder why they are withrawing this procedure?[/quote]If I have to make a guess, it is probably because over the past years, there has been a consistent move away from stored procedures toward "real" SQL syntax. In SQL Server 2000 (IIRC), CREATE USER, ALTER USER, and DROP USER did not exist at all; there were stored procs for that as well. One by one, the old stored procs are being replaced.

RE: Connection Problems

DugyC — Mon, 07 Feb 2011 03:21:50 GMT

I thought "yeah I know this one, I've had this problem, don't even need to look it up"... but I guess with 71% getting it right it's quite a common issue.Great question, nice start to the week. Cheers :-D

RE: Connection Problems

Duncan Pryde — Mon, 07 Feb 2011 03:05:24 GMT

[quote][b]Nils Gustav Stråbø (2/7/2011)[/b][hr]What security checking does sp_change_users_login do?All it does is map a database user with a login. BOL says nothing about any security checking.[/quote]It does some checks on the user that is running the procedure. If it's not a member of the db_owner group it won't let you report or update one, and if the user isn't a member of sysadmin it won't let you auto fix.

RE: Connection Problems

Duncan Pryde — Mon, 07 Feb 2011 03:01:35 GMT

[quote][b]Toreador (2/7/2011)[/b][hr]sp_helptext[sp_change_users_login] will reveal all :-)[/quote]Presumably the permissions on ALTER USER will perform the required security checks on whether the user has permission to perform the action. The sp_change_users_login does seem to do quite a lot, but apart from listing the orphaned users in a database it should be possible to do everything with CREATE LOGIN and ALTER USER.

RE: Connection Problems

L' Eomot Inversé — Mon, 07 Feb 2011 02:36:58 GMT

Nice question, but very easy indeed for those of us who have been moving databases from server to server for more than a decade.

RE: Connection Problems

Toreador — Mon, 07 Feb 2011 02:27:55 GMT

sp_helptext[sp_change_users_login] will reveal all :-)

RE: Connection Problems

Nils Gustav Stråbø — Mon, 07 Feb 2011 02:24:43 GMT

What security checking does sp_change_users_login do?All it does is map a database user with a login. BOL says nothing about any security checking.

RE: Connection Problems

Toreador — Mon, 07 Feb 2011 02:15:44 GMT

I always use sp_change_users_login in these circumstances, so had to pick an answer at random, luckily I got the right one :).I wonder why they are withrawing this procedure? Anyone know if the replacement command does all the security checking that the procedure does?

RE: Connection Problems

Duncan Pryde — Mon, 07 Feb 2011 01:36:44 GMT

Thanks for the kind comments everyone - this was my first question, so it's good to get a positive response!And thanks Carlo for the extra information - I wasn't previously aware you could do that.

RE: Connection Problems

Ronald H — Mon, 07 Feb 2011 01:20:25 GMT

Exactly a scenario that happens in our environments. Thanks for the question!

RE: Connection Problems

Carlo Romagnano — Mon, 07 Feb 2011 01:16:38 GMT

This is an old problem with sql2000 too: restoring a database on a different instance, logins to database become invalid.The solution is create login on the restoring instance with the same sid of the source instanceSee here: http://msdn.microsoft.com/en-us/library/ms189751.aspx[code="sql"]CREATE LOGIN loginName { WITH <option_list1> | FROM <sources> }<option_list1> ::= PASSWORD = { 'password' | hashed_password HASHED } [ MUST_CHANGE ] [ , <option_list2> [ ,... ] ]<option_list2> ::= [b] SID = sid[/b] | DEFAULT_DATABASE = database | DEFAULT_LANGUAGE = language | CHECK_EXPIRATION = { ON | OFF} | CHECK_POLICY = { ON | OFF} | CREDENTIAL = credential_name <sources> ::= WINDOWS [ WITH <windows_options>[ ,... ] ] | CERTIFICATE certname | ASYMMETRIC KEY asym_key_name<windows_options> ::= DEFAULT_DATABASE = database | DEFAULT_LANGUAGE = language[/code]

RE: Connection Problems

michael.kaufmann — Mon, 07 Feb 2011 00:53:27 GMT

Thank you very much for this question and scenario--and for the update regarding the [b]sp_change_users_login[/b] stored procedure.Regards,Michael

RE: Connection Problems

Koen Verbeeck — Sun, 06 Feb 2011 23:58:39 GMT

Great question, thanks!

RE: Connection Problems

tejaswini.patil — Sun, 06 Feb 2011 23:01:30 GMT

Good question.:-)

RE: Connection Problems

SQL-DBA-01 — Sun, 06 Feb 2011 14:17:26 GMT

Good Question.

RE: Connection Problems

mohammed moinudheen — Sun, 06 Feb 2011 11:03:20 GMT

Very good scenario based question.

Connection Problems

Duncan Pryde — Sun, 06 Feb 2011 07:24:05 GMT

Comments posted to this topic are about the item [B]Connection Problems[/B]