Які необхідні кроки для аутентифікації користувачів з Active Directory, що працює на Windows Server 2012 R2 у FreeBSD 10.0, використовуючи запуск sssd
AD з використанням Kerberos TGT?
Які необхідні кроки для аутентифікації користувачів з Active Directory, що працює на Windows Server 2012 R2 у FreeBSD 10.0, використовуючи запуск sssd
AD з використанням Kerberos TGT?
Відповіді:
Є деякі складні міркування щодо того, щоб все працювало нестандартно. sssd
На даний момент FreeBSD підтримує версію 1.9.6. Таким чином, немає підтримки для основних імен підприємств.
Якщо у вас є домен із невідповідними UPN, він не зможе ввійти, оскільки автентифікація Kerberos не вдасться під час процесу, навіть якщо FreeBSD підтримує основні імена підприємства з Kerberos, це sssd
не вдається обробити цей випадок.
Отже, у фактичній версії sssd
ви маєте обмеження мати головне ім’я користувача у межах одного доменного імені, наприклад:
Domain Name = example.com
NetBIOS Name = EXAMPLE
User Principal Name:
username@example.com sAMAccountName: username
Знаючи це, ми можемо описати кроки для успішної аутентифікації користувачів від AD у FreeBSD.
Створіть файл /etc/krb5.conf
із таким вмістом:
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = yes
Встановіть Samba 4.1:
$ pkg install samba41
Створіть файл /usr/local/etc/smb4.conf
із таким вмістом:
[global]
security = ads
realm = EXAMPLE.COM
workgroup = EXAMPLE
kerberos method = secrets and keytab
client signing = yes
client use spnego = yes
log file = /var/log/samba/%m.log
Запитайте у адміністратора Квіберовий квиток:
$ kinit Administrator
Потім приєднайтесь до домену та створіть вкладку ключів
$ net ads join createupn=host/server-hostname.example.com@EXAMPLE.COM -k
$ net ads keytab create -k
Встановіть необхідні пакети:
$ pkg install sssd cyrus-sasl-gssapi
Відредагуйте файл /usr/local/etc/sssd/sssd.conf
відповідно до цих налаштувань:
[sssd]
config_file_version = 2
services = nss, pam
domains = example.com
[nss]
[pam]
[domain/example.com]
# Uncomment if you need offline logins
#cache_credentials = true
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad
# Comment out if the users have the shell and home dir set on the AD side
default_shell = /bin/tcsh
fallback_homedir = /home/%u
# Uncomment and adjust if the default principal SHORTNAME$@REALM is not available
#ldap_sasl_mech = GSSAPI
#ldap_sasl_authid = SERVER-HOSTNAME$@EXAMPLE.COM
Відредагуйте файл /etc/nsswitch.conf
відповідно до цих налаштувань:
group: files sss
passwd: files sss
Встановіть додаткові пакети для створення домашнього каталогу:
$ pkg install pam_mkhomedir
Змініть необхідні PAM
області, щоб відповідати цим параметрам:
auth sufficient /usr/local/lib/pam_sss.so
account required /usr/local/lib/pam_sss.so ignore_unknown_user
session required /usr/local/lib/pam_mkhomedir.so mode=0700
session optional /usr/local/lib/pam_sss.so
password sufficient /usr/local/lib/pam_sss.so use_authtok
$ pkg remove -f openldap-client
$ pkg install openldap-sasl-client
$ getent passwd <username>
Який Керберос ви тут використовуєте? Вбудований або безпечний / krb5 від MIT?
Встановлюючи sssd, потрібно встановити захист / krb5, який на даний момент досі вважається експериментальним у FreeBSD. Таким чином це питання.
Мені не пощастило отримати користувачів / груп AD під час виконання команд "getent". це може бути пов'язано з тим, що ім'я NETBIOS відрізняється від доменного імені - тобто в моєму випадку доменне ім'я - dawnsign.com, а ім'я NETBIOS - DSP.
Я налаштував лише модуль входу pam.d. Які ще модулі пам’яті потрібно редагувати, щоб пройти успішну аутентифікацію?
Будь-яка додаткова інформація буде дуже вдячна!
Перекомпілюючи samba4 з портів можна використовувати аутентифікацію winbind, як Linux, навіть без sssd. Просто перекомпілюйте samba4 з портів після включення sasl ldap
pkg remove samba41
pkg install cyrus-sasl-gssapi samba36-libsmbclient pam_mkhomedir ldb
pkg remove -f openldap-client
pkg install openldap-sasl-client
cd /usr/ports/security/sssd && make install
Це перекомпілює samba з усією необхідною підтримкою (gssapi, ldap, kerberos), а потім відредагуйте nsswitch.conf, як це
passwd: files winbind
group: files winbind
Привіт,
Це невелике оновлення щодо використання sssd v1.11.7
Якщо ви використовуєте "id_provider = ad" і ви бачите таку помилку в файлі журналу sssd:
/var/log/sssd/sssd_example.com.log
(Sun Oct 5 18:41:37 2014) [sssd[be[alidaho.com]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-12)[Not Supported]
(Sun Oct 5 18:41:37 2014) [sssd[be[alidaho.com]]] [sasl_bind_send] (0x0080): Extended failure message: [unknown error]
Ви можете скористатися наведеною нижче процедурою, щоб вирішити цю проблему та змусити інтеграцію AD правильно працювати. Тепер побудуйте sssd v1.11.7 з підтримкою Samba, потрібна побудова з src sssd, так що це пов'язано з libsasl2
pkg remove samba41
pkg install cyrus-sasl-gssapi samba36-libsmbclient pam_mkhomedir ldb
pkg remove -f openldap-client
pkg install openldap-sasl-client
cd /usr/ports/security/sssd && make install
Установка (і весела упаковка та проблеми залежностей)
/usr/bin
, а інший в /usr/local/bin
. Оскільки, здається, жоден з базових системних файлів не міститься в пакеті, ви не можете просто видалити речі Heimdal KRB. Щось слід пам’ятати.Переможна залежність різних пакетів (цікаві відмітки жирним шрифтом, конфліктні депи - жирним курсивом):
net-mgmt/adcli:
net/openldap24-sasl-client
security/cyrus-sasl2-gssapi: security/cyrus-sasl2
net/openldap24-sasl-client: security/cyrus-sasl2
security/sssd: security/nss
security/sssd:
security/krb5
security/sssd: security/cyrus-sasl2
security/sssd:
net/openldap24-client
security/sssd: lang/python27
security/sssd: lang/python2
security/sssd: dns/c-ares
security/sssd: devel/tevent
security/sssd: devel/talloc
security/sssd: devel/popt
security/sssd: devel/pcre
security/sssd: devel/libunistring
security/sssd: devel/libinotify
security/sssd: devel/gettext-runtime
security/sssd: devel/ding-libs
security/sssd: devel/dbus
security/sssd: databases/tdb
security/sssd: databases/ldb
Зворотні залежності різних пакетів:
net/openldap24-sasl-client: sysutils/msktutil
net/openldap24-sasl-client: net/nss-pam-ldapd-sasl
net/openldap24-sasl-client: net-mgmt/adcli
sssd
, потрібен MIT Kerberos, навіть якщо у нас є Heimdal в якості базового пакетуadcli
хоче openldap-sasl-client
, але входять інші пакети (включаючи підзалежності sssd
) openldap-client
, що є mutex з клієнтом sasl (з будь-якої дурної причини). Це спричиняє біль при установці навіть при мінімальному наборі двійкових пакетів.Станом на це написання, двійковий pkg для SSSD для FreeBSD не включає підтримку AD в SSSD
SMB
adcli
існує, але станом на цей текст не працює.
GSSAPI_MIT
cyrus-sasl-gssapi
Потрібно, але бінарна версія pkg не працює, і має незвичайні проблеми залежності, які призводять до видалення SSSD.
GSSAPI_MIT
openldap-sasl-client
потрібен для функціональності, але SSSD хоче задіяти не-SASL-версію openldap.
openldap-sasl-client
за допомогою GSSAPI
параметра, вибраного ( make config
) у портах.pkg remove –f openldap-client
openldap-client
не роблячи жодних авторемонтів будь-яких інших пакетів (наприклад, SSSD) та дозволить встановити версію SASLopenldap-sasl-client
pkg remove –f sssd
(Необов’язково) Після того, як все працює і перевірено, ви можете використовувати pkg create
для створення бінарних пакетів з чотирьох пакетів з увімкненими належними параметрами та використовувати ті замість того, щоб будувати їх у портах у кожній системі. Встановлення двійкового файлу відбувається за аналогічною схемою для процесу збирання портів:
pkg install sssd-1.11.7_8.txz
pkg add
інші пакети (не встановлювати, додавати), зберігаючи пакет openldap останнім часом.openldap-sasl-client
зробітьpkg remove –f openldap-client
pkg add openldap-sasl-client-2.4.44.txz
pkg create
щоб замінити залежність від openldap-client
з , openldap-sasl-client
щоб позбутися від необхідності робити це видалити / перевстановити. У мене не було часу займатися цим.
openldap-client
виправлення.Конфігурація Kerberos:
[libdefaults] default_realm = MYDOMAIN.NET forwardable = вірно # Зазвичай все, що вам потрібно в середовищі AD, оскільки DNS SRV записує # ідентифікує сервери / послуги AD / KRB. Прокоментуйте, якщо ви # хочу вручну вказати на ваш AD-сервер dns_lookup_kdc = вірно [царства] MYDOMAIN.NET = { # Якщо ви вручну вказуєте на інший сервер AD, ніж на DNS # admin_server = adserver.mydomain.net # kdc = adserver.mydomain.net } [domain_realm] mydomain.net = MYDOMAIN.NET .mydomain.net = MYDOMAIN.NET
[sssd] config_file_version = 2 домени = MYDOMAIN.NET послуги = nss, pam, pac запасний_хомедір = / домашній /% u [домен / MYDOMAIN.NET] id_provider = оголошення access_provider = оголошення auth_provider = оголошення chpass_provider = оголошення # використовувати атрибути AD POSIX, коментуйте, якщо ви використовуєте автоматично створені # UID та GID. ldap_id_mapping = Неправильно cache_credentials = вірно ad_server = adserver.mydomain.net # якщо у вас немає bash, або будь-якого іншого, що є в обліковому записі AD # атрибут встановлений override_shell = / bin / tcsh
/etc/pam.d
файлів, які мені довелося змінити, щоб змусити SSSD працювати з FreeBSD:/etc/pam.d/sshd:
# # $ FreeBSD: releng / 11.0 / тощо / pam.d / sshd 197769 2009-10-05 09: 28: 54Z des $ # # Конфігурація PAM для послуги "sshd" # # авт auth достатньо pam_opie.so no_warn no_fake_prompts автентичний необхідний pam_opieaccess.so no_warn enable_local #auth достатньо pam_krb5.so no_warn try_first_pass #auth достатньо pam_ssh.so no_warn try_first_pass auth достатньо pam_unix.so no_warn try_first_pass nullok auth достатньо pam_sss.so use_first_pass потрібний auth pam_unix.so no_warn use_first_pass # рахунок потрібен обліковий запис pam_nologin.so #account потрібно pam_krb5.so потрібен обліковий запис pam_login_access.so потрібен обліковий запис pam_unix.so рахунок достатній pam_sss.so # сесія # сесія необов'язково pam_ssh.so want_agent сесія за бажанням pam_sss.so потрібен сеанс pam_mkhomedir.so mode = 0700 потрібен сеанс pam_permit.so # пароль #password достатній pam_krb5.so no_warn try_first_pass #password достатній pam_unix.so try_first_pass use_authtok nullok пароль достатній pam_unix.so try_first_pass use_authtok пароль достатній pam_sss.so use_authtok
/etc/pam.d/system:
# # $ FreeBSD: releng / 11.0 / тощо / pam.d / system 197769 2009-10-05 09: 28: 54Z des $ # # Загальносистемні параметри за замовчуванням # # авт auth достатньо pam_opie.so no_warn no_fake_prompts автентичний необхідний pam_opieaccess.so no_warn enable_local #auth достатньо pam_krb5.so no_warn try_first_pass #auth достатньо pam_ssh.so no_warn try_first_pass #auth потрібно pam_unix.so no_warn try_first_pass nullok auth достатньо pam_unix.so no_warn try_first_pass auth достатньо pam_sss.so use_first_pass потрібен auth pam_deny.so # рахунок #account потрібно pam_krb5.so потрібен обліковий запис pam_login_access.so потрібен обліковий запис pam_unix.so рахунок достатній pam_sss.so # сесія # сесія необов'язково pam_ssh.so want_agent потрібен сеанс pam_lastlog.so no_fail сесія за бажанням pam_sss.so потрібен сеанс pam_mkhomedir.so mode = 0700 # пароль #password достатній pam_krb5.so no_warn try_first_pass #password потрібно pam_unix.so no_warn try_first_pass пароль достатній pam_unix.so no_warn try_first_pass nullok use_authtok пароль достатній pam_sss.so use_authtok #password обов'язковий pam_deny.so
/etc/pam.d/su:
# # $ FreeBSD: releng / 11.0 / тощо / pam.d / su 219663 2011-03-15 10: 13: 35Z des $ # # Конфігурація PAM для послуги "su" # # авт auth достатній pam_rootok.so no_warn auth достатньо pam_self.so no_warn автентична пам’ятка pam_group.so no_warn group = колесо root_only fail_safe ruser auth включають system.dist # рахунок Обліковий запис включає system.dist # сесія потрібен сеанс pam_permit.so
(відступ)
system.dist
є копією /etc/pam.d/system
файлу акцій . Він включений у /etc/pam.d/su
файл вище, щоб запобігти проблемам із командою su.su
зазначати облікові записи AD як корінь, оскільки один раз root su
не потребує автентифікації, і інформація про обліковий запис переноситься через службовий комутатор імен через SSSD.sudo
з міркувань безпекиksu
що працює для переходу від користувача A до користувача B
ksu
(in /usr/bin
) не встановлено SUID
ksu
працювати,chmod u+s /usr/bin/ksu
krb5
пакет, встановлений в /usr/local/bin
) - це SUID при встановленні/usr/local/bin
це було раніше /usr/bin
, тощоksu
підкаже користувачеві пароль для AD / Kerberos пароля цільового користувачаpasswd
не працюватиме, щоб змінити пароль AD / Kerberos, навіть якщо ви додасте pam_sss.so
файл PAM-файл passwd. passwd
Двійкова підтримує тільки локальну і NIS Використання kpasswd
змінити пароль на AD / сервер Kerberos (s).Перемикач обслуговування імен:
/etc/nsswitch.conf
Файл повинен бути налаштований на використання SSS сервісу для паролів і груп. Приклад:
group: files sss
passwd: files sss
Приєднання до домену:
adcli
kinit
перед використанням, він робить це для вас на основі наданих кредитів.
adcli join -D mydomain.net -U Administrator--show-details –v
adcli join –H adclient.mydomain.net -D mydomain.net -U Administrator --show-details -v
net
Утиліта
Sambanet
Утиліта є частиною пакета Samba.smb.conf
файлі конфігурації, що ускладнює та незручно користуватися, особливо неінтерактивно.kinit
. Знову ж таки, це незручніше і робить його трохи складніше використовувати неінтерактивний сценарій, оскільки замість одного є два кроки.
Міркування щодо SSHD:
/etc/ssh/sshd_config
GSSAPIAuthentication yes
PasswordAuthentication yes
ChallengeResponseAuthentication yes
PasswordAuthentication no
під час використання цієї опції./bin/passwd
, який не підтримує нічого, крім NIS та локального файлу passwd.GSSAPICleanupCredentials yes
kdestroy
після виходуGSSAPIStrictAcceptorCheck no
host/<FQDN>@REALM
для розмови з KDC, але іноді він помиляється (наприклад, якщо ім'я хоста не відповідає імені DNS сервера SSH). Ця опція дозволяє SSHD використовувати будь-який головний /etc/krb5.keytab
файл, який включає належнеhost/<FQDN>@REALM
ssh -K <ip>
щоб вони працювали, не вимагаючи введення пароля (припускаючи, що ви вже зробили 'kinit', звичайно).