Hello,

I'm having trouble running jobs with my active directory (ADS) account. I've setup my SQL services to run under an ADS account, but jobs cannot seem to query ADS for user information. We're running Windows Server 2003 and SQL Server 2005 SP2.

Here is the error message:

==

The job failed. Unable to determine if the owner (ADS\me) of job eFASRtest has server access (reason: Could not obtain information about Windows NT group/user 'ADS\me', error code 0x5. [SQLSTATE 42000] (Error 15404)).

==

also this message in log:

==

[298] SQLServer Error: 15404, Could not obtain information about Windows NT group/user 'ADS\me, error code 0x5. [SQLSTATE 42000] (ConnIsLoginSysAdmin)

==

I already tested the suggested:

execute as login='ads\me' and I get the same error on both (my local installations and production)

appreciate your help

Which service account is the SQL Server running with ?

Jens K. Suessmeyer

---
http://www.sqlserver2005.de
---

We are using the Local system account

Most likely the machine account doesnt have permission to query the AD.

I would recommend requesting access to the AD administrator or change SQL Server and run the service as a low-privileged domain account that has proper permissions on the AD.

-Raul Garcia

SDE/T

SQL Server Engine

Yes, as Raul mentioned, the Local Service does not have any rights to query / check the identity of the connecting user.

Jens K. Suessmeyer

---

http://www.sqlserver2005.de

---

Which kind of permissions this account needs?

• Proposed as answer by marxbiker Monday, September 19, 2011 3:14 PM

Members of the Domain should be enough.

Jens K. Suessmeyer

---
http://www.sqlserver2005.de
----

I have been receiving the same error - only intermittently. Popped up after installing SP2 on SQL 2005. For example a job that runs every ten minutes failed at 6:10, worked until 7:30 and then failed. Received the same error on both - Unable to determine if the owner of job... has server access (reason: Could not obtain information about Windows NT group/user 'ad\user', error code 0xea [SQLSTATE 42000] (Error 15404)

The ad account had administrator access on the server and in SQL. The service account also has administrator access.

Thanks for any help,

Sandy

Hi.

In the company I'm working for we are planning to move from SQL Server 2000 to SQL Server 2005 but in our test environment we have the same problem. We are using a single Windows Server 2003 Active Directory. The SQL Server ist run with a standard domain user account (DOMAIN\sqlserver) without any special permissions or restrictions.

I am not able to run any scheduled job or any maintenance plan manually with my domain user account. My domain account is member of the SQL Server's host's administrators group and member of each admin group inside the SQL Server. The scheduled jobs are working fine if I set their owner to sa but that's not possible for the manually run maintenance jobs. The SQL Server is set to Windows authentication only.

If I add DOMAIN\sqlserver to the Domain Admins group of the Active Directory everything works fine. But this solution is inacceptable. What permissions does the service account need to access the Active Directory to check the permissions of a domain user?

Kind regards

Kay Zumbusch

Hi Sandy

My Maintenance Plan for backups stopped working after some security patching. Same error message. Did you ever resolve your issue?

Thanks

Ruth

I'm seeing the same issue within reporting services with schedule reports (which creates jobs withinsql server agent). It creates the job fine, but I get the same error as listed in this forum when it tries to execute. The User is a domain user. The only work around I have is after someone creates a scheduled report to update the sql agent job with a different owner. I'd like to not have to do this, so has anyone found a real solution?

Thanks,

Sean

This is still an issue in SQL Server 2005 SP3+ (9.0.4035 in my case).

I'll be very interested when/if Microsoft comes up with a workable solution.

Most likely this is being caused by a lack of permissions. And it didn't seem to be resolved with a definitive answer. If you see this error try adding the DOMAIN\SQLSERVER machine account to the pre-windows 2000 access group. This may not solve the problem for everyone, but did for me.

I had this problem and found that, if I created the maintenance plan while authenticated to the Management Studio as a user of the same domain that the SQL Server was running on, the maintenance plan was successful; even if I then modified it while logged on as a user of another domain.

A little further info - my machine (the one I run Management Studio on) is logged on as domainA\username1. The SQL Server I am connecting to is running in domainB. I can connect with domainA\username1 because it is set as an administrator on the SQL Server machine. However, when I create a new maintenance plan while logged in as domainA\username1, I get this problem. I tried 'EXEC AS' and creating a new connection that used SQL Server authentication, but to no avail.

I then added domainB\username2 as an admin on the SQL Server machine, logged into that machine and created a maintenance plan that worked. I also found that, going back to my machine and logging in as domainA\username1, I could modify the maintenance plan and it still worked.

Good luck

This same error has started cropping up in several of my production servers:

The job failed. Unable to determine if the owner (AMERICAS\$svcpnbsqlprod001) of job UDMaintenancePlan.DBA-Trans Log Backup for All User Databases has server access (reason: Could not obtain information about Windows NT group/user 'AMERICAS\$svcpnbsqlprod001', error code 0x5. [SQLSTATE 42000] (Error 15404)).

This is our production service account which is used for the Logon Account for both the Database Engine and Agent services. It has Local Server SysAdmin privileges on the box, and SysAdmin privileges on the SQL instance, and it is not locked out at the Active Directory level. Nothing has changes with these accounts at the local level, and these jobs have been running without error for 18+ months. I can only assume that something at the AD level has changed, but when I looked at the account settings using the AD Users & Computers MSC I saw nothing out of the ordinary.

I've been researching this error and have found several forum messages describing the issue in different contexts, but I haven't come across any solutions yet. Has anyone encountered this problem and found a viable solution?

Brandon.Forest@hp.com
Senior SQL Server DBA

I have a similar problem:

"Unable to determine if the owner (sa) of job eBlast Engine Check for Audiences to Sync has server access."

I had restarted one of my 3 local AD domain controllers yesterday and after that all SQL Agent Jobs I have started failing with an error similar to this.
I restarted the SQL Agent Service and now it's all working again.

The issue seems to be if connectivity is lost to a AD Domain Controller it loses it's ability to authenticate users for the SQL Agent Jobs.

My expected behavior would be that worst case the SQL Agent Jobs would fail until the AD Domain Controller is available again... then it should automatically start working again.

-Phil

Any Ideas on a fix???

**** THE ANSWER ****

I have just had the same problem. I have read all over the internet about this but it took our IT engineer who knows about SQL Server and AD to point out that I had set the SQL Agent to use a domain account but it was acutally the SQL Server service that brokers the requests to AD.

To resolve this problem, ensure that the SQL Server service account under "" is running under a domain user account.

I believe you can leave the SQL Agent running under a restricted local server account.

This enables you to run jobs that are owned by a domain account and so they should be able to access network resources.

Regards

Peter

Liverpool PCT, NHS, England

• Proposed as answer by Jonas Andersson [MCITP] Tuesday, May 15, 2012 4:21 PM

For future readers of this problem, another possible cause is if the account trying to execute a job is locked out.

 

• Proposed as answer by asesx Monday, December 03, 2012 2:20 PM

Also note for this very similar error:

SQLServer Error: 15404, Could not obtain information about Windows NT group/user 'Domain\Admin', error code 0x37. [SQLSTATE 42000] (ConnIsLoginSysAdmin)

the ownership of the job and maintenance plan must be correct.  See http://www.sqlservercentral.com/articles/SQL+Jobs/68764/ for more info.

In this case, you can create a job with the SQL agent service account as job owner and JOb steps can use AD account to run the job steps. This will resolve the problem.

Hi All,

It's probably permissions' problem. The best way to solve this is detecting which account under Security\Logins that has the db_owner permissions and map it to a user with enough permissions to perform the backups. That is for specific database you need to backup, probably the account permissions is changed if it's local, can be due to some application update or new install.

To solve the problem, the best of practice is mapping the account with db_owner to a local account with enough permissions (if backup is local) or to a domain backup operator (if backup is remote or network).

Hopefully that helps!

I had the same issue.

Looks like the security patching needed a reboot. As the domain control was restarded the same time for the same reasons (more or less), The SQL SERVER couldn't make the link with AD and wasn't able to mount it after time.

A simple reboot of the SQL SERVER and all came back working again.

So try first to do a simple reboot of your SQL SERVER before making any change in configuration (specially if it was working before) and try to avoid rebooting Domain Controler and other Server on the same time.

• Proposed as answer by Sony S4 1 hour 20 minutes ago

Stop SQL Server & SQL Server Agent services and Start  with  "Local System Account" or Windows AD account instead of    "NT Service\MSSQLserver".

• Proposed as answer by Sony S4 1 hour 13 minutes ago