Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I have a SQL Server instance that runs 5 scheduled tasks each night, each of which run SSIS packages.

These packages have been running for years and the associated steps run via a Proxy Account (PackageExecutor). PackageExecuter is associated with a SQL Credential that was a former domain admin account.

Soon, the domain associated with this admin account is going to be shutdown. I have to use a new account, on a new domain, as the admin account associated with my roxy, PackageExecutor. When I created a new Credential for the new Admin account and associated it with PackageExecutor, I started to get the following error when I tried to run one of my SQL jobs as a test:

Unable to start execution of step 1 (reason: Error authenticating
proxy *Domain\Admin_Account*@*fully.qualified.domain.com*, system
error: Logon failure: unknown user name or bad password.).  The step
failed.

If I'm understanding this reasonably explicit error, what it's telling me is that the Credential accounts, associated with my proxy is in correct. How do I validate this?

I know that this account is legitimate-- I've already associated it with every associated server group, I've made it a sysadmin user on the server.

What could be causing this problem?

To be clear, I haven't mis-typed the account name or the password associated with the Proxy Credential. However, when I entered the account name Domain\Admin_Account and clicked the Check Names button, SQL Server automatically transformed the User ID to the fully-qualified version. I'm not sure if this has anything to do with this problem.

I'm at a bit of a loss. I've given my credential account full access to everything that I can think of. What might I need to do to get this to work?

UPDATE

Sorry, one more quick mention. I've found this MSDN kb article. Resolution method #1 is what I've been doing for years. The others don't seem to apply, or I'm missing something. Any tips or clarification would be beneficial.

share|improve this question
    
Try using DOMAIN\Admin_Account (as you typed it) for the credential identity and see what happens. –  Jon Seigel Jul 24 '12 at 15:33
    
If I double-click on the Credential and remove the @domain.blah.blah.blah.com portion, it will save/accept the credential, but when I execute the package, I get the same response as mentioned above, accept, the name of the account in the error message has changed to reflect my removal of the @domain.com. –  RLH Jul 24 '12 at 15:37
    
You probably saw my comment edit -- I realized that Management Studio will accept anything for the identity and password. It doesn't get validated until something uses it. –  Jon Seigel Jul 24 '12 at 15:40
    
Is there any other way of validating it. Maybe some way of checking it and getting a more explicit or appropriate error? –  RLH Jul 24 '12 at 15:41
    
I believe I have solved this problem but I don't know why. If this makes sense (@Jon Seigel) feel free to post an answer explaining what's going on. Otherwise, tomorrow after the scheduled tasks exec, I'll post an answer regarding my discovery. In short, instead of using SSMS on my PC, I remoted into the server logging in with the account associated with the new credential. I removed the cred, created it again (this time SS didn't at the @domain.com) and then I attempted a test execution of one of the jobs. It worked?! Apparently this changed something and helped SS resolve the account. –  RLH Jul 24 '12 at 15:59

2 Answers 2

Just in case others have gotten here for the same reason. Make sure that the account your proxy/credential is using is a user in its default database in SQL Security.

We went through all the other suggestions (checking that the password hasn't changed, switching to a local service acct for SQL Agent User, rebuilding the credentials and proxy, etc.) and until we made sure the account was a user in its default DB, for some reason, that was causing it to pass a Null SID when it was trying to authenticate to AD.

share|improve this answer

I doubt there are many people that will make the same mistake as I did...

I was connected in Management Studio to the wrong server, so I kept typing in the username and password and getting this error. I was actually setting up the job on the wrong server too.

So double check the SQL Server instance you're connected to, is the one on which the credential exists.

share|improve this answer
    
This is really a low chance to occure ) Triple triple chech it ) –  Johnny_D Dec 13 '13 at 8:24

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.