Comments 15
В экосистеме Windows есть прекрасные нативные решения для файл-серверов, где не нужно вот это всё.
Для меня уже много лет загадка, зачем люди упорно пытаются превратить Linux в Windows?
Зачем вы файл-сервер Linux вставляете в домен Windows? Что вам мешает сразу взять файл-сервер Windows?
При выполнении проектов импортозамещения предприятиям нужно заменить службу каталога Active Directory и файловые сервера Windows на что-то альтернативное. Мы предлагаем службу каталога ALD Pro на базе FreeIPA и файловый сервер на базе Samba
В таком случае вы должны предлагать и рабочие станции на импортозамещённой ОС.
Так вот суть вопроса Вы не уловили: зачем у Вас вся инфраструктура на Linux использует механизмы Windows?
Вы пытаетесь, как китайцы, чтоб с виду BMW, а внутри хрензнаетчто?
ALD Pro - это служба каталога из экосистемы группы компаний Астра, поэтому основной операционной системой для нас является Astra Linux, но скоро появится поддержка и других отечественных дистрибутивов
По поводу использования технологий Windows действительность такова, что в корпоративном секторе распространены были именно эти продукты, и часто возникают ситуации, когда большую инфраструктуру нельзя перевести на новые рельсы по одному указу щелчку пальцев. Поэтому мы в команде ALD Pro понимаем, что должен существовать некоторый переходный период, и прорабатываем механизмы для гибридного развёртывания
Штирлиц сел в раскоряку и побежал вприпрыжку
Но стабильность ещё не завезли...
и не завезут, потому что если взять разных продуктов от разных разработчиков, скрутить это всё на проволоку с изолентой, а дырочки замазать пластилином..
в общем, стабильность конструкции не может быть выше стабильности любого из отдельных её компонентов.
В продуктах Microsoft изоленты, пластилина и проволоки тоже предостаточно - чем глубже погружаешься в технологии MS, тем более очевидны эти костыли, но это не важно, а главное, что эти костыли работают. И для успешного импортозамещения нам важно, чтобы было решение всех ключевых бизнес-задач, над чем мы и работаем
Создают учетную запись сервиса «krbprincipalname=cifs/fs-1.ald.company.lan@ALD.COMPANY.LAN» в контейнере «cn=services,cn=accounts,dc=ald,dc=company,dc=lan».
Как-то переводил вебсервис с windows сервера на Debian, попутно меняя метод аутентификации с NTLM на kerberos. И долго не мог понять, почему у меня сквозная авторизация в windows домене не проходит. Всё по мануалам, сертификаты валидные, права у служебной уз все есть. Пока учётку вебсервиса не переместил в cn=users в корне домена. Не нравилось ей в сервисах жить и всё тут.
Учетная запись cifs-службы в LDAP-каталоге нужна для того, чтобы центр распространения ключей MIT KDC мог выписать пользователю сервисный билет
На сервере FreeIPA данный компонент выполняет поиск сервисных учёток по всему каталогу (scope=SUBTREE), начиная с корневой записи домена "dc=ald,dc=company,dc=lan". Поэтому сейчас должно работать вне зависимости от местоположения сервисной учетной записи в каталоге. Но лучше, конечно, учётные записи не перемещать
Создают учетную запись сервиса «krbprincipalname=cifs/fs-1.ald.company.lan@ALD.COMPANY.LAN» в контейнере «cn=services,cn=accounts,dc=ald,dc=company,dc=lan».
Выгружают ключи этой учетной записи в keytab-файл /etc/samba/samba.keytab, содержимое которого можно посмотреть с помощью утилиты klist. Ключи нужны службе Samba для расшифровки Kerberos-билетов пользователей.
У вас файл-сервер является членом ALD домена, на нем уже находится настроенный sssd, который уже создал в LDAP учетную запись хоста krbprincipalname=host/fs-1.ald.company.lan@ALD.COMPANY.LAN. Так почему нельзя добавить cifs/fs-1.ald.company.lan@ALD.COMPANY.LAN к этой же учетке и использовать тот же keytab (системный) что и sssd демон? Или так нельзя сделать? В MS AD как раз так и работает в servicePrincipalName аттрибуте хоста.
Прожил в конце нулевых с файл-сеовером на самбе(тогда ещё 3й) и freebsd пару лет. Это был интересный опыт, куча проблем ( в основном с гибкостью ntacl) и осознал, что экономия на покупке windows сервера никак не имела смысла, кроме получения опыта.
Судя по статье, самба не особо по изменилась (ну кроме работы по Kerberos и отсутствию winbindd). Сейчас я вообще не представляю смысл работы с пользовательскими шарами без прелестей DFS и всяких плюшек типа дедуплекации.
Файловый сервер Samba позволяет создавать пространства имён распределенной файловой системы DFS-Namespaces, но есть ряд существенных ограничений:
Сервер Samba поддерживает только stand-alone пространства, которые физически размещаются на том же сервере, к которому обращается DFS-клиент, а domain-based пространства - это уже не к Самбе.
Клиенты DFS не умеют использовать результаты автоматического обнаружения контроллеров домена и обращаются к серверу просто по имени, поэтому им нужно, чтобы DNS-сервер умел поднимать вверх списка A-записи ближайших к ним контроллеров, используя информацию о сетях, привязанных к сайтам. Но этого не умеет делать ни встроенный DNS-сервер, ни Bind9, поэтому в больших инфраструктурах клиент будет сходить с ума в поисках контроллера, который сможет ему ответить.
В мире Linux альтернативой технологии DFS-Namespaces являются карты автоматического монтирования дисков, и в FreeIPA & SSSD технически уже есть реализация необходимых инструментов, поэтому мы планируем задействовать этот механизм.
По поводу "плюшек" от Windows - Linux предоставляет множество возможностей, в т.ч. использование различных файловых систем, например zfs, btrfs, которые предоставляют дополнительную функциональность и дедупликацию в частности.
"Общий ресурс можно подключить, например, средствами FUSE в пространстве пользователя. Если требуется временный доступ, то в адресной строке можно просто вбить адрес smb://file-1.ald.company.lan/test_share"
При попытке доступа с клиента ALSE 1.7.х который не принадлежит домену, этот вариант не работает.... Также не получается монтировать через CIFS. Не удается подключиться и через fly-fm - не появляется запрос логин/пароль!
Работает только подключение через SMBCLIENT (smbclient //fs01/publilc/ -U 'ald.lan\admin')
На других дистрибутивах через GUI (с машиной НЕ В ДОМЕНЕ) Mint/Debian/Ubuntu все прекрасно работает - спрашивает логин и пароль! Также работают и Windows клиенты...
Данное поведение наблюдается на 2.4.0 - 2.4.1...
Разбираемся с работой SAMBA в корпоративном домене