Проверка доступа к серверу на основе токенов завершилась ошибкой инфраструктуры

Question

Буду признателен за помощь по следующей проблеме:

Я создал локальную группу на нашем сервере SQL 2008 и добавил две учетные записи пользователя Windows «DOMAIN \ UserName». Затем я добавил локальную группу в базу данных и предоставил доступ только для чтения.

Пользователи пытаются связать таблицы, используя MS Access, используя ODBC-соединение, и получают следующую ошибку. Пользователи не являются системными администраторами.

Дата 30.06.2010 13:01:54 Журнал SQL Server (текущий - 30.06.2010 13:10) Исходный вход Сообщение Не удалось войти в систему для пользователя 'DOMAIN \ UserName'. Причина: проверка доступа к серверу на основе токенов завершилась ошибкой инфраструктуры. Проверьте на наличие предыдущих ошибок. [КЛИЕНТ: 999.99.9.99] Дата 30.06.2010 13:01:54 Журнал SQL Server (текущий - 01.07.2010, 8:12:00)

Исходный вход

Сообщение Ошибка: 18456, серьезность: 14, состояние: 11.

Сервер базы данных: Windows Server 2008 R2 Enterprise Тип системы: 64-битная операционная система SQL Server 2008

Answer 1

Спасибо за ваш ответ.

Я нашел причину проблемы. Я просто хотел, чтобы сообщение об ошибке MS в журналах могло быть более ясным. Удаленный пользователь с проблемами доступа к журналу также был частью группы, которой было отказано в доступе к нашей базе данных. Я полностью пропустил эту конфигурацию. Затем я создал другую группу и предоставил доступ пользователю. Я также предоставил доступ явно, и в обоих случаях пользователям было отказано в доступе. Как только я удаляю группу, которой запрещен доступ, все работало нормально.

p.reinoso

Answer 2

Возможно, отсутствует имя участника-службы для учетной записи службы, которую вы используете для подключения к серверу SQL. Например, если вы пытаетесь подключиться к sqlsrv1 из websrv1 с использованием учетной записи svcacct1, вы можете (используя учетную запись администратора домена) добавить имя участника-службы, чтобы гарантировать, что AD разрешит проверку подлинности с этого компьютера с использованием этой учетной записи.

setspn -A MSSQLSvc/websrv1.domain.local:1433 svcacct1

Теперь, когда вы пытаетесь подключиться к sqlsrv1 (для аутентификации с помощью MS SQL), используя svcacct1 от websrv1, учетные данные должны пройти и разрешить аутентификацию на сервере без генерации этой ошибки.

Answer 3

Эта ошибка появляется для учетной записи следующего типа / s YourDomaninName \ ServerName $, когда вы переименовываете НОВЫЙ встроенный сервер со старым именем сервера, то есть обновление сервера.Чтобы решить эту проблему, вам нужно будет по существу удалить пользователя во всех сопоставленных базах данных, удалить логин, создать логин и, наконец, снова предоставить разрешения для баз данных.

Шаг 1. Сценарий Создать логин (вы должны использоватьсценарий, так как пользователи такого типа не доступны для поиска)

CREATE LOGIN [YourDomaninName\ServerName$] FROM WINDOWS WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english];

Шаг 2. Запишите базы данных, к которым у пользователя есть доступ, и предоставленные разрешения, затем удалите пользователя из каждой базы данных.

USE MyDatabase;
IF EXISTS (SELECT * FROM sys.DATABASE_principals WHERE name = N'YourDomaninName\ServerName$')
DROP USER [YourDomaninName\ServerName$];

Шаг 3. Удалите имя входа с сервера

USE [Master];
IF EXISTS (SELECT * FROM sys.server_principals WHERE name = N'YourDomaninName\ServerName$') 
DROP LOGIN [YourDomaninName\ServerName$]

Шаг 4. Создайте имя входа с помощью ранее созданного сценария

CREATE LOGIN [YourDomaninName\ServerName$] FROM WINDOWS WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english];

Шаг 5. Предоставьте разрешениекаждая база данных из заметок, сделанных на шаге 2. Этот шаг может быть выполнен вручную через SSMS.

Answer 4

У меня возникла та же проблема:

Не удалось войти в систему для пользователя. Проверка доступа к серверу на основе токенов завершилась с ошибкой инфраструктуры

Я просто забыл дать Разрешения на чтение / запись базы данных дляэтот пользователь.Мы создаем пользователя для каждого веб-сайта на нашем сервере, и этому пользователю с более низкими разрешениями необходим доступ на чтение к веб-файлам, его собственный пул приложений и доступ для чтения / записи к их конкретной базе данных в Sql Server.Я забыл последний шаг и получил это непонятное сообщение в журналах.Добавление этих разрешений решило это.

Answer 5

У меня была эта проблема, и это было, потому что пользователь был частью родительского домена, и я дал только группу, к которой он был частью доступа (например, PARENT \ someGroup). Таким образом, получается, что группа - это группа «Локальный домен», а не глобальная / универсальная группа. Моя БД в моем дочернем домене не может прочитать токены для локальной группы домена в родительском домене.

Answer 6

Моя проблема немного отличалась от проблемы Педро (p.reinoso).В моем случае была настроена группа доменов Windows для управления доступом администраторов БД к серверам SQL.Человек был членом группы MyDomain \ SQL_Admin, но его личный вход в систему SQL на одном из серверов был отключен.Когда мы удалили учетную запись SQL, индивидуум смог подключиться на основе учетных данных группы.

Answer 7

Это звучит как проблема с аутентификацией Kerberos / windows на ваших серверах AD. Я бы посоветовался с вашим администратором AD, чтобы выяснить, могут ли они помочь вам решить эту проблему.