Веб-клиент, windows авторизация #731684

Всем привет. Есть база клиент-серверная, у пользователей стоит аутентификация ОС (есть сетка, домен, Active Directory). База опубликована на веб-сервере, через браузер, с локальной сети проблем нет, заходит под пользователем. Но вот из внешней сети как можно зайти, используя данные нашей локальной сети (типо ввести доменимя пользователя и пароль)? То есть чтоб не указывать для него аутентификацию 1С с указанием пароля...

Нет такого( А еще хочется, чтобы доменная аутентификация опционально для пользователя была бы "неавтоматической", то есть с вводом логина, пароля и домена. Чтобы получить независимость логина в 1с от логина в ОС.

>из внешней сети как можно зайти, используя данные нашей локальной сети Никак. Протокол win-аутентификации (NTLM) работает только внутри локальной сети. >А еще хочется, чтобы доменная аутентификация опционально для пользователя была бы "неавтоматической", то есть с вводом логина, пароля и домена Это штатная функция. В настройках запуска базы нужно выбрать "Запрашивать имя и пароль".

"Протокол win-аутентификации (NTLM) работает только внутри локальной сети." Что мешало в дополнение к ntlm сделать basic-аутентификацию с передачей логина и пароля средствами приложения? Сквид же умеет так делать. Это не то. 1с умеет запрашивать имя и пароль только при собственной аутентификации. Доменные - не умеет.

>Доменные - не умеет. Имхо, и правильно делает. Для юзеров самое то, чтобы работали в базах под своими учетками. А для админа есть 1с-ные логин/пароль. >Сквид же умеет так делать. Дык, 1с же не только через веб-сервер умеет работать.

"Дык, 1с же не только через веб-сервер умеет работать." Какая разница? Что мешает самой 1с сделать то же, что делает веб-браузер при запросе к прокси-серверу?

"Имхо, и правильно делает. Для юзеров самое то, чтобы работали в базах под своими учетками." Бывает всяко.. скажем, работа с компа общего доступа. Одновременно запущена куча 1с под разными логинами, человек сел, занес данные, залочил 1с и уступил место другому. У нас на складе так - кладовщиков несколько, комп один. Было бы удобно, если бы при этой схеме можно было авторизироваться доменным паролем.

С твоим умом да к Нуралиеву.... Цены бы вашему тандему не было бы....

а чего нет то ? включаешь нтлм на иис, в 1с через домен, в клиенте выбрать веб авторизация через логин пароль ,должно взлететь. Сам не делал ибо лень.

"Запуск от имени другого пользователя" в помощь.

А если компьютер не в домене, а надо авторизироваться доменным пользователем?

Ввести компьютер в домен.

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

тады ой

То есть, 1с значительно сузила область применения доменной авторизации.. вместо того, чтобы просто аутентифицировать пользователя В ДОМЕНЕ, она аутентифицирует пользователя ДОМЕНА - а это не одно и то же..

и проблема то в чем? заходишь на сервак в конторе по RDP/VPN под учеткой домена заходишь с сервера в 1с.

щито?

Мда.... Тут у меня метла свободная образовалась.... Не хочешь поработать?

Это опять требует дополнительных затрат - RDP-сервера, в частности. Ну вот разработчики сквида осилили же гибридную аутентификацию. Когда при неуспешном ntlm есть возможность аутентифицироваться вводом логина-пароля в браузере. И 1с так могли сделать.

см

Разработчики много чего осилили много чего. Что вообще за сквид? Какое отношение он имеет к 1С? Специально же сделано, чтобы абы кто абы откуда не зашел в базу. И не надо всякую ересь придумывать типа гибридной аутентификации.

В общем-то в документации все описано: Пользователь может быть аутентифицирован неявно средствами операционной системы. Для этого пользователю должен быть поставлен в соответствие некоторый пользователь операционной системы. При старте системы, «1С:Предприятие» запрашивает у операционной системы пользователя, который аутентифицирован в системе в данный момент. Для этого в ОС Windows используется интерфейс SSPI, а в ОС Linux – GSS-API. Затем выполняется проверка, что данному пользователю операционной системы сопоставлен пользователь «1С:Предприятия». Если поиск заканчивается успешно – считается, что пользователь системы «1С:Предприятие» аутентифицирован успешно, и диалог аутентификации не отображается.

Сквид - это прокси-сервер. Гибридная аутентификация - не ересь, а стандарт де-факто при организации выхода в интернет из локальной сети.

"Пользователь может быть аутентифицирован неявно средствами операционной системы." Ключевое слово НЕЯВНО.. а хотелось бы в том числе и возможности ЯВНО аутентифицироваться)

> а стандарт де-факто при организации выхода в интернет из локальной сети. лучше бы в 1с аудит сделали... блокировку после N-той попытки зайти

Да, неявно. В этом режиме 1С ничего не знает про логины, пароли, домены и т.д., а пользуется стандартным интерфейсом безопасности ОС. При явной аутентификации необходимо реализовывать защищенный ввод логина/пароля, процедуры аутентификации в домене и на локальном компьютере, обрабатывать ошибки, выполнять дополнительные действия вроде "Менять пароль при входе в систему" и т.п. В общем городить еще одно звено, массовая необходимость которого сомнительна (толпа кладовщиков и авторизация в домене с компьютера вне домена скажем так не самые массовые варианты), а безопасность явно ниже чем основной вариант. А далее - безопасность системы определяется безопасностью самого слабого звена. Вот зачем 1С становиться "слабым звеном"?

>Вот зачем 1С становиться "слабым звеном"? +1 все потуги из нормально решаются другими средствами некуй накручивать на систему еще и "варку кофе с минетом".

Ровно то же можно было сказать и про собственный сервер 1с в версии 8.1... нафига было велосипед строить, если в 8.0 был сервер на основе DCOM? Оказалось, что велосипед весьма неплох получился, и намного удобнее старого решения.

DCOM, увы, под Linux не запускается. Кроме того DCOM тормознут и для нагруженного серверного приложения слишком "текуч" и "дыряв".

сервер на dcom это было крайне м.дацким решением... кто с 8.0 сношался - тот в цирке не смеется

Оказывается все просто. При публикации базы на веб-сервере надо поставить галку Использовать аутентификацию операционной системы на веб-сервере. И тогда, при подключении из вне к базе вначале вылазит виндовское окошко с логинпаролем, указал данные (доменюзер) и все ок.

А вот ответ службы поддержки, мне не пригодился)): "попробуйте выполнить следующие настройки: На клиентской рабочей станции настройте Internet Explorer таким образом, чтобы он использовал аутентификацию Windows, а также добавьте адрес сайта в зону локальной сети, поскольку для зоны Internet браузер не использует аутентификацию Windows. Для этого: - Запустите браузер Internet Explorer. В строке меню выберите пункт "Tools" и выберите команду "Internet Options". Перейдите на вкладку "Advanced" установите флажок напротив пункта "Enable Integrated Windows Authentication". - Перейдите на вкладку "Security" выберите зону для изменения "Local intranet", нажмите кнопку "Sites" укажите имя web-сервера, нажмите "Add". Настройте Web-сервер таким образом, чтобы он использовал аутентификацию Windows и отключите использование анонимного доступа, так как если он включен то web-сервер сначала пытается воспользоваться этим способом аутентификации. Для этого: - Запустите оснастку iis.msc находящуюся в каталоге "%SystemRoot%system32inetsrviis.msc" перейдите в раздел "Web Sites - Default Web Sites - <ИмяОпубликованнойИБ>" из контекстного меню выберите "Properties". Перейдите на вкладку "Directory Security" нажмите кнопку "Edit" в разделе "Authentication and access control". Установите флажок "Integrated Windows authentication". Остальные флажки должны быть обязательно сняты. Настройте Active Directory для делегирования полномочий Kerberos (необходимы права администратора домена). Для этого: - Разрешите делегирование web-серверу. На контроллере домена откройте оснастку "Active directory users and computers", в группе "Computers" выберите компьютер являющийся web-сервером, откройте его свойства. Если функциональный уровень домена "Windows Server 2003", то выберите вкладку "Delegation" и установите флажок "Trust this computer for delegation to any services (Kerberos only)", если функциональный уровень домена "Windows 2000", то на вкладке "General" установите флажок "Trust this computer for delegation". - Разрешите делегирование пользователю. На контроллере домена откройте оснастку "Active directory users and computers", в группе "Users" выберите пользователя, откройте его свойства. На вкладке "Delegation" установите флажок "Trust this user for delegation to any services (Kerberos only)" и убедитесь, что на вкладке "Account" в разделе "Account options" снят флажок для пункта "Account is sensitive and cannot be delegated". "