Аутентификация Ldap для автономных серверов Windows
В моей среде у меня есть LDAP-сервер Novell eDirectory, через который хранятся пользовательские данные. В моей среде у меня есть набор серверов Windows и Linux. Мне нужно использовать этот LDAP в качестве источника аутентификации для обоих серверов.
Для Linux мне нужно добиться этого, установив linux как LDAP Client и расширенную схему edirectory для пользователей linux, и пользователи могут входить в систему и даже создавать домашние каталоги для пользователя. Но проблема приходит с машинами Windows.
Для машин с Windows я использовал novell gina, которая аутентифицирует пользователя с использованием LDAP, но также требует учетных данных локального или доменного пользователя для входа в локальную систему. Затем для каждого пользователя мне нужно создать локального пользователя в каждой системе, которая не предназначена для цель.
Затем я использовал pgina (еще один Gina с открытым исходным кодом), с помощью которого я могу аутентифицировать пользователя с помощью LDAP, и он создает профиль для пользователя. Хорошо, но он также создает локального пользователя с именем пользователя LDAP. Если какой-либо администратор изменит пароль на локальном компьютере для этого пользователя, то пароль как LDAP, так и локального пользователя не будет синхронизирован.
Как я могу получить имя входа в активную директорию, где он будет аутентифицироваться в активной директории (думаю, AD как LDAP) и создает профиль для вас в локальной системе, но никогда не создает локального пользователя. Любой может пролить свет на это, чтобы решить вопрос?
Спасибо и С уважением,
Солнечно.
1 ответ
Чтобы сделать то, что вы ищете, самым простым способом, вам действительно нужен домен Windows (как говорит @Joel Coel в своем комментарии). Вам не нужно использовать Windows Server для размещения домена - Samba отлично справляется с этой ролью уже много лет, и Samba может выполнять внутреннюю аутентификацию в LDAP.
Использование домена Windows для этого предпочтительнее любых альтернатив, потому что вы используете много клиентского кода, написанного и протестированного Microsoft, а не код, который заново изобретает колесо. Вы можете перейти к более новым версиям Windows, используя домен, вместо привязки к коду (например, pGina), который не работает в более новых версиях Windows.