Готовые продукты пока не интересуют. Тем более, что мне нужно для hp-ux.

не готовый, а ГОСТовый

для сведения - мы завязали с индейскими плясками под тамтамы... Удалось убедить клиента в том, что раз интегратор сумел впарить им тиволи идентити манагер - пусть и настраивает:)

Но если кто-то добился приемлемого результата - интересно было бы узнать.

Обслуживать САП и не плясать с бубном?? Разве это возможно:-)?Я вот уперся в настройку кербероса под hp-ux. Кстати тоже самое попробовал под линуксом - работает. То ли какой косяк/несовместимость с AD в клиенте кербероса у hp-ux, то ли я свою ошибку в настройке не могу найти. В логах ничего нет, поэтому кроме как плясать с бубном ничего не остаётся...

"Astrosoft" представляет...

http://www.matchlogon.ru/index.php?page=sap

Расширенная версия MatchLogon - MatchLogon для доступа в SAP® R/3® - позволяет организациям использовать уже развернутую на этапе внедрения MatchLogon для Active Directory инфраструктуру аппаратной аутентификации для обеспечения комфортного и безопасного доступа в системы SAP® R/3® и SAP® Enterprise Portal.

Предлагаемый механизм доступа не противоречит стандартной (встроенной в системы SAP®) парольной схеме аутентификации. Несмотря на то, что на рынке существуют реализации доступа в SAP® R/3® по цифровому сертификату, стоимость подобных решений, а также совокупных затрат на их внедрение и сопровождение, несравненно выше стоимости внедрения MatchLogon. При этом MatchLogon позволяет осуществлять доступ в SAP® с использованием любой технологии аутентификации, включая смарт-карты, биометрическую (отпечаток пальца, роспись, радужка глаза и др.), proximity-карты и другие.

MatchLogon полностью избавляет пользователей от неудобств и уязвимостей, связанных с вводом пользователем пароля учетной записи SAP® R/3®. Автоматическая генерация и смена паролей, реализованная в MatchLogon специально для систем SAP®, удовлетворяет всем требованиям безопасности, предъявляемым со стороны R/3® к сложности пароля, длине пароля и периоду устаревания пароля.

MatchLogon не требует вмешательства в существующие механизмы работы серверной части SAP® R/3®. Это положительно отражается как на гарантийных отношениях с сервисной компанией, осуществляющей поддержку SAP® R/3®, так и на совместимости с любыми серверными платформами (Solaris, HP-UX, Windows и др.).
MatchLogon для доступа в SAP® R/3® - это:

ИЗБАВЛЕНИЕ ПОЛЬЗОВАТЕЛЕЙ SAP® R/3® ОТ ПАРОЛЕЙ
MatchLogon позволяет задействовать ту же технологию аутентификации в SAP® R/3®, которая была выбрана в организации для доступа в домен Active Directory.

ЦЕНТРАЛИЗОВАННОЕ УПРАВЛЕНИЕ СОЕДИНЕНИЯМИ ПОЛЬЗОВАТЕЛЕЙ СИСТЕМ SAP® R/3®
MatchLogon позволяет выполнять настройку соединений SAP® R/3® централизованно, с использованием MMC консоли Active Directory Users and Computers, а также удобных шаблонов соединений. Таким образом, системный администратор может за один шаг создать учетную запись сотрудника для доступа в сеть и настроить профили соединений с системами SAP R/3. Изменения, вносимые впоследствие в шаблоны (смена адреса сервера, идентификатора системы и т.п.) автоматически применяются на все соединения, созданные по данному шаблону.

СНИЖЕНИЕ РИСКА ПРЕВЫШЕНИЯ АДМИНИСТРАТОРАМИ SAP® R/3® СВОИХ ПОЛНОМОЧИЙ
У администраторов SAP® R/3® отсутствует возможность узнать или использовать чужой пароль, после того как пользователь осуществил вход в SAP® R/3® с использованием устройства аутентификации (сканер отпечатка пальца, смарт-карта, proximity карта и т.п.). Любые попытки сбросить чужой пароль мгновенно отражаются в Журнале событий, что может служить поводом для проведения служебного расследования.

ЦЕНТРАЛИЗОВАННЫЙ АУДИТ ДЕЙСТВИЙ ПОЛЬЗОВАТЕЛЕЙ
MatchLogon записывает в журнал событий все попытки пользователей получить доступ в системы SAP® R/3®. В случае использования биометрических устройств аутентификации факт наличия подобного сообщения означает физическое присутствие пользователя в момент получения доступа.

Спасибо за информацию, но меня пока интересуют штатные средства. Кстати ту ошибку я поборол. Как всегда, самая тупая ошибка наиболее трудно диагностируется. Дело было в том, что неправильно был прописан 88 порт в /etc/services. А kinit нет чтоб написать что-нибудь типа "неизвестный порт kerberos", вместо этого пишет, что не может соединиться с KDC.

Новая проблема - криво собирается SAP_SNC_Adapter. Для hp-ux makefile заточен под C/ANSI компилятор, который HP продаёт только за деньги. Соответственно у меня есть 2 варианта: для gcc, но под линукс, или под hp-ux, но для C/ANSI. Нужно из них получить для gcc под hp-ux.

P.S. То же самое пытались сделать в http://forums.sdn.sap.com/message.jspa? ... ID=7194538.

Эту задачу решить удалось. Использовал бинарный gcc 3.0.1, который скачал с ftp://sunsite.informatik.rwth-aachen.de ... /gcc_hpux/ (ссылка туда шла с http://gcc.gnu.org/install/binaries.html). Вот подправленый build.HP-UX:Может какие ключики и лишние, но по крайней мере так работает.

Наконец-то нам IT сгенерил рабочий ключик и мы опробовали это решение на реальном домене. При этом возникла следующая проблема: в AD у нас несколько доменов. Ключик сгенерирован только для одного. IT утверждает, что техническому пользователю, для которого сгенерирован этот ключик были даны полномочия на авторизацию пользователей из других доменов. Но не совсем ясно что нужно задавать на вкладке SNC в SU01 для этих пользователей.

Согласно http://help.sap.com/saphelp_nw70ehp1/helpdata/en/44/0ebf6c9b2b0d1ae10000000a114a6b/frameset.htm


KERBEROS_REALM_NAME у нас совпадает с именем домена, в котором зарегистрирован технический пользователь, поэтому для пользователей этого домена всё хорошо.

Для остальных если использовать вместо KERBEROS_REALM_NAME имя того домена большими буквами, то пользователь при логоне получает следующую ошибку: GSS-API(min): SSPI: No authority could be contacted for authentication target="p:<наш Principal Name>"

Если же мы задаём на вкладке SNC пользователя из тестового домена, не принадлежащего нашей AD, то сообщение выглядит так:
GSS-API(min): SSPI: Specified target is unknown or unreachable target="p:<наш Principal Name>"

То есть есть подозрение, что всё-таки IT не все права дал техническому пользователю.

У кого такое же работает - что задаёте для пользователей других доменов?

Я делал такую связку c HP-UX, правда достаточно давно. Уже не помню всех подробностей.
Помню, что есть приколы в стыковке HP-UX 11.23 и 11.31 с доменами 2003 и 2008 - все четыре варианта нужно настраивать по разному, везде свои особенности

А что касается нескольких доменов, то у меня было мнение что это просто невозможно, поэтому не пробовали. Да и задача так не ставилась.
Но может и прокатит. Ругань-то идет на полномочия, что обычно решить можно. Другое дело, что не в этом на самом деле может быть причина.
Навскидку, как минимум нужно убедиться что все hp-ux хосты резолвят DNS всех нужных AD доменов.

С 2008 я не пробовал. А долгий затык был у нас с неработающим ключиком потому что я пробовал тестовый домен на оригинальной 2003 без всяких сервис-паков, а домен из настоящей АД был конечно пропатчен и там стоял sp2. Как выяснилось, утилита ktpass, которая выгружает ключики, была там старая (её нужно отдельно обновлять), поэтому она генерила некорректные ключики. Но в итоге сейчас у меня сгенерированный ключик работает даже с kinit от мит-керберос клиента для WIN32. Так что сама аутентификация думаю должна работать на любых версиях HP с мит-керберос клиентом.

adem, не можете вспомнить какие именно приколы были с 11.31 и 2003 ? 11.23 у нас тоже есть, приколы для неё тоже интересны, но менее актуальны.

Насчёт видимости контроллеров чужих доменов действительно у нас могут быть проблемы. Пропишу их сейчас и проверю ещё раз.

Порылся в записях. Вроде получается что с 2003 доменом, все более-менее сработало по тому мануалу, что здесь упоминался (плюс еще поиск в инете).
Может разницы между 11.23 и 11.31 с 2003 и <я не знать русский языка> и я запомнил неправильно. Единственно, может что-то с версиями кербероса и его наличием в системе.
Сейчас 11.31 под рукой нет, а на всех 11.23 уже все настроено, так что концов не найдешь

А вот с 2008 точно приколов было достаточно. Помню, что ktpass на 64 битах запускать было нельзя, не вязалось.
Приколы, связанные с шифрованием: SAP хочет использовать только DES, тогда как винда 2008 желает работать с AES. Там уже пошли отступления от мануала. Если я правильно помню, то керберос 11.23 удалось совместить с виндой только по связке DES+AES, а 11.31 связался более гладко, кажется на DES only его уговорили.

Спасибо за информацию. Мне всё ещё пока не сделали доступ в виндовс с аккаунтом из другого домена. А с родным доменом никаких особых отличий. Везде кушает DES only (у меня контроллеры домена 2003 или 2000, а 2008 говорят нет). Пробовал и на системах на IA64 и на PA-RISC, и версии были 11.23 и 11.31 - всё одинаково. Только конечно sap snc adapter собирался для каждой архитектуры свой. Причём под IA64 gcc3 поставился только на hp-ux 11.23. Но полученый файл работает и на 11.31.

Получилось зайти пользователем с подчинённого домена. Как оказалось, у нас сложная система в AD. Не уверен как это точно называется, наверно лес. То есть несколько независимых доменов, у каждого из них есть свои поддомены, а общего корня нет. Есть только доверительные отношения между командирами этих независимых доменов.

Вопрос к тем, кто использует коммерческие системы (тут по ходу дела две всплывали): ваши решения годятся для случая нескольких независимых доменов?

В общем можно сказать, что получилось всё. В том числе настроить аутентификацию по 128-битному ключу, использующему алгоритм RC4-HMAC-NT, который штатно поддерживается в W2k8R2. AES я не пробовал, потому что у нас ещё много доменов, которыми рулят w2k3. Каких либо специфических проблем со стороны hpux пока не заметил. http://h20000.www2.hp.com/bc/docs/suppo ... 254561.pdf содержит указания по установке, они походят и для 11.31 и для 11.23. Поддерживают все нужные алгоритмы шифрования. Если для W2k8 использовать шифрование RC4-HMAC, то в libdefaults нужно добавить В принципе думаю можно было бы использовать и DES для W2k8R2, но по умолчанию он там отключен и зазря не хотелось понижать безопасность.