Проверка подлинности Windows-to-windows в WebSphere MQ с использованием классов Java - PullRequest
1 голос
/ 16 февраля 2011

При подключении с рабочей станции Vista к Windows Server 2003 с помощью WebSphere MQ версии 6.x клиент имеет версию 7.0.1.3. Я могу написать очень простую .Net-программу для подключения с помощью интерфейса AMQMDNET к администратору каналов и очередей, но при этом с использованием Java и классов com.ibm.mq я получаю канал 2537, недоступный. Проводная трассировка показывает, что .Net-код предоставляет SID пользователя вместе с идентификатором пользователя, но вызванный Java-код не заполняет SID. Я подозреваю, что наши администраторы настроили канал со свойством NTSIDsRequired на канале (ожидая ответа от администратора).

Кто-нибудь знает, почему интерфейсы Java не отправляют SID по умолчанию? Я не могу найти параметр, чтобы использовать это поведение.

Эд

1 Ответ

0 голосов
/ 16 февраля 2011

Я подозреваю, что наши администраторы настроили канал со свойством NTSIDsRequired на канале ...

На самом деле, если это причина, скорее всего, все наоборот.При конфигурации по умолчанию администратор очередей будет использовать SID, если он указан, но в противном случае будет использовать строковое представление имени учетной записи.Если бы оно использовало строковое представление, и это не помогло, вы бы вернули ошибку 2035 Not Authorized.С другой стороны, если было установлено NTSIDsRequired и была предпринята попытка подключения без SID, то приведет к отказавшему соединению.Ожидается ошибка 2035, по крайней мере на стороне QMgr, но вполне возможно, что клиент увидит 2537 для этого.

Обратите внимание, что NTSIDsRequired не является настройкой канала.Это действительно, когда запрос на соединение сделан, но поведение функционирует в Object Authority Manager (OAM) и выполняется для каждой проверки OAM, сделанной от имени подключенного клиента, включая OPEN, CLOSEи SUBSCRIBE.Он работает полностью на стороне администратора очередей.

Обычно 2537 виден, если у канала есть выход, который отказывает в соединении.Например, BlockIP2 exit может быть настроен так, чтобы отклонять соединения, если идентификатор пользователя пуст, содержит административную учетную запись или исходит от неавторизованного IP-адреса (отсюда и имя).Кроме того, канал может достигнуть максимальных значений или быть остановлен, но ни один из них не соответствует вашему описанию.Выход из канала является реальной возможностью, однако.

Две возможности: 1) NTSIDsRequired установлен , и QMgr отказывается от соединения, поскольку SID отсутствует;или 2) выход канала отклоняет соединение.Поскольку сообщения об ошибках безопасности намеренно редки на стороне клиента, для их диагностики потребуется просмотреть сообщения в журнале ошибок администратора очередей или в журнале событий Windows на сервере администратора очередей.Если выход установлен, может также потребоваться просмотреть журналы выхода.Если это связано с NTSIDsRequired и события авторизации включены в администраторе очередей, я ожидаю, что будет также сгенерировано событие авторизацииЕсли это из-за выхода или одного из ограничений экземпляра канала, будут записи в журнале.

Редактировать:
Проведя еще немного исследований, я обнаружил страницу Инфоцентра о том, чтоSID всегда передается, и не делается никаких различий в отношении типа клиента Windows.Исходя из этого, поведение, которое вы видите, противоречит документированному поведению, поэтому вы должны иметь возможность открыть PMR для него.Похоже, что эта страница была дословно скопирована с с той же страницы в Инфоцентре v6 , поэтому несоответствие версий не должно вызывать проблем.

...