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

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

(0) >из внешней сети как можно зайти, используя данные нашей локальной сети

Никак. Протокол win-аутентификации (NTLM) работает только внутри локальной сети.

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

Это штатная функция. В настройках запуска базы нужно выбрать "Запрашивать имя и пароль".

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

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

>Сквид же умеет так делать.
Дык, 1с же не только через веб-сервер умеет работать.

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

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

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

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

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

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

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

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

(12) тады ой

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

(12) и проблема то в чем?

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

заходишь с сервера в 1с.

(14) щито?

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

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

(18) см (7)

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

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

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

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

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

лучше бы в 1с аудит сделали... блокировку после N-той попытки зайти

(23) Да, неявно. В этом режиме 1С ничего не знает про логины, пароли, домены и т.д., а пользуется стандартным интерфейсом безопасности ОС.

При явной аутентификации необходимо реализовывать защищенный ввод логина/пароля, процедуры аутентификации в домене и на локальном компьютере, обрабатывать ошибки, выполнять дополнительные действия вроде "Менять пароль при входе в систему" и т.п.

В общем городить еще одно звено, массовая необходимость которого сомнительна (толпа кладовщиков и авторизация в домене с компьютера вне домена скажем так не самые массовые варианты), а безопасность явно ниже чем основной вариант. А далее - безопасность системы определяется безопасностью самого слабого звена.

Вот зачем 1С становиться "слабым звеном"?

>Вот зачем 1С становиться "слабым звеном"?

+1

все потуги из (0) нормально решаются другими средствами

некуй накручивать на систему еще и "варку кофе с минетом".

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

(27) 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%\system32\inetsrv\iis.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".
"