Windows nt user or group not found check the name again

MS SQL Server. При создании логина генерируется
ошибка

При создании пользователя сервере (что из Enterprise Manager,
что из Query Analizer) командой

exec sp_grantlogin 'OurDomainMalinkin'

вылезает ошибка:

Server: Msg 15401, Level 11, State 1, Procedure sp_grantlogin, Line 41
Windows NT user or group 'OurDomainMalinkin' not found. Check the name again.

Ошибка, прямо скажем, непонятная. В списке логинов
сервера пользователя OurDomainMalinkin нет, пользователь
такой в Active Directory есть, а сервер возвращает ошибку, что
такой пользователь имеется. В чем причина? Оказалось,
что пользователь OurDomainMalinkin в домене раньше именовался
по-другому и был уже зарегистрирован на сервере. Стало
немного яснее, но как же генерировать пользователя так,
чтобы не появлялась ошибка?

Для этого перед генерацией пользователя следует
проверить, не зарегистрирован ли он уже на сервере:

if not exists(
  select
    1
  from
    master.dbo.syslogins
  where
    sid = suser_sid('OurDomainMalinkin'))
exec sp_grantlogin 'OurDomainMalinkin'

Теперь дам пояснения. Пользователь Windows имеет
уникальный идентификатор, которым является вовсе не
имя, а SID. Именно по SID происходит различение
пользователей при Windows-аутентификации. Потому и
проверять существование пользователя на сервере
нужно не по имени, а по его SID. Еще один интересный
момент: при выдаче прав пользователю на базу
использовать нужно уже его действительное имя, а не то,
которое прописано на сервере. То есть, если вы даете
права на базу пользователю OurDomainMalinkin, которого раньше
звали OurDomainMalina, то в процедуру sp_grantdbaccess передавать
нужно OurDomainMalinkin, несмотря на то, что прописано в
таблице syslogins:

exec sp_grantdbaccess 'OurDomainMalinkin', 'Malinkin'

Хотя запрос

select
  *
from
  master.dbo.syslogins
where
  name = 'OurDomainMalinkin'

возвращает пустую выборку. Так происходит на MS SQL Server
2000. В версии 2005 запрос на выдачу прав срабатывает в
обоих случаях.

Сказать честно, мне все равно непонятно, почему в
такой ситуации генерируется такое ни о чем не
говорящее исключение, разработчики из Microsoft просто
поленились, в системной процедуре sp_MSaddlogin_implicit_ntlogin для
любой ситуации, когда генерация невозможна,
исключение одинаковое.

Having an issue creating accounts in SQL.

There are KB articles for the issue: http://support.microsoft.com/kb/324321/en-us http://support.microsoft.com/kb/2770837

Except these don’t exactly apply. This issue typically arises when you have a CS instance. I have confirmed the collation as CI:

select serverproperty('collation')  
SQL_Latin1_General_CP1_CI_AS  

SQL Ver is 10.50.400 (2008 R2 SP2)

So when I try to create a login from windows it just tells me :

Msg 15401, Level 16, State 1, Line 1 Windows NT user or group ‘domainaccount’ not found. Check the name again.

So here is the kicker. The SQL Server is hanging off a RODC. It has no direct communication with a RWDC. That may be important, not sure. The real kicker is that if I authenticate to the server with an account, that account is then good.

So if I try to add login for domainuserA, I get 15401. Then, I log into the SQL Server as domainuserA. I run the T-SQL again, and it works.

If I run:

select SUSER_SID ('domainuserb')

I get a NULL return. Until I log into the server as domainuserb. Then I get the SID back.

Wondering if anyone else has experienced this strange issue, or has any suggestions as to how I might solve it.

When you add new Domain Login to SQL Server, you may see error  Windows NT user or group ‘DomainUser’ not found. Check the name again. (Microsoft SQL Server, Error: 15401).

This error message is very general and it does not explain any specific problem or reason itself. Microsoft has a very good article to fix this issue at http://support.microsoft.com/kb/324321/en-us.

However, there is another scenario which is not covered in above article (at the time when writing this article) or may be I am the first person who faced this issue.

This scenario can be reproduced on Windows 2008 Server with SQL 2008 Server where the Domain Controller is Windows 2000 server. On Windows 2008 server, 2 new policies have been enabled by default that encrypts the secure channel data when new LOGIN request is sent to Domain Controller by Domain member(Also SQL Server). In this scenario, Domain Controller is Windows 2000, thus it does not understand the encrypted request thus refuses the LOGINrequest. All you need to do is to fix this behavior in Windows 2008 (SQL Server) to not to send encrypted secure channel data to Domain Controller. To do this follow the steps below and it should fix the issue.

1. From the SQL Server running Windows 2008 R2, Click Start-> Run and type the command GPEDIT.MSC. This will open the Policy Editor.
2. From Policy Editor Expand “Computer configuration” — > Windows Settings -> Security Setttings -> Local Policies -> Security Options.
3. You will see all security policies on right hand side window. Make changes into the following two policies.

• Domain member: Digitally encrypt secure channel data (when possible) – Disable this policy
• Domain member: Digitally sign secure channel data (when possible) – Disable this policy

After making these changes, close the policy editor and reboot the box. (Not SQL Server, but restart entire system).

In case your local policy does not allow you to make changes, you may have to make changes using Group Policy Management Console. Instructions to install GPMC are located at http://blogs.technet.com/askds/archive/2008/07/07/installing-gpmc-on-windows-server-2008-and-windows-vista-service-pack-1.aspx.

• Run gpmc.msc (Group Policy Management)

• Expand your Domain

• Go to and select and then follow steps 2 and 3 from above.

Posted by Sudarshan Narasimhan on October 17, 2012

This entry was posted on October 17, 2012 at 1:55 AM and is filed under Security, Windows.
Tagged: create login, DNS, error creating login, lookupaccountname, Msg 15401, SID, SQL Server, trust relationship. You can follow any responses to this entry through the RSS 2.0 feed.

You can leave a response, or trackback from your own site.