Вводные данные.
Есть сайт asp во внутренней сети на IIS сервере под 2003 серваком+oracle. Используется всеми российскими офисами (около 3000 чел)
Из внешней сети не доступен.
Появился деманд от бизнеса.
1. Сделать сайт дешевле, (oracle-> mysql, win2003 serv - > centos, IIS->apache, asp-> php)
2. Убрать все железные серваки в Лондон (нельзя в Москве иметь свое железо, только арендовать, либо хостить)
3. Сделать сайт доступным не только из внетренней сети и по vpn, но и с других компов+мобильных устройств и т.п., + с сохранением авторизации
4. Вообще убрать эту наколенную asp поделку и заменить ее каким нибудь стандартным решением

1 и 2 вроде решаемо, 4 то же решили. Нашли php движок, который отвечает всем требованиям.
В 3 главное, столкнулся с выделенным жирным. Бизнес хотит, чтобы было как сейчас - автоизоваться со своими доменными логинами+паролями и горя не знать. А если, типа, из внутренней сети, то чтобы сайт их вообще без всякой авторизации узнавал.

Как сделать доменную авторизацию из внешнего php хостинга?
п.с. Портами AD я не рулю, они рулятся бритиш телекомом, что то просить их открыть - бесполезно

дак если vpn то какая разница где хостинг?

(1) vpn только по сертификатам, привязанным к устройству.
Просто так с домашнего компа или нового телефона ты в впн не зайдешь. Из за этого мне постоянно приходится таскать между домом и работой сертифицированный ноут.
А так да, с сертифицированным ноутом - без разницы.

(2) это по каким сертификатам? Вроде там открытый и закрытый ключи только. Формируешь открытый на домашнем компе, высылаешь админу, он закрытый генерит. Ну или сам, если сам админ, подключившись с того же ноута.

(3) учитывая, что мой админ - бритиштелеком, и хрен с два он мой ключ возьмет, - то какая разница

(5) а они точно к устройству привязаны? На ноуте-то у тебя он есть. Обычный файлик, копирнуть на домашний и будет пускать.

sda553 Просто так с домашнего компа или нового телефона ты в впн не зайдешь.

так смотри в техусловии ты пишешь что надо и через vpn и без vpn чтобы работала авторизация через ntlm

(0) SAMBA + настроить в качестве SDC/PDC в зависимости от нужд.

(7)(9) а как одинэсники с этим живут?

(14) там хрень про IIS + ntlm а у тебя ведь apache

Если такой вариант:
1. Делаем внутренний сайт. Юзер заходит на сайт со своего сертифицированного ноута, проходит доменную авторизацию, опознается и получает файл-ключ
2. Этот файл он кладет на свой сторонний девайс: домашний комп, планшет или еще чего. Тот создает кукизу для внешнего сайта
3. Юзер заходит с этого стороннего девайса на внешний сайт, сайт проверяет кукиз-ключ, опознает юзера и радостно с ним работает
Соответственно внутрений и внешний сайт регулярно обмениваются ключами.
Есть уже какое нибудь готовое стандартное решение с похожим функционалом?

(17) Уязвимость при перехвате кукисов - грабак полно.

(18) ну кукиза при установке вписывает в ключ ид девайса и тот же кукиз с другого девайса уже не принимается, к примеру. Да и кукизу я к примеру привел. плюс https

(19) ИМХО, хлипко, да и, незачем.
В (16) сказано абсолютно верно.

почему всех нельзя за vpn посадить?

(21) Потому что британцы не выдают vpn сертификаты на любые девайсы просто так. Только на корпоративные девайсы с исключительно заранее утвержденным билдом. Домашний комп и уж тем более мобильному подключиться к vpn не разрешается.
Я же уже говорил, что мне приходиться ноут между домом и работой таскать

sda553 Потому что британцы не выдают vpn сертификаты на любые девайсы просто так. Только на корпоративные девайсы с исключительно заранее утвержденным билдом. Домашний комп и уж тем более мобильному

и поэтому ты хочешь проковырять дыру размером с автобус?

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

(24) Готов по-спорить, что из-за авторизации ничего у вас не выйдет

Если я и дальше пойду расширять пакет внешних решений, то сайтов на внешних хостингах со временем станет много, а юзерам придется от каждого хранить логин-пароль. Не дело. Для 3к юзеров, постоянно забывающих пароли, поддержка помрет от нагрузки

(26) Ты же вроде не админ, зачем берешь на себя архитектурную задачу?
Т.е., грубо, двигатель я нашел, а вот к какому забору его пристроить не знаю.

(27) это не архитектурная задача, а скорее концептуальная - как строить ит решения в тяжелых условиях отсутствия "своих" серверов

(28) Без специальных знаний не взлетит, ИМХО, всё равно, что с кулинарным образованием пилотировать сверхсзвуковой лайнер.

Чего я уже только не пилотировал в ит за время своей работы. утро вечера мудренее

(30) тож спать ;)