 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
SQL Server Forum / DB Engine / SQL Server / July 2008Proxy Credentials Frustration
Please let me know I'm not crazy. I have a NAS that I want to back up to. It has a user account, we'll call him Bob. Lets say I have a folder \\NAS\Backuphere\ which, if I'm logged into my computer as "bob" with the same password that bob has on the NAS, I can get to the share just fine. In SQL I can't backup to that share directly but I want to be able to backup to it by using a proxy on ssis package. I create a proxy with the username and password for bob but it still fails. I've given the bob proxy as much rights as I can, but it seems it's not using that account for the remote login to the share. Thoughts? Please please help. Thanks! Jeff Jeff: In order to create the Proxy, you first set up the Credentials for "Bob", yes? You may need to verify his password. If it's not right, he won't be able do do anything. When you say "Bob" has as much rights as you can give him, how high up did you make him? sysadmin would do it. Are you trying to execute the SSIS Package from SQL Agent? If so, are you selecting Run AS in the JoStep setup? Keep us posted  SignatureTodd C > Please let me know I'm not crazy. > I have a NAS that I want to back up to. It has a user account, we'll [quoted text clipped - 11 lines] > Thanks! > Jeff > Jeff: > In order to create the Proxy, you first set up the Credentials for "Bob", [quoted text clipped - 29 lines] > > - Show quoted text - Credentials made, yes, same password, yes sys admin in the proxy and just about every thing but deny data reader / deny data writer- probably more then just those two, but really almost everything. Yes, agent is running the ssis package in a job, yes the step was run as "bob". Works if the target for the backup is local, but not remote and I double checked all passwords. It's like "credentials" and "proxys" don't apply to - pass through to - network share permissions. If everything is correct, then it has to be a permissions issue. If you have the rights to do so, try these techniques: 1) Grant rights on the backup folder location to EVERYONE, Full Control. Then run the job from SQL Agent. Does the job succeed? (Remember to remove the EVERYONE permissions afterward!) 2) Create a Cerdentials and Proxy with some all-powerful account like Domain Admin if you can. Run the Job Step with that new Proxy. Does the job succeed? (delete the proxy when finished) If the job succeeds under either of these two scenarios, then it is permission based. SignatureTodd C > > Jeff: > > In order to create the Proxy, you first set up the Credentials for "Bob", [quoted text clipped - 37 lines] > and I double checked all passwords. It's like "credentials" and > "proxys" don't apply to - pass through to - network share permissions. > If everything is correct, then it has to be a permissions issue. > [quoted text clipped - 57 lines] > > - Show quoted text - Not to sound stupid, but can you verify you can do this. The NAS is NOT active directory based. It's works for everything else by just using the active logged in credentials- i.e. as long as you're using a login that is the same username and it has the same password- it just works. Can you try to set up some similiar test on your end. Backing up to a folder that is shared and has permissions of only "local" users- given that the usernames and passwords are the same. (This also takes AD out of the equation). Thanks, and I'll try your suggestions to narrow this down too. Jeff Jeff: Oooh, sorry. Yes, I saw the initial post mentioning NAS but assumed that its access was controlled by a standard ACL in AD. My suggestions were based soley on my experiences with File System storage. I don't know how NAS permissions work. I don't have access to our NAS to run tests. When you fire off a SQL Agent Job from Management Studio, i think you can see some notes about "Executing as ..." You may need to grant some permissions to the SQL Agent Startup account. Just a suggestion. Wish I could be of more help. Sorry. ------- Todd C > Not to sound stupid, but can you verify you can do this. The NAS is > NOT active directory based. It's works for everything else by just [quoted text clipped - 6 lines] > Thanks, and I'll try your suggestions to narrow this down too. > Jeff > Jeff: > Oooh, sorry. Yes, I saw the initial post mentioning NAS but assumed that its [quoted text clipped - 24 lines] > > - Show quoted text - You could simulate with a share on any system that is only given permissions to a local user account rather then a domain account. I'm off to try your suggestions now. Thanks again. Jeff On Jul 3, 9:41 am, ujjc...@gmail.com wrote: > > Jeff: > > Oooh, sorry. Yes, I saw the initial post mentioning NAS but assumed that its [quoted text clipped - 32 lines] > > - Show quoted text - Well, I have tried everything- this was very very annoying. I was finally able to get it to work by actually changing the account sql server runs with, not just the agent even. Here's what I tried: NAS with no AD support, shared folder with a user on the nas "bob" with password "bobpass". Local user on the SQL server with same username and password. Admin on local machine. With windows explorer bob has full access to the shared folder. In SQL with bob logged into the local machine and sql with windows login, bob is unable to backup to the share. Made credentials for the bob account and an ssis proxy (with all max principles to help) for bob- tried the backup as a job, with bob run as for the step. Still no go. Tried to change the agent to use bob, still no go. Had to change the SQL Server service to Bob to make it finally work. So, what use is a "RUN AS" proxy for an SSIS Package trying to gain access to network shares? Jeff |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.