Лоцман и Linux

[oracle]

У нас контроллер домена под линухом, клиенты под виндой ХР. Как мне сказали, если домен под линухом, то можно использовать только сокет соединение. Но при сокет соединении много чего не работает у Лоцмана и библиотека интеграции Лоцман и 1С. Чтобы установить дком соединение при котором все это будет работать необходимо произвести настройки в АД учетных записей и дать права представителя машине с сервером приложений.
Как известно под линухом поддержки АД нет. И как сделать аналогичные настройки под линухом мы не знаем. Админы наотрез отказываются перейти на виндовый контроллер домена.
Может у кого есть такие же проблемы? Или кто-то их уже решил? Давайте тогда дружить

[YorikER]

Обалденная тема! Я уже несколько раз напрягал АСКОН по поводу Линуха (как для Компаса так и для ЛОЦМАНА). Компас вяло обещают, а вот с ЛОЦМАНОМ перспективы весьма туманны... Давайте уточним (если еще кто-то читает эту тему): права представителя надо дать не машине, а пользователю, от имени которого запускается сервер приложений... Настройки пользователей под Линухом плохо знаю, но недавно вышла новая версия OpenSYSE (кажется 10.3), в ней уже многое есть для сетевых настроек домена... Теперь, что конкретно на работает при сокете? Я пробовал сокет, ситуация несколько странная, но вполне сносная: подсоединился к базе данных только через SQL идентификацию, причем имя пользователя SQL - имя компьютера (на котором стоит сервер приложений) в сети с префиксом "$"! И все пользователи подключенные к серверу приложений работают с базой данных от этого имени. Получается так - одна группа (в конфигураторе ЛОЦМАН) - один сервер приложений (т.к.надо настроить права к данным на группу). В конце концов можно поднять вторичный сервер домена и устроить репликацию... Чем у Вас все закончилось? Пожалуйста сообщите. Очень интересно.

[Maxxx]

Конкретно при сокете не работает функция "Создать на основе прототипа"(версию и копию). А также не подключается модуль WORKFLOW(((

[oracle]

Да нет, именно нужно давать "права представителя" машине с сервером приложений, а учетную запись от имени которой будет выполняться сервер приложений доверить для делегирования, причем эта учетная запись еще должна иметь полномочия администратора домена, чтобы достучаться до AD. А пользователям необходимо убирать галочку "Важна и не может быть делегирована". Все настройки делаются в AD.
И вся фишка как раз в делегировании полномочий. Т.е. пользователь обращается к серверу приложений, сервер приложений берет данные о пользователе (т.е. учетная запись пользователя должна делегироваться), а учетная запись сервера приложений должна уметь делегировать, т.е. брать эти данные о пользователе. Дальше сервер приложений обращается к AD и поэтому должна иметь полномочия администратора домена и спрашивает у AD есть ли такой пользователь. Вот так и проходить Windows - аутентификация.
При сокет-соединении возможна только SQL-аутентификация т.к. сервер приложений обращается напрямую к СУБД.
Вообщем в программном коде библиотеки интеграции Лоцман и 1С строго прописано dcom-соединение и при сокет не работает. Но это можно обойти. На компьютере где выполняется сервер приложений (и только на нем) можно установить dcom-соединение, если контроллер домена на Линухе, т.к. сервер приложений может обращаться к локальному каталогу пользователей. И на этом же компьютере можно запустить эту библиотеку интеграции. Что касается "создать на основе прототипа" она и при dcom-соединении не работает. Также не работает модуль "Извещения" при сокет-соединении. Справочник "Материалы и Сортаменты" также не работает при сокет-соединении, но можно это обойти(со справочником), если кому интересно спрашивайте как))
Вообщем, в конечном итоге загвоздка осталась только по модулю "Извещения". В техподдержке мне сказали, что будет исправлено в следующих версиях. Вот только неизвестно в какой именно)) В конечном итоге я убедил всех, и наших админов и руководство, что нужно ставить контроллер домен под виндой)) Так и сделали. Вроде все работает.
И что не понял из Вашего описания, зачем префикс "$" у компа с сервером приложений, и зачем все пользователи работают от одного имени? А если пользователей много и им нужен совсем разный доступ к обектам?

[oracle]

Вот и в Линухе как раз делегирование не поддерживается, насколько я знаю. Вообще AD это LDAP скрещенный с Kerberos (хотя люди из Microsoft говорят, что там есть еще что-то неизвестное простому человеку). И делегирование это как раз из мира Kerberos. Вообще Линух поддерживает этот протокол, но как настроить при этом делегирование я незнаю. Спрашивал у людей, никто мне ничего внятного не сказал, хотя может я просто не внял)) Так что эта тема для меня осталась открыта, установить dcom-соединение мне не удалось (удалось только на машине с сервером приложений).

[YorikER]

Первый вопрос: dcom соединение удалось установить на сервере приложений - сервер приложений запущен под Windows? И запущен от имени клиента домена с правами делегирования? В принципе мы так и собирались: есть домен под виндами, есть сервер приложений под ними же проклятыми, а вот клиентское приложение, собственное написанное под наши задачи (www.infnt.ru) установить по Линухом, и была простейшая попытка написать его в Lazarus, пакет под Линух, слегка напоминающий Delphi7. Он свободно распространяется и внем есть библиотеки под Socket соединение. Простейшая попытка достучаться через сокет получилась, но дальше мы не пошли, т.к. нет КОмпаса под Линух. Мы не используем вообще стандартный ЛОЦМАН-клиент и все его библиотеки. Легче взять все управление на ЛОЦМАНом как базой данных на себя, чем разбираться в базовых приложениях...

[oracle]

У нас только контроллер домена под Линух, а все остальное под виндой. Сервер приложений выполняется на машине с Win Server 2003 R2. На этой же машине поставил клиента. В этом случае учетная запись, от имени которой запущен сервер приложений, должна иметь права администратора на этом компьютере. И любая учентная запись, в таком случае, может проходит windows-аутентификацию, на этом компьютере, если она заведена на нем и каждая запись соответственно из своей области.
Т.е. сервер приложений будет обращаться к локальному каталогу компьютера и брать оттуда информацию о пользователе. Видимо в Линухе учетные записи позволяют себя делегировать. А доверять учетную запись сервера приложений для делегирования нужно, если нужна инфа за пределами компьютера.