Я выдернул свои волосы из-за этой проблемы, переполнение стека, но все еще не смог это исправить.
Цель
Я пытаюсь создать учетные записи по требованию на Windows Сервер 2019 Azure ВМ. Виртуальная машина не присоединена к домену, а является отдельным сервером в этой одинокой рабочей группе. Приложение представляет собой приложение веб-API ASP. NET Framework v4.6.1, работающее в качестве службы приложений в Azure.
using (var context = new PrincipalContext(ContextType.Machine, vmData["ip"].ToString(), null, ContextOptions.Negotiate, $@"{vmData["name"]}\{vmData["username"]}", vmData["password"].ToString()))
{
using (var user = new UserPrincipal(context))
{
user.DisplayName = username;
user.SamAccountName = username;
user.SetPassword(password);
user.PasswordNeverExpires = true;
user.Save();
using (var group = GroupPrincipal.FindByIdentity(context, "Administrators"))
{
group.Members.Add(user);
group.Save();
}
}
}
Проблема
При локальном запуске этого кода все работает нормально, подключение к виртуальной машине Azure прошло успешно, пользователь создается и добавляется в локальную группу администраторов на сервере.
Когда этот код публикуется в Служба приложений в Azure всегда будет выдавать System.Runtime.InteropServices.COMException: Access is denied. в строке user.DisplayName = username;. Я предполагаю, что при попытке установить user.Displayname сервер запрашивается таким образом, но это свойство пользователя не обязательно должно быть уникальным, и я знаю из предыдущих проектов, что реальная проверка уникальных свойств происходит, когда вы сохраняете () user.
Исправления исследований и попыток
- Я отключил правила брандмауэра, которые разрешали входящий трафик c с IP-адресов служб приложений на виртуальную машину Azure просто чтобы увидеть, получу ли я другое исключение => Тайм-аут / Сервер не может быть достигнут. Правила брандмауэра кажутся правильными
- Я полностью отключил все брандмауэры, чтобы убедиться, что в правилах брандмауэра не пропущены какие-либо порты или требуемые протоколы => Доступ запрещен!
- Я подключил Visual Studio удаленно отладка службы приложений в надежде получить более подробную информацию из исключения => Доступ запрещен, ничего более.
- Пробные исправления из PSEXE C, ошибки доступа запрещены
- Обнаружены ошибки при использовании. NET 4.5 . NET 4.5 Ошибка в UserPrincipal.FindByIdentity (System.DirectoryServices.AccountManagement) => при использовании 4.6.1
- Проверен удаленный сервер на проверить, что создаваемая учетная запись еще не существует
- Проверены журналы событий удаленного сервера на наличие журналов, которые могут быть связаны с этой проблемой, сбой входа в систему, аудит, что угодно. Ничего не найдено.
Последнее средство
На данный момент я собираюсь включить OpenS SH на этих виртуальных машинах и начать пытаться создавать локальные учетные записи таким образом.
У кого-нибудь есть идеи, где искать, другие вещи попробовать?
Заранее спасибо!
ОБНОВЛЕНИЕ 1:
Я изменил проект с. NET Framework v4.6.1 на v4.7.2, поскольку Azure Служба приложений запускается либо. NET v3.5 или. NET v4.7.
Снимок экрана Azure Отображение конфигурации службы приложений. NET Настройка v4.7
В надежде, что на моем локальном компьютере возникнет то же исключение, которое я дал тесту, еще один go и он действительно создает исключение COMEx в той же строке. Однако это не то же самое COMException.
System.Runtime.InteropServices.COMException: Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.
Поскольку я только что внес изменение в v4.7.2, я все еще исследую это новое исключение, просто подумал, что эта дополнительная информация может быть важна для добавить в исходный номер.