I have a situation where I need to determine the password of a database user in SQL Server 2008 (not R2, just regular 2008). It is a native SQL Server account, and has no password restrictions / policies assigned to it. I have full sysadmin access on the SQL Server already; under normal circumstances I would simply reset the password for this user (it is NOT the sa user) to a known value, however the account is used for a variety of processes as is, and cannot be changed; unfortunately, the existing password was not documented anywhere, and nobody knows what it is.
I have found a number of different ways to do this in SQL Server 2000 and SQL Server 2005, but none of them appear to work in SQL Server 2008. Note, the user is indeed active, and in fact its credentials are actually saved in the SQL Server Management Studio, where I can log in with the SQL Server user whose password I need to obtain -- so, I know that the account is good. I just need to find out what the password is! :P
Thanks very much!
I'm afraid the official position is to reset the password, which I know you don't want to do. Beyond that I believe you're stuck trying out 3rd party applications that claim to have this ability, but none guarantee success. Of course, passwords are supposed to be hard to discover...
Related
I try to write a simple sql server agent job to run daily. The sql statement is as follows:
insert into testtable (nt_username, last_batch)
select nt_username, last_batch from master.sys.sysprocesses where nt_username <> ''
The same sql statement works great if I run it in management studio. But it only returns one record something like:
Administrator 2016-07-14 13:07:08.270
when it runs as a sql server agent job. As a result, it is useless. What did I do wrong and how to fix it? What is the correct sql statement for the same result that works as a sql agent job? My sql server is sql 2008 R2 with service pack 2 (10.50.4000) running on windows server 2008.
Thanks.
After some careful examination, it turns out the culprit is that the sql server agent process must be run under a domain account. I encountered the problem because it run under network service account. The weird part is the sql server also runs under the same network service account with no problems. What a headache this is especially when you are in a hurry to just get a thing to work.
Please do not use sysprocesses. It was deprecated when SQL Server 2005 was released, and the sys.sysprocesses "table" you are using is just a compatibility view. The MSDN page for sys.sysprocesses even has a note at the top stating:
This SQL Server 2000 system table is included as a view for backward compatibility. We recommend that you use the current SQL Server system views instead. To find the equivalent system view or views, see Mapping System Tables to System Views (Transact-SQL). This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature.
You should instead use the new DMV (Dynamic Management Views):
sys.dm_exec_sessions
sys.dm_exec_requests
sys.dm_exec_connections
Please note that a Login might need to be granted the server-level permission of VIEW SERVER STATE in order to see more than their own data for sys.dm_exec_sessions and sys.dm_exec_requests, or see anything at all in sys.dm_exec_connections.
If this permission is needed, then the current database when you run the GRANT statement needs to be master as this is a server-level permission.
I am installing TFS2010. There is a separate Application Tier server and Database Tier server. I am using an already existing database, called Tfs_Configuration. When entering the database name/instance name I am able to test it and obtain the green check-mark so TFS can find the database. The version of SQL server I am connecting to is - SQL Server 2008 SP3. But when I run the readiness tests I get the following messages-
First are those two warning causing the error?
Also, I have db_owner rights to the existing database (Tfs_Configuration) that I am connecting to. What other rights do I need? And what can I do to resolve these issues?
The first error suggests you need the sysadmin role which is in fact a SQL Server role which can be enabled by doing the following:http://blog.sqlauthority.com/2008/12/27/sql-server-add-any-user-to-sysadmin-role-add-users-to-system-roles/
Hope that moves you past at least one error.
You need to be Sysadmin of the SQL instance or a role that is able to create new databases, because the installer wants to create an additional database for the DefaultCollection (and the TFS_Warehouse, TFS_Analysis). Therefore it is not enough to be the owner of TFS_Configuration.
I am trying to create a set of users in Sql server 2008 SP1 with access to database for any specific time say 12:00AM to 6:00AM . If that user try to access the database before 12:00AM or after 6:00AM the access shall be denied is there any inbuild feature for user management available.
Thanks,
Atul
You can create a logon trigger that denies them the ability to connect to between those times, but there's no simple way to cut off their access if they stay longer than desired.
One ugly way to do it would be to examine all connections at 6 am, and for those coming from people you no longer want connected, issuing a KILL command. But that would be a very "abrupt" experience for those users - any transactions that were still in progress at that time would be rolled back.
Can you tell how your clients are connecting to you database ? I think it would be easier to implement logon restrictions to the front end of the system.
I'm trying to connect to our SQL Server box from our web server. The only thing i've been able to find regarding the issue is to enable tcp/ip and mixed authentication.
TCP/IP is already enabled
Mixed authentication mode is selected
we already have 1 user successfully connecting to a different database so I know TCP/IP and mixed authentication are working.
Logging in as the problem user from sql manager works fine.
I get the same error creating an ODBC connection as well as a ColdFusion SQL Server data source.
According to the log files, which isn't logging all the attempts also indicates State 40, which is "Default database could not be accessed (SQL 2008)."
I've check and the default database is the one I want to open. The Schema is DBO.
Any help would be appreciated.
Make sure your user password not longer than 16 characters.
I apologize for not answering this sooner. To be honest I completely forgot about the question until I got a 'Notable Question' badge from it. Unfortunately, I'm afraid it won't help anyone as the problem was caused due to bad information from the network admins. They moved our SQL server to another box but did not shut down the old instance. Essentially, they gave me the old IP to connect to. Once I got the correct IP to the new box everything worked perfectly. The user I thought was connecting was an older account that was already established prior to the 'move' so the account existed on the old box.
If your box has multiple IP's on it, make sure the Cold Fusion server's IP address (that it's binded to) is allowed access to the SQL box. I've come across this problem in the past. I don't know if you're using a firewall or not to restrict access...but this was a problem I've encountered in the past.
I'm trying to use Sam Saffron's program SoSlow (as suggested here) for importing SO's data sump into MS SQL Server 2008.
Unfortunately, I have little idea of what I'm doing, and so do not know the Connection String that the program asks for.
I have tried the following syntax:
Data Source=SHIMI\SQLEXPRESS; Initial Catalog=SO; User Id=sa; Password=;
where SHIMI is the name of my machine, and SO is the name of the DB I've created.
SoSlow announces that the login fails "Login failed for user 'sa'".
Tried all other logins that are listed through the object browser in SQL Server Management Studio > Security > logins.
I have not altered the server in any way since install, defaults apply.
What am I doing wrong? (besides asking noob questions)
Thanks!
You would have set an SA password during the installation of SQL Server Express - if you don't recall it you will need to reset it. Follow the steps here to reset.