Страницы: 1 2 След.
RSS
Записи в журнале событий
 
ТИ 3.0.2.916

1. [HTTP proxy] запрос от 192.168.12.91, имя "OMGUPS\ЭиУК-Симак" - Авторизация запрещена.

Авторизация на прокси сервере у меня, действительно, запрещена. Однако этот пользователь авторизован через агента и спокойно работает Интернете. Почему генерируется такая запись?

2. [HTTP proxy] запрос от 192.168.11.10, имя "СПИ-Васильев" - Пользователь СПИ-Васильев не найден

Этот пользователь существует, тоже авторизован через агента и тоже нормально работает в Интернете. Что же означает это предупреждение?


 
Протестировал на 917 версии, всё блокируется и отрабатывает.
Возможен удаленный доступ на сервер и клиента?
Возможно у Вас действуют какие-то разрешающие правила, или ещё что-то.
 
Wacko Интересно, что Вы там такое тестировали, что у Вас всё блокируется и отрабатывает? Вы поняли суть вопросов? На всякий случай повторю еще раз, медленно. 
По записям типа 1. Пользователь авторизован через агента, что отчетливо видно в мониторе работы, активен, кушает интернет-трафик. В этом случае, на мой взгляд, такой записи в журнале событий быть не должно! Она логична и правомочна, если неавторизованный пользователь лезет в Интернет, а авторизация на прокси сервере запрещена.
По записям типа 2. Что значит пользователь не найден, если он есть, авторизован через агента и активен? Сами Вы не ответите на этот вопрос. Задайте его разработчику.
Удаленный доступ на сервер я пару раз давал (по другим вопросам) - результат нулевой. Не думаю, что он станет иным.
У меня есть разрешающие правила по IP для всех. И что с того? У Вас есть какая-то идея, объясняющая связь таких правил с появлением в журнале событий вышеупомянутых записей?
 
Запись первого типа уведомляет вас, что запрос от пользователя на прокси сервер запрещён, именно поэтому она начинается с [HTTP proxy].

Запись второго типа указывает на то, что такой пользователь c IP адресом не был найден в списке пользователей сформированным до первого совпадения с IP адресом запроса.
 
Такое впечатление, что мой последний пост Вы не прочитали.
Запись первого типа русским по белому говорит о том, что авторизация на прокси сервере запрещена. Я это знаю, это так и есть. Но в это время этот пользователь авторизован. Через агента. Запросы в Интернет от него проходят, в том числе и через прокси сервер.
Второй абзац Вашего сообщения перечитал раз 5, смысла так и не понял. Разъясните, пожалуйста.
 
Ну так авторизацию на прокси вы запретили, а агент использует свой протокол. Просто клиент будучи авторизован агентом попытался авторизоваться через прокси, например программой настроенной на прокси

По второму - проще сказать запрос пришел от пользователя, для которого в списке пользователей с авторизацией по IP попадает несколько вариантов, выбирается первый вариант и затем проверяются дополнительные условия, которые не удовлетворяют авторизации.
 
Цитата
Ну так авторизацию на прокси вы запретили, а агент использует свой протокол. Просто клиент будучи авторизован агентом попытался авторизоваться через прокси, например программой настроенной на прокси
Логично.

Цитата
По второму - проще сказать запрос пришел от пользователя, для которого в списке пользователей с авторизацией по IP попадает несколько вариантов, выбирается первый вариант и затем проверяются дополнительные условия, которые не удовлетворяют авторизации.
Все равно я не понял Вашу мысль.
По поводу записи "[HTTP proxy] запрос от 192.168.11.10, имя "СПИ-Васильев" - Пользователь СПИ-Васильев не найден" у меня появилась некоторая мыслишка. Пользователь СПИ-Васильев точно существует. Правда, строго говоря, полный логин его - OMGUPS\СПИ-Васильев. На прокси, видимо, посылается логин без указания домена, поэтому прокси такого пользователя не находит.
Кстати. В файле users.xml LogonName пользователя пишется почему-то без домена. ТИ ведь может работать с пользователями из разных доменов, к примеру домен1\Иванов и домен2\Иванов. Как тогда ТИ их будет различать, если в конфигурационном файле пользователей про домен нет никакой информации? Это недоработка программиста?

Еще несколько разновидностей записей в журнале событий.

[Authorization server]

Запрос от 192.168.33.38. Пользователь "OMGUPS\ПК-Оператор" не найден.

Понимаю ее так. На компе с адресом 192.168.33.38 установлен клиентский агент ТИ. Он передает серверу авторизации указанный логин. Такого пользователя в ТИ нет. Поэтому в журнал заносится запись что такой пользователь не найден. Заметьте, не "Неверное имя или пароль", как, на мой взгляд, некорректно отписывает прокси сервер (см. ниже), а точная фраза.

[Authorization server] Запрос от 192.168.3.6. Пользователь не

найден

В этом случае, по моему, на компе агента нет, польователь пытается выйти в Интернет через NAT (мимо прокси), сервер авторизации о логине ничего не знает, в списке авторизованных IP такого адреса нет, поэтому появляется такая запись. Правильно интерпретирую?

[Authorization

server] Запрос от 192.168.3.34 - SSPI error "SEC_E_LOGON_DENIED"

[8009030C] in AcceptSecurityContext (GenContext point 2)  in UserAuthThread.Execute

Эту запись пока никак не интерпретирую. О чем она? И почему в отличие от других - не по русски?

[HTTP proxy]

запрос от 192.168.12.225, имя "None" - Неверное имя пользователя или пароль

Такого пользователя в базе ТИ нет. Тогда и писать надо точно - "Пользователь не найден", как это делает сервер авторизации (см. выше). И пароль тут совсем ни при чем! (Это камешек в сторону разработчика. Передайте, пожалуйста.)

[HTTP proxy]

запрос от 192.168.32.93, имя "ОТЖТ-Андреева " - Неверное имя

пользователя или пароль

Такой пользователь есть (в users.xml такой буквально, на самом деле OMGUPS\ОТЖТ-Андреева). Запись в журнале считаю некорректной. Если пользователь указал неверный пароль, надо так и написать "Неверный пароль". А если у прокси есть претензия к логину, то запись должна быть "Пользователь не найден". Согласны со мной? Если да, то передайте привет разработчику. Если нет, аргументацию в студию.

Пока все. Возможно, еще появятся записи, смысл которых мне не понятен, тогда задам вопросы дополнительно.




 
А у вас используется исключительно доменная авторизация или также есть BASIC?
 
В правиле сетей (все адреса) разрешены методы аутентификации и BASIC и NTLM.
В свойствах всех групп авторизация через прокси или SOCKS запрещена.
 
А вы простые пароли используете для авторизации?
Страницы: 1 2 След.
Читают тему (гостей: 2)