IBMMQDotnetClient, использующий учетные данные Windows вместо учетных данных, указанных приложением

#c# #ibm-mq

#c# #ibm-mq

Вопрос:

При использовании IBMMQDotnetClient версии 9.2.0.1 в .NET Core я пытаюсь подключиться к клиенту с помощью

 private MQQueueManager Connect()
{
    System.Collection.Hashtable properties = new System.Collections.Hashtable();
    properties.Add(MQC.USER_ID_PROPERTY, "username");
    properties.Add(MQC.PASSWORD_PROPERTY, "password");
    // more settings below
    
    return new MQQueueManager(QueueManagerName, properties);
}
  

Проблема в том, что это все еще пытается передать мои личные учетные данные Windows даже после установки идентификатора пользователя и пароля при настройке свойств диспетчера очередей. Как мне убедиться, что учетные данные, переданные приложением, заменяют мои личные учетные данные Windows при запуске приложения.

Редактировать:

Для большего контекста параметры вывода настраиваются как:

 public static readonly int OUTPUT_OPTIONS = MQC.MQOO_OUTPUT;
  

Я не уверен, могут ли быть другие варианты, которые могут гарантировать, что переданные учетные данные используются в отличие от учетных данных Windows.

Комментарии:

1. Какая версия MQ запущена в диспетчере очередей, к которому вы подключаетесь? IBM добавила CONNAUTH (проверка подлинности соединения) в MQ в версии 8.0, и это необходимо настроить в диспетчере очередей ADOPTCTX(YES) , чтобы использовать отправляемый вами идентификатор / PW. Если он настроен с ADOPTCTS(NO) помощью, то он все равно будет проверять предоставленные вами имя пользователя / пароль, но для целей разрешения он будет использовать пользователя, под которым запущена программа.

2. Вам нужно будет проконсультироваться с администратором MQ, чтобы узнать, какую ошибку они видят, и если / как у них настроен CONNAUTH. Идентификатор, который отправляется в MQ в потоке подключения, всегда является зарегистрированным пользователем, если вы укажете USER_ID и ПАРОЛЬ, он отправляется в дополнение к зарегистрированному пользователю во время последующего потока MQCSP. Если диспетчер очередей настроен для просмотра MQCSP или нет, это то, что вам нужно проверить.

3. Если вы просто хотите, чтобы пользователь был отправлен во время потока подключения (без пароля), тогда вам нужно будет использовать runas или олицетворение. Обратите внимание, что если это работает, то это означает, что диспетчер очередей не защищен, поскольку тривиально заставить поток соединений отправлять любое имя пользователя, которое вы хотите.

4. Да, и это соответствует поведению, о котором я упоминал в своих комментариях выше. Вы не можете заставить диспетчер очередей проверять подлинность и использовать ваш идентификатор и PW, для этого необходимо настроить диспетчер очередей.

5. Нет, это параметр Qmgr для объекта AUTHINFO, на который указывает атрибут CONNAUTH QMGR.

Ответ №1:

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

Комментарии:

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