The job failed unable to determine if the owner error 15404

The job failed unable to determine if the owner error 15404

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

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

Answers

Most likely the machine account doesn’t 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.

SQL Server Engine

All replies

Which service account is the SQL Server running with ?

Jens K. Suessmeyer

We are using the Local system account

Most likely the machine account doesn’t 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.

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

Members of the Domain should be enough.

Jens K. Suessmeyer

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,

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?

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

I’m seeing the same issue within reporting services with schedule reports (which creates jobs within sql 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?

READ  Ulauncher uwow ошибка подключения к серверу

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. Fred Morrison

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.

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?

Источник

The job failed unable to determine if the owner error 15404

I executed the following:

EXECUTE AS LOGIN=’ADS\me’
Go

Msg 15404, Level 16, State 19, Line 1
Could not obtain information about Windows NT group/user ‘ADS\me’, error code 0x5.

I also executed that command with the service account:

EXECUTE AS LOGIN=’ADS\myserviceaccountname’

Command(s) completed successfully.

So, it’s as if the service account can query its own information but not that of other ads user objects. I suspect that SQL is trying to validate my SID with the SID it has for me within a SQL system table to verify that my ADS account really is a SQL login, but I’m just guessing there.

I’m going to send this information to our ADS admins. It really seems to point to a permission problem in ADS.

If it is a SQL issue, could it be that ADS\me doesn’t have permission to execute a system stored procedure in order to perform the ADS query? To answer my own question, it seems like the service account would be doing this and not my ADS\me account.

Thanks very much,

I have to admit I am also a little bit surprised. I have never faced a scenario where an account is getting an explicit access denied when querying information about itself and all its groups, but succeeds while querying information about other principals and objects in the AD. I agree with you, check with your AD administrator, probably they have some security policy we are not aware of that may be causing this problem.

READ  Steam fatal error filesystem stdio dll

I personally don’t think the problem is regarding any permission to execute a system stored proc (EXECUTE AS should call the code directly); but let’s wait until we have more information from the AD admins regarding this issue.

One more thing you can try: Can you install a test-only copy of SQL Server 2005 (i.e. SQL Server Express) using a different account for the service? (it could be a different machine). If you can install it, can you try the same EXECUTE AS LOGIN tests?

SQL Server Engine

Actually, I think it’s the other way around: the service account can query its own information, but cannot query other ADS users.

I’ll see if I can try that test on my local SQL instance.

Got it, I misunderstood that part; I apologize for the confusion. Thanks for the clarification.

It seems like it is a limited account on the AD and doesn’t have permission to query, hopefully the AD admin will be able to verify if this assumption is correct.

SQL server Engine

I am having the same exact problem. I even test on my test SQL server and I get the same message. I am not sure where to start to solve this problem. Any help?

Make sure that the SQL Server service account has permission to query the AD. Typically this error is caused by trying to impersonate or query information regarding a Windows user from a different domain.

Please, if you need further assistance let us know the scenario that were you are hitting this issue.

SQL Server Engine

Can you give me the step by step on how to grant, or make sure, the SQL Server service account has access to query AD? I’m new to SQL and not sure how to do this. I have two domains setup. One is internet facing, and one is our regular domain. Our regular domain doesn’t trust out Interent domain, but our Internet domain trusts our regular domain. The SQL server I am working on is in our Internet domain, and the jobs are falling with the same messages above. We are running a few jobs with different user accounts. Some from our regular domain, and a few with our admin account on the Internet domain. All jobs are falling. I have tried running the jobs with the sa account, but that fails as well.

Can you help me out?

Hello,
I am also getting the same error (15404) as Syndrake. I have tried all of Raul’s suggestions with the same results.

I have confirmed with our AD Admin that there are no restrictions on this domain account. They setup the service account as a standard user. She actually created a new account, just as a test, while I had her on the phone and we had the same results.

One intresting twist with my situation is that this issue cropped up when I migrated this server to an AD domain from a NT4 domain (seperate domains, not a domain upgrade). The Agent service account was able to query user info just fine in NT 4, but this same SQL Agentservice/job owner setup now fails in AD.

For further assistance on AD configuration I would recommend using the directory services forum ( http://forums.microsoft.com/TechNet/ShowForum.aspx?ForumID=571&SiteID=17 ), the audience of this forum will be better qualified to help you on this area than myself.

Please correct me if my assumption is incorrect:

· Domain-A trusts Domain-B, but Domain-B doesn’t trust Domain-A

· SQL Server is installed on a Domain-A machine

In order to work, SQL Server should be running under a Domain-B service account, otherwise it is very likely that Domain-B will not accept the token from the service and fail.

SQL Server Engine

Thanks for replying to my post.

Actually, Domain A trusts Domain B and Domain B trusts Domain A. Full 2-Way trust.

SQL Server machine was a member of Domain A but now has joined Domain B. Domain A will be going away.

Previous Working Scenario

  • Server is a member of Domain A (NT4).
  • SQL Agent service running as Domain A\SQLAgentAcct.
  • Domain A\SQLAgentAcct has sysadmin rights in SQL. Also belongs to Domain Users domain group and the local Administrators group.
  • SQL Agent job owner = Domain B\Developer
READ  Padovan прошивка кто это

Agent job runs successfully. Domain A\SQLAgentAcct while logged into Domain A is able to get information about Domain B\Developer. I assume because of the 2-way trust.

Non-working Scenario. Attempting to take Domain A out of the picture.

  • Server is now a member of Domain B (AD). Also, all accounts involved now belong to Domain B.
  • SQL Agent service running as Domain B\SQLAgentAcct.
  • Domain B\SQLAgentAcct has sysadmin rights in SQL. Also belongs to Domain Users domain group and the local Administrators group.
  • SQL Agent job owner = Domain B\Developer

SQLAgentAcct could not obtain information about Windows NT group/user ‘Domain B\Developer’

Like Syndrake, I was able to log into the server as Domain B\SQLAgentAcct and add Domain B\Developer to local groups. The check names function works great. So, you would think Domain B\SQLAgentAcct would have adequate permissions to query AD.

My AD Admin claims that the Domain B\SQLAgentAcct does not have any restrictions. It is setup like any other user. And, because I am able to query AD outside of SQL, this doesn’t seem to be a AD permissions issue.

What is the service account for SQL Server? The AD query should be running using the AD credentials (if coming from SQL Server Engine).

SQL Server Engine

In my working scenario, the SQL Server service was running as a domain user in Domain A.

In the non-working scenario, the SQL Server service is running as a local account that does not have domain access to Domain B. I set it up this way because I thought it was the SQL Agent account that was actually doing the AD query.

I changed the SQL Server service to run as a domain user account and the agent jobs now appear to be working when a domain account is the owner.

I am going to do some more testing, but I think that the SQL Server service account was my problem.

Thank you very much, Raul.

I have got the same issue after renaming the server. When executing a maintenance plan I get the same error. What I can se is that the user failing is

    \Administrator not \Administrator. The server does not belong to a domain. Also the default \ accounts under Security/Logins are also
      \ .

    How can I fix this ?

    We have this issue also. I’m going to try maybe setting the trust for delegation rights on the sql svc acct? Could this be a double hop kerberos issue?

    Has anyone found any fix for this?

    I have the following scenario and solved it this way:

    • A cross-Forest Trust between «Domain A» and «Domain B» (in this example alpha.corp and beta.corp)
    • The SQL Server is member of domain BETA and tries to obtain information about a user in domain ALPHA but fails with error «SQLServer Error: 15404. «
    • The SQL Server is running under the service account «BETA\sqlservice»

    On The SQL Server, error 28005 was constantly logged in the event log:

    An exception occurred while enqueueing a message in the target queue.
    Error: 15404, State: 19. Could not obtain information about Windows NT group/user ‘ALPHA\myaccount’, error code 0x5.

    On the Domain Controller(s) of domain «ALPHA» I could also find event id 4769 and Failure Code 0xc,
    which translates to KDC policy rejects request Workstation/logon time restriction.

    Log Name: Security
    Source: Microsoft-Windows-Security-Auditing
    Date: 16.11.2010 07:11:46
    Event ID: 4769
    Task Category: Kerberos Service Ticket Operations
    Level: Information
    Keywords: Audit Failure
    User: N/A
    Computer: DC1.alpha.corp
    Description:
    A Kerberos service ticket was requested.

    Account Information:
    Account Name: sqlservice@BETA.CORP
    Account Domain: BETA.CORP
    Logon GUID:

    Service Information:
    Service Name: cifs/DC1.alpha.corp
    Service ID: S-1-0-0

    Additional Information:
    Ticket Options: 0x40810000
    Ticket Encryption Type: 0xffffffff
    Failure Code: 0xc
    Transited Services: —

    Solution:

    Enable ‘Allowed to authenticate‘ security setting for the service account BETA\sqlservice on the domain controllers computer object in domain ALPHA:

    Источник

Smartadm.ru