Could not obtain information about windows nt group user error code 0x5

I have a Windows 2012 Server running SharePoint 2010 using an SQL Server Express locally installed. Unfortunately my logs are currently flooding with message «An exception occurred while enqueueing a message in the target queue. Error: 15404, State: 19. Could not obtain information about Windows NT group/user ‘DOMAIN\user’, error code 0x5.» It can be 20 such messages every second!

(…and the ‘DOMAIN\user’ happens to be my personal account.)

Are there a job running that has missing rights? «Qoute from https://serverfault.com/questions/277551/mssqlserver-exception-occurred-while-enqueueing-a-message-in-the-target-queue-e «Try to changing the owner of the jobs to the sa account, on the properties of the job.» If I’m correct the express version of SQL server cannot run jobs? Or is there someone/something that wants access to our AD? Why do that account wants to obtain information about my account 20 times every second?

I do find lot’s of blogs and hints about this task, but I just dont understand the solutions. One says «To repair this, login as one of the SA accounts and grant SA access for the account that needs it.» But what account needs sa access?

asked Sep 15, 2014 at 10:22

Change the owner to sa. Here are the steps I took to solve this issue:

Right-Click on the database and select properties
Click on Files under the Select a page
Under the Owner, but just below the Database Name on the right-hand pane, select sa as the owner.

ΩmegaMan

29.6k12 gold badges100 silver badges123 bronze badges

answered Aug 21, 2017 at 10:09

olasammyolasammy

6,7364 gold badges26 silver badges32 bronze badges

In my case, sa was not the owner of the DB, I was. When I tried to execute CLR configuration that required sa privileges, I got the error too.

The solution:

USE MyDB 
GO 
ALTER DATABASE MyDB set TRUSTWORTHY ON; 
GO 
EXEC dbo.sp_changedbowner @loginame = N'sa', @map = false 
GO 
sp_configure 'show advanced options', 1; 
GO 
RECONFIGURE; 
GO 
sp_configure 'clr enabled', 1; 
GO 
RECONFIGURE; 
GO

I used help from the db team at work and this post to find the answer.

starball

22.1k8 gold badges47 silver badges285 bronze badges

answered Nov 17, 2014 at 21:46

Chaim EliyahChaim Eliyah

2,7734 gold badges24 silver badges37 bronze badges

In my case the owner of the database was a domain account Domain\Me.

The error message was

Error: 15404, State: 19. Could not obtain information about Windows NT
group/user ‘Domain\MyAccount’

The problem was that the database didn’t know what to do with the domain account — so the logical thing to do was to use a local account instead.

I tried changing the owner of the database, but things still wouldn’t work correctly.

In the end I dropped and recreated the entire database MAKING SURE THAT THE OWNER WAS SA

I also set the Broker to Enabled in the settings

Thing started magically working after this

answered May 6, 2015 at 11:38

No Domain Authentication

Failure was ultimately due to the fact that it was not able to authenticate when I was not vpn-ed into the corporate network.

For I was connecting to a local db on my work laptop, however the User ‘DOMAIN\user’ needed to be authenticated by AD on the corporate network.

Error was resolved as soon as I reconnected and refreshed; the error disappeared.

ΩmegaMan

29.6k12 gold badges100 silver badges123 bronze badges

answered Jun 26, 2020 at 7:59

Ameet BhatAmeet Bhat

911 silver badge1 bronze badge

to do a bulk update for all databases, run this script and then execute its output:

 SELECT 'ALTER AUTHORIZATION ON DATABASE::' + QUOTENAME(name) + ' TO [sa];' 
 from sys.databases
     where name not in ('master', 'model', 'tempdb')

answered Mar 26, 2018 at 17:05

avs099avs099

11k6 gold badges60 silver badges110 bronze badges

I had this error from a scheduled job in sql Server Agent, in my case, just after I changed the hostname of the Windows Server. I had also ran sp_dropserver and sp_addserver. My database was owned by «sa», not a Windows user.

I could login into SQL as the Windows user NEWHOSTNAME\username (I guess after a hostname change, the SID doesn’t change, that’s why it worked automatically?).

However, in SQL, in Security/Logins node, I had SQL logins defined as OLDHOSTNAME\username. I connected to SQL using «sa» instead of Windows Integrated, dropped the old logins, and create new ones with NEWHOSTNAME\username.

The error disappeared.

answered Jan 11, 2016 at 14:26

Thierry_SThierry_S

1,5361 gold badge16 silver badges25 bronze badges

I was having the same problem. In my case it was due to the fact that my machine was part of a domain, but I was not connected to the company VPN. The problem was solved after connecting to the VPN (so the domain user could be resolved by the SQLAgent).

answered Mar 1, 2021 at 13:41

erionpcerionpc

3783 silver badges16 bronze badges

I had the same issue where my domain login was not being recognized. All I did was go into the SQL Server configuration manager and start the services as Network Services instead of a local service. The sql server / agent was then able to recognize the AD logins for the jobs.

answered Jun 14, 2019 at 12:42

HaliHali

413 bronze badges

In my case, it was VPN issue. When I turned on the VPN to connect with my office network & then tried to start the snapshot agent again, it started successfully.

answered Oct 29, 2019 at 18:37

Ankush JainAnkush Jain

5,6944 gold badges32 silver badges57 bronze badges

I was facing the same issue.
Fix for me was changing the log-on from NT User to global user in Sql Server Configuration Manager => Sql Server Service => Sql Server Agent => Properties => Account name.

answered Apr 4, 2020 at 9:10

Jitan GuptaJitan Gupta

4646 silver badges18 bronze badges

You should be connected with your domain. (VPN)

answered Feb 8, 2022 at 8:53

WouterWouter

2,56019 silver badges31 bronze badges

Источник

(…and the ‘DOMAIN\user’ happens to be my personal account.)

asked Sep 15, 2014 at 10:22

Change the owner to sa. Here are the steps I took to solve this issue:

Right-Click on the database and select properties
Click on Files under the Select a page
Under the Owner, but just below the Database Name on the right-hand pane, select sa as the owner.

ΩmegaMan

29.6k12 gold badges100 silver badges123 bronze badges

answered Aug 21, 2017 at 10:09

olasammyolasammy

6,7364 gold badges26 silver badges32 bronze badges

In my case, sa was not the owner of the DB, I was. When I tried to execute CLR configuration that required sa privileges, I got the error too.

The solution:

USE MyDB 
GO 
ALTER DATABASE MyDB set TRUSTWORTHY ON; 
GO 
EXEC dbo.sp_changedbowner @loginame = N'sa', @map = false 
GO 
sp_configure 'show advanced options', 1; 
GO 
RECONFIGURE; 
GO 
sp_configure 'clr enabled', 1; 
GO 
RECONFIGURE; 
GO

I used help from the db team at work and this post to find the answer.

starball

22.1k8 gold badges47 silver badges285 bronze badges

answered Nov 17, 2014 at 21:46

Chaim EliyahChaim Eliyah

2,7734 gold badges24 silver badges37 bronze badges

In my case the owner of the database was a domain account Domain\Me.

The error message was

Error: 15404, State: 19. Could not obtain information about Windows NT
group/user ‘Domain\MyAccount’

The problem was that the database didn’t know what to do with the domain account — so the logical thing to do was to use a local account instead.

I tried changing the owner of the database, but things still wouldn’t work correctly.

In the end I dropped and recreated the entire database MAKING SURE THAT THE OWNER WAS SA

I also set the Broker to Enabled in the settings

Thing started magically working after this

answered May 6, 2015 at 11:38

No Domain Authentication

Failure was ultimately due to the fact that it was not able to authenticate when I was not vpn-ed into the corporate network.

For I was connecting to a local db on my work laptop, however the User ‘DOMAIN\user’ needed to be authenticated by AD on the corporate network.

Error was resolved as soon as I reconnected and refreshed; the error disappeared.

ΩmegaMan

29.6k12 gold badges100 silver badges123 bronze badges

answered Jun 26, 2020 at 7:59

Ameet BhatAmeet Bhat

911 silver badge1 bronze badge

to do a bulk update for all databases, run this script and then execute its output:

 SELECT 'ALTER AUTHORIZATION ON DATABASE::' + QUOTENAME(name) + ' TO [sa];' 
 from sys.databases
     where name not in ('master', 'model', 'tempdb')

answered Mar 26, 2018 at 17:05

avs099avs099

11k6 gold badges60 silver badges110 bronze badges

I could login into SQL as the Windows user NEWHOSTNAME\username (I guess after a hostname change, the SID doesn’t change, that’s why it worked automatically?).

The error disappeared.

answered Jan 11, 2016 at 14:26

Thierry_SThierry_S

1,5361 gold badge16 silver badges25 bronze badges

answered Mar 1, 2021 at 13:41

erionpcerionpc

3783 silver badges16 bronze badges

answered Jun 14, 2019 at 12:42

HaliHali

413 bronze badges

In my case, it was VPN issue. When I turned on the VPN to connect with my office network & then tried to start the snapshot agent again, it started successfully.

answered Oct 29, 2019 at 18:37

Ankush JainAnkush Jain

5,6944 gold badges32 silver badges57 bronze badges

answered Apr 4, 2020 at 9:10

Jitan GuptaJitan Gupta

4646 silver badges18 bronze badges

You should be connected with your domain. (VPN)

answered Feb 8, 2022 at 8:53

WouterWouter

2,56019 silver badges31 bronze badges

Источник

Remove From My Forums

Question
I have created an ASSEMBLY by using following SQL
successfully ,
```
CREATE ASSEMBLY name-assembly
FROM "C:path"
WITH PERMISSION_SET = SAFE;
```
later when I run the code below,
```
-- Alter assembly with PERMISSION_SET = EXTERNAL_ACCESS
ALTER ASSEMBLY name-assembly
WITH PERMISSION_SET = EXTERNAL_ACCESS;
GO
```
I got,

Please help! Thanks,

«Msg 15404, …, Could not obtain information about Windows NT group/user,..,, error code 0x5″

Answers

Are you running SQL Server under LocalSystem? Best practice is to use a domain account. You could also try logging on to SQL Server with an SQL login rather than integrated security.

Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
- Marked as answer by
  
  Sunday, September 30, 2012 11:02 AM

Источник

November 13, 2018 at 10:18 am

#416488

Here’s my issue:

1. Log into SSMS locally on the server as sa
2. Attempt to impersonate an existing «Windows authentication» (domain) account.
3. Receive error «Could not obtain information about Windows NT group/user ‘[domain\user]’, error code 0x5.»

I’ve seen quite a few posts about this issue. Some are related to running a stored procedure, some are my case exactly. However all of them don’t have the actual resolution to the issue. It seems most are content to «just create and use a SQL Server authentication login», or change the owner of the object to a SQL login.

I’m pretty sure that the issue is that the domain account running the SQL Server Service is missing a required permission in Active Directory (0x5 is access denied).
If anyone knows the missing Active Directory permission, I would be grateful.

P.S. the server is correctly auto-registering the SPN, so the service account has that much access. (required Active Directory “Write to Public Information” permissions).

Here’s the SQL for the impersonation test:
SELECT SUSER_NAME(), USER_NAME();

EXECUTE AS LOGIN='[domain]\'; GO

--Msg 15404, Level 16, State 19, Line 4 --Could not obtain information about Windows NT group/user '[domain]\', error code 0x5.

Sue_H

SSC Guru

Points: 90860

Jon.Morisi — Tuesday, November 13, 2018 10:18 AM

Here’s my issue:

1. Log into SSMS locally on the server as sa
2. Attempt to impersonate an existing «Windows authentication» (domain) account.
3. Receive error «Could not obtain information about Windows NT group/user ‘[domain\user]’, error code 0x5.»

I’ve seen quite a few posts about this issue. Some are related to running a stored procedure, some are my case exactly. However all of them don’t have the actual resolution to the issue. It seems most are content to «just create and use a SQL Server authentication login», or change the owner of the object to a SQL login.

I’m pretty sure that the issue is that the domain account running the SQL Server Service is missing a required permission in Active Directory (0x5 is access denied).
If anyone knows the missing Active Directory permission, I would be grateful.

P.S. the server is correctly auto-registering the SPN, so the service account has that much access. (required Active Directory â€œWrite to Public Informationâ€ permissions).

Here’s the SQL for the impersonation test:
SELECT SUSER_NAME(), USER_NAME();

EXECUTE AS LOGIN='[domain]\'; GO

--Msg 15404, Level 16, State 19, Line 4 --Could not obtain information about Windows NT group/user '[domain]\', error code 0x5.

There are also quite a few posts that indicate the issue was with the service account and not having set password never expires.
There are also some posts where it’s some odd issue with a particular account so trying to execute xp_logininfo with a few different accounts.
And it can also happen if there are issues with communication between SQL Server and active directory.
Otherwise, the service account needs to be able to read the container with the user accounts.

Sue

frederico_fonseca

SSCoach

Points: 15804

first I wonder if the syntax is correct
EXECUTE AS LOGIN='[domain]\’;
possibly should be
EXECUTE AS LOGIN='[domain\user]’; — brackets around all of the domain\user, not around both domain and user

Second it may be that the SQL Server domain account does not have «impersonation» privileges and is therefore failing.

Jon.Morisi

SSChampion

Points: 12846

EXECUTE AS LOGIN='[domain]\';

Above is just pseudo code. I did test

frederico_fonseca — Thursday, November 15, 2018 5:51 PM

first I wonder if the syntax is correct
EXECUTE AS LOGIN='[domain]\’;
possibly should be
EXECUTE AS LOGIN='[domain\user]’; — brackets around all of the domain\user, not around both domain and user

Second it may be that the SQL Server domain account does not have «impersonation» privileges and is therefore failing.

Thanks, this lead me down the right track. It was not an AD permission it was the local impersonation configuration under, «Configure/verify local impersonation user rights» here:
https://blogs.msdn.microsoft.com/sqlupdates/2014/12/05/sql-server-kerberos-and-spn-quick-reference/

Источник

This is one of those typical blog posts that I write for my future self, the guy who keeps fixing the same stuff over and over and forgets what he did the next minute.

If you want to query information about a Windows user or group and its access path in SQLServer, you can use the extended stored procedure “xp_logininfo”. Here’s an example:

EXEC xp_logininfo 'MyDomain\SomeUser','all';

If everything is configured correctly, you will see a list of Windows accounts and the login(s) they are mapped to in SQLServer.

However, in some cases, the command fails with the infamous error message:

Could not obtain information about Windows NT group/user 'MyDomain\SomeUser', error code 0x5

This happens every time SQLServer tries to query information about the Windows user from Active Directory and receives an error.

Understanding where the error comes from can be tricky, but it can become easier to troubleshoot when you understand what happens behind the scenes and what are the most likely causes.

The user does not exist

This is very easy to check: does the user exist in Windows? Did you misspell the name?

You can check this from a cmd window, issuing this command:

net user SomeUser /domain

If you spelled the user correctly, the command will return information about it, like description, password settings, group membership and so on.

If the user name is incorrect and cannot be found in AD, you will get an error message

The user name cannot be found.

Easy peasy: check your spelling and check your AD.

The service account does not have enough privileges to query AD

As I said, SQL Server needs to query AD to retrieve information about the user: if its service account doesn’t have enough privileges, the query will fail.

The most likely cause for this is a misconfiguration of the service account settings in SQL Server. To be more specific, it is very likely that SQL Server is configured to run as a local user who has no access to Active Directory at all. This happens when SQL Server runs as a per-service SID or one of the built-in local accounts (local service or localsystem).

It is very easy to check what account is being used to run SQL Server: all you need to do is query sys.dm_server_services.

SELECT servicename, service_account 
FROM sys.dm_server_services;

If you see a local account being returned, go ahead and change your service account to a domain account, using the Configuration Manager.

If you still can’t query AD, maybe there is something wrong with the permissions on your AD objects. Try impersonating the SQL Server service account, open a cmd windows and issue the net user command.

> net user SomeUser /domain
The request will be processed at a domain controller for domain MyDomain

System error 5 has occurred.
Access is denied

If you get the “Access is denied” error message, you need to go to your AD and grant read permissions on that user/OU to the service account.

The service account does not have enough privileges to impersonate the windows user

This was a bit of a surprise for me. In order to retrieve information about the Windows user, SQL Server needs to impersonate it first and then will contact AD impersonating that user.

In order to impersonate a user, SQL Server needs to run under a service account user that has enough privileges to impersonate another user. This privilege is granted through a local policy.

Open the local security policy MMC (secpol.msc) and expand “Local Policies”, “User Rights Assignment”. Find the policy named “Impersonate a client after authentication” and double click it. You can verify whether the service account for SQL Server is granted this privilege, directly or through one of its groups.

Generally speaking, you don’t have to change this, because by default Windows grants this privilege to the “SERVICE” special identity. Any process running as a service is acting as the SERVICE special identity, including SQL Server. If you don’t find it listed here, add it back.

Windows permissions can get tricky at times. I hope that this post helps you (and me!) taming the beast.

Источник

No Domain Authentication

No Domain Authentication

Question

Answers

The user does not exist

The service account does not have enough privileges to query AD

The service account does not have enough privileges to impersonate the windows user