Samba 3 — клиент в домене Windows (Linux, Windows, О работе) 13.12.2008
Давно собирался написать небольшой manual на эту тему, но каждый раз меня что нибудь останавливало. Сегодня же передо мной в очередной раз встала такая задача, поэтому писать я буду прямо по ходу действия.
Имеем:
- Будущий прокси-сервер на CentOS 5.2 с установленным samba-client и krb5-workstation
- Ныне живущий контроллер домена Active Directory на базе Windows 2003 (для примера буду указывать домен MAIN.LAN с сервером server.main.lan)
- Устойчивое желание иметь на линукс-машине авторизацию доменных пользователей
- Банку кабачковой икры, батон, кофе (опционально) 🙂
Шаг первый: "Время Kerberos"
Правим /etc/krb5.conf
указывая имя домена и сервера который будет нас авторизовывать.
[realms]
MAIN.LAN = {
kdc = server.main.lan
admin_server = server.main.lan
}
Теперь пробуем авторизоваться под учетной записью администратора домена командой:
# kinit [email protected]
если в ответ на эту команду появляются ошибки, типа: kinit(v5): Cannot find KDC for requested realm while getting initial credentials или kinit(v5): KDC reply did not match expectations while getting initial credentials - ищем ошибку в файле /etc/krb5.conf
. Если напротив все прошло без ошибок, смотрим что получилось командой:
# klist
Если в результате проверки появляется ошибка kinit(v5): Clock skew too great while getting initial credentials - часы на linux-машине и windows-сервере помнят разное время. Решить это можно установкой ntp-сервера и синхронизацией часов с серверами точного времени в интернете, но мне этот метод кажется не совсем "прямым". Ведь концептуально наша задача не получить точное время, а получить время одинаковое на обоих машинах. Я в качестве решения выполняю команду
# net time set -S server.main.lan
Так же эту команду можно дописать в файл /etc/rc.d/rc.local
.
Шаг второй: "Samba и Winbind"
Если вы в будущем хотите каким либо образом работать с samba в качестве файл-сервера, то файл /etc/samba/smb.conf
вам придется изучить в любом случае, но сегодня нас интересует только следующий его блок:
[global]
workgroup = MAIN
realm = MAIN.LAN
security = ads
password server = *
encrypt passwords = yes
netbios name = proxy
idmap uid = 10000-20000
idmap gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes
Перезапускаем samba и winbind:
# service smb restart
# service winbind restart
Добавляем linux-машину в домен командой
# net ads join -U [email protected]
Получаем ошибку Failed to set servicePrincipalNames. Please ensure that the DNS domain of this server matches the AD domain, Or rejoin with using Domain Admin credentials. Deleted account for 'proxy' in realm 'MAIN.LAN'. Failed to join domain: Type or value exists ....и удивляемся. 🙂
Маленькая хитрость: в момент выполнения команды net ads join домен резолвится исключительно по файлу /etc/hosts
, который про этот домент само собой и слухом не слыхивал. Добавляем туда соответствующую запись и заводим наконец в домен наш linux-компьютер указанной выше командой. Если все прошло успешно, то ответ на команду:
# wbinfo -t
должен быть - checking the trust secret via RPC calls succeeded. Теперь можно посмотреть список пользователей и групп домена командами:
# wbinfo -u
# wbinfo -g
На этой радостной ноте я закончу этот рассказ, т.к. его продолжение индивидуально для каждой задачи: NTLM-авторизация в Squid на этом этапе уже работает, нужно только поставить этот самый Squid; PAM-авторизацию нужно немного подкрутить, но в моей практике она не всегда необходима; чтобы использовать нашу linux-машину как файл-сервер нужно только описать доступные папки....дальше выбор за вами....