1) Для вариантов "SSO в Амазоне, а LDAP - в офисе" существует IdP Shibboleth. Даёшь ему доступ к LDAP, настраиваешь белый IP, прописываешь в AWS. При входе в AWS-админку IAM Амазона перебрасывает тебя на твой же IdP, который тебя аутентифицирует и отдаёт список доступных ролей назад, в IAM. А дальше всё просто: по этому списку ты становишься авторизован в той или иной роли IAM.
2) Самый простой механизм интеграции предполагает отсутствие кэша, т.к. без говна и палок sshd умеет вызвать внешнее что-то (обычно скрипт), передать ему параметр, вычитать в ответ из stdout публичный ключ. В принципе, этого достаточно (IMHO кэширование ключей - штука спорная, т.к. процесс отзыва становится менее предсказуемым).  Ну и best practice - Наличие emergency-пользователя с локально лежащим приватным ключом.
3) Linux-тачка в AD-домене? Можно, конечно, только зачем? Получать доступ к виндовым шарам? O_o
4) Вот про "LDAP-тормозной" - это точно не надо грязи. Чтобы он начал "тормозить", его надо прям сильно испортить.

Ну и дополнение к 1). Смысл такой конфигурации очень прост: введённый пароль - так же, как и список пользователей в LDAP - никогда не покидает пределов твоей внутренней сети.

Кстати, именно Shibboleth аутентифицирует вас (нас) на Госуслугах.

read-only slave решает удалённость AD и частично - проблему с кеширванием
с бутстрапом не вижу проблем - заводим дефолтный аккаунт, через него сетапим всё что надо, удаляем
вышеупомянутый nslcd умеет в кеширование и решает проблему тормозов

ssh-ключи  он не кеширует (о них, собственно, шла речь, а так - да, умеет)

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

"Набросать" и "готов в продакшн" - две большие разницы, и за пару дней это обычно не происходит. Я называю только production-ready решения, а дальше каждый сам решает, пробовать ли что-то мене стабильное или просто поставить и запустить.

Ну или самостоятельно писать, да.

Как по мне, так там функционал достаточно прост, чтобы за неделю довести это до продакшен состояния. У вас всего две сущности: LDAP-клиент и LRU- или time-based кеш. И то, и другое - не рокет саенс, и для них уже давно уже есть и best-practise, и наборы хороших библиотек.

Про 3-е , я думаю, @AlexAkulov , как и я, имели ввиду добавление Linux тачки в соответствующую группу в AD, чтобы пользователи группы получили доступ.
Типа, если бутстрапит одна команда - тачка в одной группе, если другая - в другой. Ну и они сами настраивают, у каких групп есть доступ к их тачкам. И дальше вся связка с ssh и ключами, паролями, 2fa на основе групп этих работает/чекается

Тут IdP Shibboleth настрой.
Тут скриптик на питоне попиши.
тут локального пользователя создай на случай проблем с лдап.
А как ключ для этого пользователя разложить? Как его быстро сменить на всех тачках если он будет скомпрометирован?
Собстенно я об этом и говорю, LDAP может и работает но с кучей заморочек, а какие он бонусы даёт непонятно. Поэтому зачем вообще нужен этот лдап когда задача просто ключи на хостах разложить?
Вместо того чтобы лдап подкручивать проще взять и всё с нуля написать, я считаю.

Если линукс тачку в домен не добавить как она будет в АД ходить и аутентификацию пользователей производить? Можно конечно на каждом хосте пароль хранить для доступа в АД, но это тоже так себе.

с аутентификацией нет проблем, он делает обычный bind c паролем пользователя, для этого не нужен отдельный аккаунт, вот с авторизацей потом сложнее

пользователь временный, только для бутстрапа, после инициализации он удаляется
Преимущества LDAP как раз в том, что можно динамически всем управлять - удалять, добавлять, менять и т.п.
Как раз из-за этой сложности мы и хотим использовать его через SCM

Ну я даже и не знаю, как же ключ разложить... Может, в других чатах подскажут? А любые другие способы централизованного управления - они что, все в белом и никогда не ломаются?

Никак, если мне память не изменяет. Ибо Керберос.

А почему ты тогда меня спрашиваешь зачем линукс тачку в домен вводить?

Ну есть варианты, когда тачка в домен не входит, а AD - это тупо LDAP-хранилище. Твм же под пароль даже атрибуты разные. Однако хочу заметить, что вопросы интеграции с виндой пакетом Samba решены были уже в 2006 (в рамках обеления софта одной конторы пилил домен AD на Samba)

Да они решены через пень-колоду. Если про полную интеграцию. Чтобы на centos/redhat самба заработала, нужно ее компилить с доп.флагами, иначе ни календарь, ни аутглюк, ничо это норм не работает (да и то).