Не удалось получить информацию о пользователе или группе в окнах nt

Обновлено: 21.11.2024

Количество и объем запутанных и рискованных настроек безопасности в Active Directory становятся все более известными с каждой новой кибератакой. Хотя верно то, что многие из этих уязвимостей могут быть связаны с рискованными конфигурациями, которые со временем накапливались в устаревших средах, ИТ-командам по-прежнему необходимо следить за проблемными настройками, которые появляются в Windows Server 2022 по умолчанию.

Одним из параметров, который должна немедленно решить каждая ИТ-команда, является предварительно заполненная «группа доступа, совместимая с версиями до Windows 2000» с субъектом безопасности «Прошедшие проверку». Этот параметр может оставить открытой дверь для злоумышленников, как я покажу.

Чтобы понять, почему этот параметр вызывает такие проблемы, давайте посмотрим на историю делегирования разрешений и назначения политик в AD, чтобы вы могли принять взвешенное решение о том, как обращаться с этим параметром в вашей организации.

Быть или не быть… совместимым с Windows NT?

Никогда не думал, что напишу новую статью, которая рифмуется с NT. Есть веская причина, по которой мы не говорим о Windows NT в наши дни. Это история. Это технологии прошлого века. Хотя это был большой шаг вперед для Microsoft и приравнивался к ее выходу на корпоративный рынок в 1993 году, операционная система Windows NT была заменена более новыми и безопасными версиями с момента выпуска Windows 2000 в самом начале этого века. А на стороне сервера Microsoft даже придерживалась стандартов именования, добавляя год, близкий к дате выпуска, к названию ОС. Итак, всего несколько недель назад была выпущена Windows Server 2022.

Ключевым изменением в Windows 2000 стала замена концепции домена Windows NT, которая представляла собой плоский каталог для аутентификации пользователей и машин в сети компании, на гораздо более масштабируемую и безопасную Active Directory. Наряду с концепцией доменов в AD были введены доменные деревья и леса, а также разрешено создание иерархической структуры организационных единиц для объектов внутри домена, которые были полезны для делегирования разрешений и назначения определенных политик.

Не менее важным было еще одно ключевое отличие от своего предшественника: в AD появилась возможность устанавливать разрешения не только на уровне объектов (например, пользователей, групп, компьютеров и т. д.), но и на уровне атрибутов каждого объекта (например, , отдел, номер телефона, членство в группах и т. д.). Это еще не было возможно в Windows NT, но теперь администраторы могли четко различать возможность «чтения» или «записи» всех атрибутов данного объекта AD или только тех, которые относятся к данной задаче.

Эта возможность была ключевой для компаний, позволивших следовать мантре «наименьших привилегий» любого хорошего плана безопасности: предоставляйте своим пользователям ровно столько разрешений, сколько им необходимо для выполнения их работы. Не предоставляйте им больше разрешений для доступа к данным, которые им не нужны. В противном случае пользователь, особенно скомпрометированный, может злоупотребить этими разрешениями и нанести ущерб компании.

В любом файловом сервере или структуре SharePoint, где документы для пользователей всей компании являются общими, наиболее естественно следовать правилу «наименьших привилегий». Например, пользователи должны быть членами соответствующей группы безопасности, чтобы разрешить просмотр документов, содержащих финансовые или иные конфиденциальные данные компании, или даже перечислить существование файла. Вы по-прежнему можете сделать определенные, неконфиденциальные данные доступными для всех ваших пользователей через общедоступный общий доступ к документам, к которому у всех пользователей есть доступ, без необходимости добавления в специальную группу. Такой доступ обычно предоставляется вашей группе «Пользователи домена» или даже участникам безопасности «Прошедшие проверку» или «Все».

К сожалению, большинство компаний по-разному относятся к своей рекламе. И частично причина в разрешениях по умолчанию, с которыми Microsoft развертывала — и до сих пор — развертывает новые домены AD. Вместо того, чтобы называть ее группой «Менее безопасные разрешения Windows NT», Microsoft решила ввести группу под названием «Доступ, совместимый с пред-Windows 2000», когда выпустила Windows 2000.

Проблема: даже при новых развертываниях совершенно нового леса AD на серверах Windows Server 2022 Microsoft решила предварительно заполнить группу «Доступ, совместимый с версиями до Windows 2000» участником безопасности «Прошедшие проверку».

Членство по умолчанию в Pre-Win2Kgroup во вновь развернутом домене Active Directory на сервере Windows 2022

Итак, почему это важно и почему вас это должно волновать?

Как следует из названия, группа «Доступ, совместимый с версиями до Windows 2000» была создана именно для этого: для совместимости с Windows NT, т.е., чтобы предоставить разрешения на уровне объекта для объектов в Active Directory, совместимых с менее защищенной Windows NT, вместо использования более детализированных разрешений на уровне атрибутов. Чтобы немного сократить эту статью, я буду называть ее просто группой «Pre-Win2K».

Microsoft не скрывает потенциально опасные последствия в описании группы, где говорится: «Группа обратной совместимости, которая разрешает доступ для чтения всем пользователям и группам в домене». р>

Описание группы доступа, совместимой с пред-Windows 2000, не скрывает ее назначение

И поскольку Microsoft хочет «помочь» вам с обратной совместимостью, насколько это возможно, они предоставляют полные разрешения на ЧТЕНИЕ для соответствующих объектов (пользователей и групп) прямо в верхней части каждого домена в вашем лесу, позволяя ему наследовать всю иерархию подразделений.

Разрешения для корня каждого домена

Эти разрешения по умолчанию установлены, хотя Microsoft больше не спрашивает, хотите ли вы развернуть новый лес AD способом, совместимым с версиями Windows до Windows 2000 (Windows NT). Эта опция была показана вам в более ранней ОС при продвижении нового леса AD, и если бы вы действительно выбрали эту опцию несколько лет назад, вы бы даже добавили «Анонимных пользователей» и «Все» в группу Pre-Win2K и, таким образом, предоставил им мощный доступ для чтения к вашему AD, т. е. пользователям даже не нужно было проходить аутентификацию, чтобы прочитать ваш AD. Я очень надеюсь, что вы уже избавились от этих устаревших разрешений, о которых вас уже предупреждала бы каждая проверка безопасности.

Можно ли оставить «Прошедших проверку» в группе Pre-Win2K в Windows Server 2022?

В этой конфигурации вы предоставляете пользователям и группам разрешения «полное ЧТЕНИЕ», что означает, что любой пользователь и компьютер, присоединенный к домену, может читать соответствующие данные любого такого объекта. Обратите внимание, что каждый присоединенный к домену компьютер также является аутентифицированным пользователем в вашем лесу AD. Это означает, что даже если ни один пользователь не вошел в систему на этих компьютерах, процесс (возможно, троян), работающий в системном контексте компьютера, присоединенного к домену, имеет такой же доступ к вашей AD, как и ваши пользователи.

Чтобы лучше понять влияние, мы должны копнуть немного глубже и проверить, какие разрешения «Прошедшие проверку» предоставляются по умолчанию для всех ваших объектов пользователей и групп в вашем домене. В конце концов, всякий раз, когда вы создаете новый объект, AD добавит дескриптор безопасности по умолчанию для данного объекта к новому объекту — эти разрешения «явно» предоставляются объекту, т. е. не наследуются, и поэтому они имеют наивысший приоритет. при определении общих прав доступа к объекту. Обратите внимание, что эта конфигурация также означает, что эти разрешения по умолчанию имеют более высокий приоритет, чем унаследованное запрещенное разрешение, что часто сбивает с толку администраторов.

Для групповых объектов разрешения Pre-Win2K не имеют значения, поскольку аутентифицированным пользователям в любом случае предоставляется полный доступ для чтения к каждому групповому объекту.

Разрешения по умолчанию для объектов GROUP

Это означает, что даже если вы удалите аутентифицированных пользователей из группы Pre-Win2K, все ваши пользователи по-прежнему смогут читать информацию о членстве во ВСЕХ группах в вашем лесу AD. Если вы не удалили это разрешение для выбранных групп, любой пользователь в вашем лесу, включая потенциального злоумышленника, может легко определить, кто является членом любой группы в вашем домене. Для самых важных групп AD, таких как администраторы домена или администраторы предприятия, вам потребуется выполнить несколько дополнительных действий, чтобы удалить это разрешение на чтение, о чем я расскажу в другом блоге.

Однако для пользовательских объектов ситуация совершенно иная. Хотя разрешения по умолчанию, предоставляемые прошедшим проверку пользователям в отношении пользовательских объектов, также довольно обширны, например, чтение всех атрибутов общей и личной информации, они менее распространены, чем разрешение на чтение ВСЕХ атрибутов пользователей.

Разрешения по умолчанию для объектов USER

Это означает, что прошедшие проверку пользователи НЕ могут получить доступ к различным конфиденциальным атрибутам пользователя с помощью этих разрешений объекта по умолчанию.К ним относятся userAccountControl, memberOf и все атрибуты, связанные с входом в систему, такие как последний вход в систему или время последнего изменения пароля. Имейте в виду, что когда вам предоставляется доступ на чтение к атрибуту userAccountControl, это также позволяет вам выяснить, у каких пользователей установлен флаг «PasswordNotRequired», и другую информацию, которая может позволить обнаружение незащищенных объектов в вашем лесу AD. Пользователи, настроенные с помощью флага PasswordNotRequired, могли быть созданы давным-давно для какого-то приложения и действительно не имели пароля, если администратор AD решил установить его таким образом. Таким образом, они являются легкой приманкой для злоумышленника.

Таким образом, если вы решите оставить прошедших проверку пользователей в группе «Доступ, совместимый с версиями до Windows 2000», каждому пользователю и компьютеру в домене автоматически назначаются разрешения этой группы при входе в систему. И с этим назначением любой процесс, включая вредоносный код, который злоумышленник может выполнить на клиенте, присоединенном к домену, без вошедшего в систему пользователя, может перечислять любые атрибуты пользователя в вашем домене.

Вход в Sysinternals AD Explorer с простой учетной записью домена

Просмотр объектов и атрибутов Sysinternals AD Explorer с Auth Users все еще в Pre-Win2Kgroup

Просмотр объектов и атрибутов Sysinternals AD Explorer с пользователями аутентификации, удаленными из pre-Win2Kgroup

Должен ли я удалить аутентифицированных пользователей из группы pre-Win2K в Windows Server 2022?

Да, вы должны удалить пользователей, прошедших проверку подлинности, из групп доступа, совместимых до Windows 2000, в каждом домене вашего леса AD, даже несмотря на то, что Microsoft по-прежнему добавляет их по умолчанию для новых развертываний AD. Это лишь один из многих важных шагов в повышении уровня безопасности вашей Active Directory. В наши дни нет необходимости поддерживать совместимость с моделью безопасности Windows NT.

Вашим пользователям не нужны разрешения, предоставленные группой до Win2K. Они все еще могут войти в систему. Компьютеры и серверы, присоединенные к домену, также не нуждаются в разрешениях; они будут нормально работать в вашем домене. Это изменение также не затрагивает обработку групповой политики. Администраторам AD также не нужны эти разрешения, так как в противном случае им предоставляется такое же и большее количество разрешений.

Тем не менее, удаление аутентифицированных пользователей из группы Pre-Win2K не является изменением, которое вы просто быстро вносите в свою рекламу в понедельник утром. Во-первых, проверьте потенциальное влияние изменения в вашей собственной среде, поскольку вы можете использовать инструменты или решения, которые ожидают, что эти разрешения до Win2K будут настроены в вашей AD, и используете их по законным причинам.

Примеры решений или задач, которые по умолчанию используют разрешения, предоставленные авторизованным пользователям в группе до Win2K:

Некоторым инструментам сканирования безопасности, которые не выполняются с привилегированной учетной записью или работают в контексте безопасности компьютера, также может быть предложено прочитать эти важные для безопасности пользовательские атрибуты, обсуждаемые в этой статье. В результате эти инструменты могут не предупредить вас, если для пользователя настроен флаг «PasswordNotRequired». Вы можете добавить соответствующую учетную запись пользователя или компьютера в группу pre-Win2K или предоставить необходимые разрешения отдельно.
Остерегайтесь приложений, которые связываются с AD через LDAP для перечисления членства в группах в целях безопасности в приложении.
Если вы используете службы федерации AD (ADFS), в зависимости от вашей настройки вы можете повлиять на проверку подлинности WebForms, что, возможно, потребуется решить с помощью выделенных разрешений на чтение для ваших серверов ADFS или с помощью группы доступа авторизации Windows (WAAG).
При использовании вкладки «Эффективный доступ» в расширенных настройках безопасности на ваших файловых серверах для проверки разрешений, которые данный пользователь может иметь для папки, сервер использует свою учетную запись компьютера для чтения сведений о членстве пользователя в группах. Этот процесс завершится сбоем, как только авторизованные пользователи будут удалены из группы, предшествующей Win2K. Хотя истинное значение вкладки «Эффективный доступ», как правило, сомнительно, поскольку она не учитывает должным образом вложенные группы, если вы все еще хотите ее использовать, вы можете снова добавить свои учетные записи компьютеров файлового сервера в группу до Win2K или иным образом предоставить соответствующие разрешения на чтение пользовательских объектов.
Клиент Ivanti File Director имеет проблемы со чтением homeDirectory и атрибута userAccountAttribute, поэтому пользователи не смогут войти в это программное обеспечение, если вы либо не добавите учетную запись, которую он использует, в Pre-Win2Kgroup, либо не предоставите надлежащие разрешения непосредственно вашим пользовательским объектам.< /li>

В любом случае, для нормальной и более безопасной работы вашей Active Directory авторизованные пользователи не обязаны быть членами группы доступа, совместимой с пред-Windows 2000. И, конечно же, ни «Все», ни «Анонимные пользователи». Сохранение группы пустой или, по крайней мере, заполненной только несколькими выделенными пользователями и компьютерами, которым это может потребоваться, безусловно, поможет уменьшить поверхность атаки вашей AD. Эта конфигурация значительно усложняет злоумышленникам перечисление слабых учетных записей и извлечение других конфиденциальных данных из вашего AD.

Ключевые выводы по настройкам совместимости до Win2K в Windows Server 2022 и более ранних ОС

В Active Directory полно минных полей безопасности, которыми могут воспользоваться злоумышленники. (Чтобы определить потенциальные бреши в безопасности в вашей среде, загрузите Purple Knight, бесплатный инструмент для оценки безопасности AD, который определяет более 80 индикаторов незащищенности или компрометации и дает рекомендации по их устранению.) Но переход на Windows Server 2022 не обязательно означает, что вы оставьте все эти устаревшие настройки позади.

По крайней мере, рассмотрите возможность внесения этих изменений в параметры конфигурации, связанные с совместимостью до Win2K:

Не думайте дважды, чтобы удалить Anonymous и Everyone из группы доступа, совместимой с пред-Windows 2000, в каждом домене вашего леса AD.
Проделайте то же самое для пользователей, прошедших проверку подлинности, но помните о возможных последствиях и будьте готовы повторно заполнить группу системами или пользователями, которые могут полагаться на предоставленные им разрешения.
Удалите разрешения на чтение по умолчанию для пользователей, прошедших проверку подлинности, из конфиденциальных групп, чтобы ограничить круг лиц, которые могут перечислять их членство. Прочтите мой предстоящий блог о том, как это сделать для встроенных групп администраторов AD.

Вы должны самостоятельно решить, следует ли удалить группу «Прошедшие проверку», чтобы повысить уровень безопасности AD. Вы можете пойти на риск и продолжать жить со старыми разрешениями, подобными Windows NT, в Active Directory. Но следуйте по этому пути только после тщательного понимания потенциальной опасности.

Гвидо Грилленмайер — главный технолог компании Semperis. Находясь в Германии, Гвидо был Microsoft MVP для служб каталогов в течение 12 лет. Он проработал более 20 лет в HP/HPE в качестве главного инженера. Гвидо, часто выступающий на технологических конференциях и публикующийся в технических журналах, является соавтором книги «Основы безопасности Microsoft Windows». Он помог различным клиентам защитить свои среды Active Directory и поддержал их переход на Windows 10/m365 и облачные службы Azure. Ссылка

Зарегистрироваться

Получите последние новости и контент от Semperis.

Нажимая «Подписаться», я соглашаюсь на использование моих личных данных в соответствии с Политикой конфиденциальности Semperis. Semperis не будет продавать, обменивать или сдавать в аренду ваши личные данные третьим лицам.

Избранное

Защита Active Directory — первый шаг к приведению в соответствие с новыми рекомендациями Управления финансового надзора Великобритании

Защита Active Directory — первый шаг к приведению в соответствие с новыми рекомендациями Управления финансового надзора Великобритании

В 2019 году Управление финансового надзора (FCA) предложило внести изменения в порядок обеспечения операционной устойчивости учреждениями финансового сектора Великобритании, особенно в отношении угрозы кибератак. FCA вступит в силу с 31 марта 2022 года. Все организации, деятельность которых регулируется FCA, должны будут пройти аудиторские проверки.

Представляем атаку Golden GMSA

В этой статье представлена новая атака, нацеленная на групповые управляемые сервисные аккаунты (gMSA), получившая название «Золотая».

Защита среды гибридной идентификации от кибератак

Поскольку мир продолжает осваивать цифровую трансформацию и распределенную работу, компании будут продолжать развертывать SaaS.

<р>1. Войдите в SSMS локально на сервере как sa
2.Попытка выдать себя за существующую учетную запись "Проверка подлинности Windows" (домен).
3. Получение ошибки "Не удалось получить информацию о группе/пользователе Windows NT "[домен\пользователь]", код ошибки 0x5."

Я видел довольно много сообщений об этой проблеме. Некоторые из них связаны с запуском хранимой процедуры, некоторые — именно мой случай. Однако не все из них имеют фактическое решение вопроса. Похоже, что большинство довольствуется «просто создать и использовать логин для аутентификации SQL Server» или изменить владельца объекта на логин SQL.

Я почти уверен, что проблема в том, что доменная учетная запись, на которой запущена служба SQL Server, не имеет необходимого разрешения в Active Directory (0x5 означает отказ в доступе).
Если кто-нибудь знает отсутствующее разрешение Active Directory, буду признателен.

P.S. сервер правильно автоматически регистрирует имя участника-службы, поэтому учетная запись службы имеет такой большой доступ. (требуются разрешения Active Directory «Запись в общедоступную информацию»).

Вот SQL для проверки олицетворения:

SELECT SUSER_NAME(), USER_NAME();

ВЫПОЛНИТЬ КАК ВХОД='[домен]\';
ПЕРЕХОД

-- Сообщение 15404, уровень 16, состояние 19, строка 4
-- Не удалось получить информацию о группе/пользователе Windows NT "[домен]\", код ошибки 0x5.

15 ноября 2018 г., 15:06

Вот моя проблема:

1. Войдите в SSMS локально на сервере как sa
2. Попытка выдать себя за существующую учетную запись "Проверка подлинности Windows" (домен).
3. Получение сообщения об ошибке «Не удалось получить информацию о группе/пользователе Windows NT «[домен\пользователь]», код ошибки 0x5».

Я почти уверен, что проблема в том, что учетная запись домена при запуске службы SQL Server отсутствует необходимое разрешение в Active Directory (0x5 — доступ запрещен).
Если кто знает отсутствующее разрешение Active Directory, буду признателен.

P.S. сервер правильно автоматически регистрирует имя участника-службы, поэтому учетная запись службы имеет такой большой доступ. (требуются разрешения Active Directory на запись в общедоступную информацию).

Вот SQL для теста на олицетворение:

SELECT SUSER_NAME(), USER_NAME();

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

-- Сообщение 15404, уровень 16, состояние 19, строка 4
-- Не удалось получить информацию о Группа/пользователь Windows NT '[домен]\', код ошибки 0x5.

Есть также довольно много сообщений, которые указывают на то, что проблема была связана с служебной учетной записью, а срок действия неустановленного пароля не истекает.
Есть также некоторые сообщения, в которых возникает какая-то странная проблема с определенной учетной записью, поэтому попробуйте выполнить xp_logininfo с несколькими разными учетными записями.
И это также может произойти, если есть проблемы со связью между SQL Server и активным каталогом.
В противном случае учетная запись службы должна иметь возможность читать контейнер с учетными записями пользователей.

Внезапно и без видимой причины наши SQL-серверы 2005 не будут выполнять автоматические задания. Похоже, что у нас проблема с контроллером домена, но все могут войти в систему, и права работают корректно. Каждое автоматизированное задание SQL, независимо от машины, получает следующее:

Идентификатор сообщения Sql: 0

Не удалось выполнить задание. Не удалось определить, имеет ли владелец (MYDOMAIN\administrator) задания SQL1\dnc-DNCSnapshot-2 доступ к серверу (причина: не удалось получить информацию о группе/пользователе Windows NT «MYDOMAIN\administrator», код ошибки 0x5. [SQLSTATE 42000] (Ошибка 15404)).

Это происходит независимо от того, какой логин мы используем (в примере мы пытались использовать логин администратора, но раньше этого не было). Я прошерстил Интернет и сайты Microsoft в поисках любой информации, и хотя я нашел много других людей, у которых были похожие проблемы, я не смог найти однозначного ответа на вопрос, что может быть не так.

Это началось около 3 недель назад, но было спорадическим. Последние 3 дня постоянно. Даже наши веб-серверы 2005 года имеют проблемы с аутентификацией!

Я прочесал журналы обоих контроллеров домена, но безрезультатно. Я попытался перезапустить оба контроллера домена. Ничто из того, что мы делаем, не решит эту проблему. Буду очень признателен, если у кого-нибудь есть какие-то предложения, особенно если вы сами столкнулись с этой проблемой. Заранее спасибо!

Я не видел эту конкретную проблему, но некоторые мысли по этому поводу.

отказаться (остановить и перезапустить) службы SQL
Проверьте используемый сервисный аккаунт.
создайте низкоуровневую учетную запись AD, возможно, с именем SQLService . просто член домена, и попробуйте использовать его в качестве логина. Установите пароль на неограниченный срок действия, чтобы пользователь не мог его изменить. Если это не сработает, не забудьте удалить низкоуровневую (SQLService) учетную запись.
От экспертной биржи:

– Кто является владельцем задания?
- Под какой учетной записью входит агент SQL Server?
– Какие права есть у этой учетной записи?

Вопрос 1: Я владелец cm/jseiwert, который в активном каталоге является администратором
Вопрос 2: Cm/administrator
Вопрос 3: права администратора

Измените владельца задания на CM/Administrator.

хорошо, cm\administrator не был ответом, но sql admin был. Спасибо

Акк, я это и имел в виду. Извините, мне явно нужно больше кофе.

2 ответа

Я не видел эту конкретную проблему, но некоторые мысли по этому поводу.

отказаться (остановить и перезапустить) службы SQL
Проверьте используемый сервисный аккаунт.
создайте низкоуровневую учетную запись AD, возможно, с именем SQLService . просто член домена, и попробуйте использовать его в качестве логина. Установите пароль на неограниченный срок действия, чтобы пользователь не мог его изменить. Если это не сработает, не забудьте удалить низкоуровневую (SQLService) учетную запись.
От экспертной биржи:

Измените владельца задания на CM/Administrator.

хорошо, cm\administrator не был ответом, но sql admin был. Спасибо

Акк, я это и имел в виду. Извините, мне явно нужно больше кофе.

Вот что сделал наш администратор базы данных, чтобы решить эту проблему:

"Я сбросил SQLDEV\DEVDATA для запуска всех служб SQL Server с использованием пользователя домена «sqlserver2» и перезапустил службы. Запрос не возвращался правильно, когда сервер запускал все службы в качестве локального пользователя SQLServer. После перезапуска службы, использующие пользователя «mydomain\sqlserver2», запрос возвращается правильно.

Затем я использовал Sqldev в качестве тестового примера живого сервера. Все службы были запущены с использованием пользователя Sqldev\SQLServer (локальная учетная запись). Не удалось выполнить запрос аутентификации. Затем я сбросил способ запуска служб с использованием пользователя домена mydomain\sqlserver2 (за исключением служб отчетов SQL Server (которые, я не уверен, мы используем) и перезапустил все службы SQLServer (т. е. базу данных, агент, браузер и т. д.). Запрос проверки подлинности теперь возвращается правильно.

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

Я не пробовал выполнять описанные выше шаги ни на одном из других активных серверов, однако я считаю, что если я изменю их, чтобы использовать логин «LocalSystem» или «mydomain\sqlserver2», проблема будет решена. Какой пользователь мы используем для запуска служб SQLServer, зависит от приведенной ниже проблемы.

Эта тема заблокирована администратором и больше не открыта для комментариев.

Чтобы продолжить это обсуждение, задайте новый вопрос.

Искра! Серия Pro – 22 марта 2022 г.

День в истории: 22 марта 1765 г. — принят Закон о гербовом сборе; Первый прямой британский налог на американских колонистов, организованный премьер-министром Джорджем Гренвиллем 1782 г. — Папа Пий VI прибывает в Вену для встречи с императором Священной Римской империи.

Щелкни! Взлом Okta, взлом Microsoft, дефекты принтеров HP, экзопланеты, изобретательность

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

Как вы измеряете успех?

Если в вашей команде появился новый инженер, и вы его обучили. Как вы измеряете успех инженера с точки зрения обучения, которое вы предоставили? Как вы оцениваете, что они должны уметь делать, или как узнать, было ли ваше обучение успешным.

Настойчивая тактика MSP

За последние несколько месяцев моя компания связалась с некоторыми ИТ-поставщиками в этом районе, чтобы узнать, подходят ли они нам для какой-либо консультационной работы и разовых проектов. долгосрочное обязательство или "услуга pl.

Стремление к карьерному росту

Здравствуйте! Кажется, это правильное место, чтобы задать мой вопрос. Я ищу эффективный способ получить должность, связанную с сетями (администрирование, проектирование, проектирование и т. д.). Я работаю в сфере ИТ около пяти лет. Я иду изначально фр.

Недавно я получил запрос о помощи от клиента по поводу проблемы, которая начала возникать с заданиями SQL Server в BizTalk Server. Все работало нормально в течение последних нескольких месяцев, пока они не начали получать следующие ошибки при попытке выполнить задание SQL:

Задание не выполнено. Не удалось определить, имеет ли владелец (домен\имя пользователя) задания MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb доступ к серверу (причина: не удалось получить информацию о группе/пользователе Windows NT «домен\имя пользователя», код ошибки 0x534. [SQLSTATE 42000] (ошибка 15404)).

Причина

На самом деле причина этой ошибки была довольно проста, и это ошибка, которая может возникать относительно часто, если мы не предпримем необходимые шаги.

В этом случае пользователь, выполнявший установку и настройку BizTalk Server, имел личную учетную запись, которая была членом группы администрирования BizTalk Server, и по умолчанию он настроен как владелец этих заданий. Однако в какой-то момент сотрудник вышел или расторг контракт, а его учетная запись была закрыта или отключена, и это стало причиной того, что эта ошибка начала происходить.

Решение

Решение простое: нужно сменить владельца. А для этого нам нужно:

Откройте SQL Server Management Studio.
Разверните Агент SQL Server, а затем Задания.

Щелкните правой кнопкой мыши имя задания, в данном случае MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb, и выберите "Свойства".
В поле «Владелец» выберите учетную запись sa или любую другую учетную запись в качестве владельца задания с помощью кнопки с многоточием.

Выполните эти действия для всех заданий SQL BizTalk Server.

После этого проблема должна быть решена.

Автор: Сандро Перейра

Сандро Перейра живет в Португалии и работает консультантом в DevScope. В последние годы он работал над реализацией сценариев интеграции как локально, так и в облаке для различных клиентов, каждый из которых имеет разные сценарии с технической точки зрения, размера и критичности, с использованием Microsoft Azure, Microsoft BizTalk Server и различных технологий, таких как AS2, EDI, RosettaNet, SAP, TIBCO и т. д. Он постоянный блоггер, международный спикер и технический рецензент нескольких книг BizTalk, посвященных интеграции. Он также является автором книги «BizTalk Mapping Patterns & Best Practices». Он был награжден MVP с 2011 года за его вклад в интеграционное сообщество. Просмотреть все сообщения Сандро Перейры

Читайте также: