Letysite.ru

IT Новости с интернет пространства
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Linux directory server

[Active Directory] Ubuntu в домене Windows AD

Некоторое время назад на работе достался мне для работы ноутбук HP ProBook 6460b. Ну и пришла в голову идея поставить на него вместо надоевшей Windows 7 Pro давно понравившуюся мне Ubuntu 14.04 Trusty LTS. Выбор операционной системы связан с тем, что Ubuntu я использую на домашнем ноутбуке и мне захотелось иметь такую же систему на рабочем компьютере. Потому, что постоянное переключение между ОСями дома и на работе быстро надоело мне и я решился на установку Ubuntu на рабочем ноуте.

Начну по порядку

Процесс установки Убунты на ноутбук не буду пересказывать потому, что не вижу в этом смысла из-за большого количества таких мануалов на просторах интернета. Скажу только то, что устанавливал с флешки, а образ на флешку писал на рабочем ноутбуке под Windows 7 Pro с помощью программы Rufus. Хватит про установку, перейдем к процессу введения в домен.
При вводе в домен Windows я пользовался стандартной инструкцией по вводу в домен. В процессе ввода в домен возникали проблемы самого разного характера (в основном связанные с моей невнимательностью и легкой кривизной рук 🙂 ). Да инструкция на русском языке есть и она довольно хороша, но я все же пользовался не только этой инструкцией, но и другими подсказками с прочих сайтов и форумов. Поэтому я решил собрать из всех одну свою.

Первое что необходимо сделать это — правильно и вполне логично! — обновиться:

Далее нас потребуется установить клиенты Kerberos , Samba и Winbind для нормальной и адекватной работы в домене Windows . Сделать это можно одной командой:

Лично я пробовал два варианта установки: первый — как указано выше — установка всех необходимых пакетов одной строкой, и второй — установка каждого паке в отдельности. Честно признаюсь, что меня больше устроил и больше понравился вариант отдельной установки каждого пакета. Поясню это тем, что при комплексной установке у меня начальная настройка пакета Kerberos не происходила, и я решил (точнее не решил, а мне пришлось из-за кривизны рук и невнимательности переустанавливать полностью Ubuntu и соответственно все необходимые пакеты) ставить все пакеты по отдельности в вышеуказанном порядке. Это дало свои плоды. На этапе установки пакеты Kerberos произошла его полная настройка где указывались все необходимые параметры для работы в домене (собственно сам домен, необходимые для авторизации DC , рабочие группы или зоны). Далее я поставил Самбу и Винбинд с которыми каких-либо заморочек не было. Так же я установил указанные желательными библиотеки libpam-krb5 , libpam-winbind и libnss-winbind . Их я устанавливал одной командой, т.к. они не требуют никаких ручных настроек и просто желательно их присутствие в системе.

Для простоты и дальнейшей ясности процесса будем считать нашим доменом по умолчанию DOMAIN.RU , доменконтроллером которого будет first.domain.ru с ip-адресом 192.168.1.2 . Он же будет нашим первичным DNS сервером домена. Коме того представим в нашем домене еще один доменконтроллер second.domain.ru с ip-адресом 192.168.1.3 . Ну и компьютер наш будет называться work-ubuntu .

Настройка DNS

Для начала необходимо изменить настройки DNS на вашей машине, прописав в качестве DNS-сервера доменконтроллер и в качестве домена поиска — нужный домен. Если у вас статический IP-адрес, то в Ubuntu Desktop это можно сделать через Network Manager, в Ubuntu Server необходимо изменить содержимое файла /etc/resolv.conf на примерно такое:

В современных дистрибутивах файл resolv.conf создается автоматически и править вручную его не нужно. Для получение нужного результата нужно добавить необходимые изменения в файл: /etc/resolvconf/resolv.conf.d/head . Данные которые будут добавлены в него, будут автоматически вставлены в файл /etc/resolv.conf . Если IP-адрес динамический и присваивается DHCP сервером то после перезагрузки resolv.conf может формироваться “неправильный” resolv.conf , например присутствует только один nameserver 192.168.1.1 и не указаны domain и search . Нужно отредактировать /etc/dhcp/dhclient.conf . Чтобы появились записи domain и search нужно убрать комментарий перед строкой supersede domain-name , и вписать свой домен:

Можно было бы добавить еще один nameserver , но я этого делать не стал потому, что у нас в сети компании он единственный. Для применения изменений необходимо перезапустить службу:

Теперь необходимо проверить файл /etc/hostname и убедиться в том, что мы правильно задали имя нашего ноутбука.

Кроме всего прочего необходимо отредактировать файл /etc/hosts так, чтобы в нем была запись с полным доменным именем и обязательно с коротким именем. У меня получился такой формат:

Сразу необходимо проверить, что наш контроллер домена пингуется нормально по короткому и по полному доменному именам:

Не обязательно конечно, но как говорится в инструкции “желательно” при внесении каких-либо изменений делать перезагрузку. Лично я так и делал.

Настройка синхронизации времени

Тут собственно говоря ничего сложного! Я просто единожды выполнил команду:

и забыл про это дело. Другие варианты развития я не вижу смысла освещать в статье т.к. они мне не понадобились.

Собственно переходим к самому основному: настройка авторизации через Kerberos

Настройка авторизации по протоколу Kerberos осуществляется простым редактированием файла /etc/krb5.conf . Вот примерный его вид:

Вы естественно указываете вместо DOMAIN.RU и first свои домен и контроллер домена. Особое внимание обращаю на соблюдение регистра — все что написано в верхнем регистре пишется в верхнем регистре!

Это конечно далеко не все, что настраивается но уже сейчас возможно проверить способность авторизации в домене. Для этого достаточно выполнить команду:

Вместо vasya и DOMAIN.RU вы так же указываете свои имя пользователя и домен. Команда так же регистрозависима! Если вы после выполнения данной команды получаете завпрос на ввод пароля от указанного пользователя и не получаете никаких ошибок, значит у вас все прекрасно. В противном случае еще раз перепроверьте все измененные вами файлы на правильность (внимательно изменяйте все ваши файлы).

Убедиться в том, что билет получен, можно с помощью команды:

Будем считать, что авторизация вы настроили и билет получен. Теперь настроим вход в домен.

Настройка Samba и вход в домен

Для того, чтобы войти в домен, необходимо прописать правильные настройки в файле /etc/samba/smb.conf . На данном этапе нас интересуют только некоторые параметры секции [global] . Вот примерный вариант файла:

Теперь необходимо проверить внесенные изменения на правильность (точнее себя на внимательность и руки на кривость 🙂 ) следующей командой:

В случае правильного изменения файла /etc/samba/smb.conf вы увидите примерно следующее:

Данное сообщение известит вас о том, что вы правильно внесли все изменения и настала пора наконец-таки осуществить вход в домен. Для этого необходимо выполнить следующую команду:

В случае успешного входа вы увидите на экране примерно следующее:

Я снова не стану описывать все возможные ошибки, потому что и ежу понятно, что если появились ошибки значит ты сделал что-то не так. Поэтому скажу только одно: RTFM friend!

На данном этапе вы можете установить себе smbclient :

и проверить доступность ресурсов, хотя бы, на доменконтроллере:

Вы должны будете увидеть список доступных ресурсов на доменконтроллере

Переходим к настройке Winbin

Если вам необходимо работать с пользователями домена, например, настраивать SMB-шары с разграничением доступа, то вам понадобится кроме самой Samba ещё и Winbind — специальный демон, служащий для связи локальной системы управления пользователями и группами Linux с сервером Active Directory . Проще говоря Winbind нужен, если вы хотите видеть пользователей домена на своём компьютере с Ubuntu.

Читать еще:  Linux etc shadow

Winbind позволяет спроецировать всех пользователей и все группы AD в вашу Linux систему, присвоив им ID из заданного диапазона. Таким образом вы сможете назначать пользователей домена владельцами папок и файлов на вашем компьютере и выполнять любые другие операции, завязанные на пользователей и группы.

Для настройки Winbind используется всё тот же файл /etc/samba/smb.conf . Добавьте в секцию [global] следующие строки:

Строки с параметрами idmap config указаны с новыми параметрами не характерными для старых версий Samba, поэтому на данном этапе будьте внимательнее. Старый формат этих строк можно посмотреть в официальной инструкции по вводу в домен.

Теперь вам необходимо перезапустить демон Winbind и Samba . Для этого соблюдая порядок команд, выполните их поочередно:

Смотрим есть ли ошибки или предупреждения, если появится: rlimit_max: rlimit_max (1024) below minimum Windows limit (16384) , то отредактировать файл /etc/security/limits.conf :

После перезапуска проверьте, что Winbind установил доверительные отношения с AD командой

А так же, что Winbind увидел пользователей и группы из AD командами:

Эти две команды должны выдать список пользователей и групп из домена соответственно. Либо с префиксом DOMAIN , либо без него — в зависимости от того, какое значение вы указали параметру winbind use default domain в /etc/samba/smb.conf .

Итак, Winbind работает, однако в систему он еще не интегрировал.

Добавление Winbind в качестве источника пользователей и групп

Для того, чтобы ваша Ubuntu прозрачно работала с пользователями домена, в частности, чтобы вы могли назначать пользователей домена владельцами папок и файлов, необходимо указать Ubuntu использовать Winbind как дополнительный источник информации о пользователях и группах.

Для этого измените две строчки в файле /etc/nsswitch.conf :

добавив к ним в конце winbind :

Так же рекомендую привести строку hosts: в файле /etc/nsswitch.conf к виду:

Теперь можно проверить, что Ubuntu запрашивает у Winbind информацию о пользователях и группах выполнив по очереди следующие команды:

После выполнения первой команды вы должны увидеть содержимое вашего файла /etc/passwd и пользователей вашего домена AD из указанного диапазона в файле /etc/samba/smb.conf . Вторая команда вернет все то же самое, только для групп.

Авторизация в Ubuntu через пользователей домена

Несмотря на то, что все пользователи домена фактически стали полноценными пользователями системы (в чём можно убедиться, выполнив последние две команды из предыдущего раздела), зайти ни под кем из них в систему всё ещё нельзя. Для включения возможности авторизации пользователей домена на компьютере с Ubuntu необходимо настроить PAM на работу с Winbind .

Он-лайн авторизация

Для он-лайн авторизации я лично подредактировал парочку файлов. Первый файл, который я редактировал это /etc/pam.d/common-session и добавил в него всего одну строчку:

Вторым был файлик /etc/lightdm/user.conf . В него необходимо добавить строчку в самый конец файла:

На этом собственно говоря все готово! Перезагружаемся и входим под учетной записью доменного пользователя.

Офф-лайн авторизация

Часто возникает ситуация, когда домен-контроллер недоступен по различным причинам — профилактика, отключение света или вы принесли ноутбук домой и хотите поработать. В этом случае для Winbind можно настроить кэширование учетных записей пользователей домена. Для этого необходимо сделать следующее. Добавьте в секцию [global] файла /etc/samba/smb.conf следующие строки:

Обычно этого достаточно. Если же возникают ошибки, то необходимо создать файл /etc/security/pam_winbind.conf со следующим содержанием:

Файл /etc/pam.d/gnome-screensaver в таком случае принимает вид:

А также изменяется файл /etc/pam.d/common-auth :

На этом вроде бы все 🙂

Вместо заключения

После всех проделанных операций наша машина на Ubuntu стала полноценным членом домена Windows и теперь с ней могу работать пользователи AD .

Было мягко говоря не легко. Тяжело было собрать информацию, относящуюся именно к моей Ubuntu 14.04 Trusty LTS .

Linux directory server

Calculate Linux — семейство дистрибутивов, предназначенных для малого и среднего бизнеса, в которых применяются перемещаемые профили и централизованное развёртывание программного обеспечения. Созданы на основе проекта Gentoo Linux и полностью с ним совместимы, отличительной особенностью является относительно последнего простая установка. © Wikipedia

В этой статье я хотел бы рассмотреть свой вариант правильной установки Calculate Directory Server 15.0.

Установка то действительно не сложная, однако стоит обратить внимание на то, что команду установки тоже необходимо прописать правильно, иначе можно не достичь нужного результата.

После загрузки с диска или образа появляется экран приветствия, в котором система предлагает первым делом настроить сеть. Так и сделаем. Настройки сети для данной машины:

IP-адрес: 192.168.1.48

Маска сети: 255.255.255.0

Шлюз: 192.168.1.101

DNS-сервер: 8.8.8.8

cl-setup-network —iface 192.168.1.48:24 —route default:192.168.1.101 —dns 8.8.8.8

После этого нам необходимо разметить диск.

Появится окно утилиты cfdisk с предложением выбрать тип разметки диска

Выбираем dos

После этого появится окно, где будет отображена необходимая информация о диске.

Создадим раздел размером 128 МБ

выбираем primary

и сделаем его загрузочным

Теперь создадим раздел размером 2 ГБ

выбираем primary

переходим на пункт Тип

и выбираем Linux своп / Solaris

И создадим раздел с оставшимся свободным местом 13,9 ГБ

выбираем primary

выбираем пункт Запись

отвечаем yes

и выходим из cfdisk

На этом этапе создана первоначальная конфигурация для установки CDS. Разделы форматировать не надо, установщик сделает это сам. Для этого мы опишем это в команде инсталляции.

Теперь установим саму систему, прописав в команду необходимые параметры:

cl-install —lang ru_RU —timezone Europe/Moscow —disk /dev/sda3:/:ext4:on —disk /dev/sda1:/boot:ext2:on —disk /dev/sda2:swap

В команде указано, что установленная система должна быть руссифицирована, часы — по Московскому времени, корневой раздел диска /dev/sda3 отформатирован в ext4, загрузочный раздел /dev/sda1 — в ext2, раздел подкачки /dev/sda2 — в swap.

Следующая картинка покажет то, что именно я хотел описать, то есть монтирование разделов и настройки сети. Также здесь изложены остальные необходимые параметры.

После инсталляции CDS система предлагает перезагрузить машину.

Извлекаем инсталляционный диск, отвечаем Yes, и перезагружаемся

После перезагрузки система готова к дальнейшей настройке.

Если Вам помогла статья, вы можете отблагодарить автора:
перечислить на WMR кошелёк (WebMoney): R301575071888
перечислить на Яндекс.Кошелёк: 410011003938168
или на PayPal:

Linux directory server

Выпущенная Samba 4 реализует почти полноценный аналог Active Directory (AD), включая контроллер домена, службу DNS, Kerberos-аутентификацию, групповые политики. Однако, с помощью Samba 4 пока нельзя создавать сложные доменные структуры и иерархии и устанавливать доверительные отношения, что ограничивает применимость в крупных организациях.

Таким образом, на текущий момент наиболее реальными применениями Samba 4 являются построение тестовых инфраструктур, а также внедрения в малом бизнесе.

Тем более, что во многих случаях реальный выбор не так велик. Microsoft предлагает специальные редакции Windows Server 2012 для малого бизнеса — Essentials и Foundation. Первая при цене в $500 представляет собой довольно интересное интегрированное решение для 25 пользователей, вторая предлагается для установки OEM и готова поддерживать 15 пользователей. Но проблема в том, что для большего числа потребуется не только докупать CAL, но и менять серверную лицензию на Standard. Samba 4 таких ограничений лишена и может масштабироваться до любого необходимого уровня. Вероятно, для ее распространения также лучше подошла бы OEM-модель, гарантирующая полную совместимость с оборудованием и отсутствие неожиданностей хотя бы на первых порах.

Читать еще:  Декодер h 264 linux

Между тем само внедрение Samba 4 — дело достаточно нехитрое. Естественно, начать лучше с тестирования какого-нибудь специализированного дистрибутива. Таковой, к примеру, предлагает SerNet, немецкий интегратор и участник проекта Samba — SerNet Samba 4 Appliance. Дополнительно на нем можно развернуть ПО коллективной работы Zafara, в состав входит готовый скрипт для корректировки схемы AD. Novell/SUSE предлагает свой вариант Excellent Samba4 Appliance, причем в виде как загрузочных образов, так и уже развернутых виртуальных дисков для всех популярных систем виртуализации. Данный дистрибутив периодически обновляется, вслед за выходом очередных исправлений к Samba 4.

Собственно, инициализация AD заключается в развертывании дистрибутива или создании и запуске соответствующей виртуальной машины и выполнения готового скрипта dcpromo, который запрашивает немногочисленные параметры (название домена, IP-адрес и пр.).

Поскольку Samba 4 создавалась на основе официально приобретенной документации Microsoft, ее совместимость обещает быть довольно высокой. Во всяком случае, можно использовать все стандартные административные инструменты Microsoft, которые в случае Excellent Samba4 Appliance даже доступны через внутренний веб-сервер.

Поскольку Samba 4 реализует все необходимые для AD процедуры RPC, также можно пользоваться утилитами командной строки и PowerShell-скриптами. Linux-сообщество разрабатывает и собственные инструменты, как графические, так и скриптовые, но степень их готовности пока неудовлетворительна.

В случае использования инструментов Microsoft дальнейшее администрирование домена происходит совершенно привычно для любого, хотя бы поверхностно знакомого с AD в Windows Server. Добавление учетных записей, создание групп, разграничение полномочий выполняется совершенно прозрачно.

Таким образом, Samba 4 позволяет организовать простой домен AD на Linux фактически без необходимости глубоких знаний собственно Linuх. К тому же, гибкость открытой ОС дает возможность создавать компактные монофункциональные дистрибутивы с Samba 4, которые будут надежно работать как в физической, так и виртуальной среде. Под вопросом пока остается стабильность и масштабируемость самой Samba 4, но команда разработчиков, похоже, на достигнутом останавливаться не собирается.

Теперь подробно остановимся на установке и настройке Excellent Samba4 Appliance.

Создание Домен контроллера, Active Directory и Файлового сервера с помощью Excellent Samba 4 Appliance.

1. Для начала скачиваем Excellent Samba 4 Appliance, предварительно зарегистрировавшись на сайте https://susestudio.com/.

2. Далее, скачиваем дистрибутив. Я поднимаю на виртуальной машине Hyper-V, поэтому скачиваю ISO-образ диска.

3. Итак, имеет файл Excellent_Samba4_Appliance.x86_64-1.1.11.iso, загружаемся с него и видим:

Жмём Excellent Samba4 Appliance.

Принимаем условия лицензии, нажав y. Дальше видим картину:

Логин / пароль в данном случае: root / opensuse

4. После авторизации, необходимо настроить параметры сети, выполнив команду: yast lan

Нажмите F4 для конфигурирования IP адреса.

Назначаю статический адрес 192.168.0.253, маска 255.255.255.0, имя pbdc.pbd.net

Нажимаю Next и перехожу во-вкладку Hostname/DNS.

Назначаю Hostname — pbdc, Domain — pbd.net. DNS сервера: 192.168.0.253, 91.222.240.250 и 91.222.241.250. Domain search — pbd.net.

Перехожу во вкладку Roating, где прописываю IP адрес интернет-шлюза. В моём случае — 192.168.0.254.

Жму OK. Началось применение параметров. Теперь из любого компьютера в сети адрес 192.168.0.253 должен пинговаться. Если так, всё сделано правильно.

5. Теперь установим систему на жесткий диск машины. Набираем в консоли yast и жмём Enter.

Заходим в пункт Miscellaneous, затем Live Installer, жмём Enter.

Выбираем английский язык и английскую раскладку клавиатуры (русский вряд-ли будет отображаться правильно), принимаем условия лицензии и жмём Next.

Выбираем часовой пояс и устанавливаем время, жмём Next.

Далее назначаем правило разметки диска. Я оставил всё без изменений и нажал Next.

Придумываем пользователя и пароль. Придумываем пароль root’у.

Проверяем введенные данные и жмём Install.

По завершению установки, выходим из Yast и перезагружаемся, написав reboot, вытаскиваем загрузочный диск.

6. Входим в root и приступаем к настройке Samba 4. Для облегчения этого процесса нам уже написали неплохой скрипт, который находится в

Аутентификация и авторизация в домене Active Directory при подключении к серверу Ubuntu Server 14.04 LTS

В одной из прошлых заметок мы рассмотрели процедуру присоединения сервера на базе Ubuntu Server 14.04 LTS к домену Active Directory (AD) для обеспечения работы процедур аутентификации и авторизации на прокси-сервере Squid 3.3. Тем самым мы упростили доступ рядовых доменных пользователей к ресурсам Интернет. Однако не стоит забывать и об администраторах. Использование локальных учетных записей для аутентификации и авторизации администраторов на Linux-серверах может доставлять свои неудобства, когда количество таких серверов в организации увеличивается. В этой заметке мы рассмотрим процедуры настройки сервера Ubuntu направленные на упрощение процедур аутентификации и авторизации при входе в Linux-систему путём использования учетных записей пользователей и групп безопасности домена AD.

Как и в предыдущих заметках посвященных теме интеграции Linux в AD, в качестве хранилища доменных учетных записей пользователей и групп в нашем примере будут использоваться контроллеры домена под управлением ОС Microsoft Windows Server 2012 R2.

Прежде чем приступим, хочу сделать одно важное замечание. В этой заметке мы будем выполнять корректировку некоторых системных конфигурационных файлов, отвечающих за работу аутентификации и авторизации для локального и удалённого входа в Linux-систему. Поэтому, перед тем как начать подобные корректировки, настоятельно рекомендую сделать резервную копию системы, например снапшот виртуальной машины, ибо в случае некорректных настроек PAM мы сможем получить проблемы со входом в систему (например после перезагрузки сервера).

Устанавливаем плагин для Samba4 (nss_winbind) и поддержку Winbind для PAM:

Проверяем работу Kerberos пытаясь получить билет для какого-нибудь доменного пользователя.

Проверяем наличие билета Kerberos

Очищаем кэш билетов:

Конфигурация Samba4 по умолчанию для новых пользователей подразумевает создание домашнего каталога пользователя по шаблону ( template homedir ) /home/<Домен>/ <Логин>с отсутствием оболочки ( template shell ). Немного изменим конфигурацию /etc/samba/smb.conf задав параметр описывающий оболочку

Новое содержимое smb.conf :

Обратите внимание на то, что по сравнению с конфигурационным файлом приведённым для примера ранее , добавился также ряд других параметров, нацеленных не конкретно под нашу задачу, а для оптимизации работы процессов Samba.

После изменения диапазона idmap в smb.conf не плохо бы сбросить кэш Winbind:

Для вступления новой конфигурации smb.conf перезапускаем службы Samba:

Добавляем возможность использования Winbind в системный конфигурационный файл nsswitch.conf

Дописываем winbind в строки passwd и group . Результирующий файл будет выглядеть так:

Убеждаемся в том, что ниже указанные команды возвращают список как локальных пользователей и групп так и доменных:

Обратите внимание на то, что при большом количестве пользователей и групп в домене вывод getent может работать некорректно в том случае, если в конфигурации smb.conf диапазон idmap недостаточно велик. Хотя на самом деле у нас нет необходимости получать полный список всех групп и пользователей домена, а достаточно выполнить проверку для какой-то одной конкретной группы, например для доменной группы безопасности, которую мы специально создали для объединения администраторов серверов Linux…

…и для доменной учетной записи любого пользователя, которую мы планируем использовать для входа на наш Ubuntu Server…

Создадим в каталоге домашних папок пользователей подкаталог для доменных пользователей в соответствии с настройками нашего smb.conf (в качестве имени каталога используем NetBIOS-имя домена):

Читать еще:  Установка apache linux

Проверим, что после установки библиотеки libpam-winbind соответствующие PAM-модули для Winbind активирован.

Правим файл /etc/pam.d/common-session . В конец файла добавим строку определяющую директиву создания домашнего каталога в случае его отсутствия:

Результирующий файл (без вывода комментариев) получится следующий:

Правим файл /etc/pam.d/common-auth . В строку описывающую вызов pam_winbind.so добавляем дополнительный параметр require_membership_of , в котором указываем имя доменной группы безопасности. В эту группу будут входить пользователи, которым мы хотим разрешить вход на наш Linux-сервер. Имя группы желательно указывать с учётом регистра, то есть так, как она создана в домене AD. Указанная группа должна быть группой глобального типа (область действия в домене AD).

Результирующий файл (без вывода комментариев) получится следующий:

Обратите внимание также на то, что в указанные файлы не стоит вносить никаких других изменений кроме указанных, даже таких простых, как например, изменение отступов в существующих параметрах. В противном случае мы потеряем возможность управлять включением/выключением PAM-модулей через конфигуратор pam-auth-update. Проверить то, как после ручной правки pam-auth-update воспринимает common-файлы, можно просто запустив его и если что-то ему не понравится, он сообщит нам об этом:

Если же всё таки где-то напортачили, то можно заставить pam-auth-update исправить параметры common-файлов в их исходные значения выбрав в указанном сообщении Yes, либо отдельной командой:

Остальные common-файлы привожу информативно. В них мы редактировать вручную ничего не будем, так как конфигуратор pam-auth-update уже внёс все необходимые правки со ссылкой на winbind.

Результирующий файл /etc/pam.d/common-account (без вывода комментариев):

Результирующий файл /etc/pam.d/common-password (без вывода комментариев):

Результирующий файл /etc/pam.d/common-session-noninteractive (без вывода комментариев):

После указанных настроек проверяем вход в систему используя учетные данные пользователя домена AD. В качестве логина указываем доменный логин пользователя (без доменной части). При этом проверяем, то что в систему удаётся войти только тем пользователям, которые включены в доменную группу безопасности KOM-SRV-Linux-Administrators . В случае возникновения проблем при входе следим за системным логом аутентификации:

Замечено, что в случае, если в домене AD в свойствах групп безопасности, членом которых является аутентифицируемый пользователь, присутствует непустой атрибут sIDHistory (группа ранее была мигрирована в текущий домен из другого домена), то в процессе входа в Linux может появляться ряд сообщений типа:

Это связано с тем, что после аутентификации и авторизации для пользователя запускается shell-оболочка, которая была назначена пользователю согласно параметра template shell конфигурационного файла smb.conf . То есть в нашем случае выполняется оболочка /bin/bash . В текущей своей версии оболочка bash при запуске выполняет скрипт /etc/bash.bashrc . Если мы откроем этот скрипт, то увидим, что в нём присутствует такой фрагмент кода:

Этот участок скрипта используется для банального вывода подсказки о том, что для выполнения административных действий требуется использовать sudo. При этом здесь выполняется проверка членства залогинившегося пользователя в группах вызовом утилиты groups, которая в свою очередь при вызове в контексте доменного пользователя будет пытаться вернуть список доменных групп в которые он входит. При этой операции используется Winbind, у которого есть проблемы с чтением из домена AD групп имеющих непустой атрибут sIDHistory.

Чтобы избавиться от вывода подобного рода сообщений при входе в систему есть два простых решения. Либо закомментировать представленный выше участок кода в файле /etc/bash.bashrc , либо для доменных пользователей использовать альтернативную shell-оболочку, например zsh (при этом надо поменять параметр template shell конфигурационного файла smb.conf на /bin/zsh и перезапустить службы Samba). Я предпочёл первый способ.

Итак, мы уже имеем возможность локального и удалённого (по SSH) входа на наш Linux-сервер используя учётную запись пользователя домена AD с ограничением по членству в доменной группе безопасности. Однако для выполнения таким пользователем административных действий в Linux-системе, нам потребуется включить для этого пользователя возможность выполнения sudo. Проще всего будет выдать данное разрешение не для конкретного пользователя, а сразу для указанной доменной группы. Для этого нам потребуется внести изменения в системный конфигурационный файл /etc/sudoers . Прямая правка этого файла не рекомендуется, поэтому воспользуемся специальным инструментом visudo, который при сохранении файла sudoers выполняет его проверку:

Приведу фрагмент файла, в котором описываются группы доступа имеющие возможность выполнять sudo (здесь была добавлена последняя строчка фрагмента):

После сохранения файла снова входим в систему доменным пользователем и пробуем выполнить любую команду с sudo.

На этом всё. В следующей заметке мы рассмотрим процедуру настройки Single sign-on (SSO) при подключении к Linux-серверу на базе Ubuntu Server 14.04 LTS по протоколу SSH с клиентских компьютеров под управлением Windows

Как получить список пользователей LDAP

Ребят не подскажите как из Linux можно получить список пользователей Active Directory в определённой группе?

Установил программу ldap-utils, в ней есть утилита ldapsearch. Пробовал с ней получить список пользователей, там такая ахинея получается.

Может кто сталкивался с таким?

CentOS 7 доменная и локальная учетные записи

Ситуация следующая. Тачка с CentOS введена в домен, есть одна учетка локальная и доменная с одинаковым именем. Как мне в sudoers прописать разрешения на локальную учетку, а не доменную?, ибо в первую очередь сервер обращается ко второй.

Ansible + Windows Active Directory

Надо одну штуку сделать для винды.
Есть актив директори, где админ домена domain.com —> MainAdministrator и есть компик ComputerAdministrator, собственно надо, чтобы при подключении на этот компик (ComputerAdministrator) логинился под MainAdministrator.
Мне это как-то через kerberos делать или есть путь полегче? С ним не работал. В конфиге хоста у ansible у меня просто айпи, логин с паролем, который по winrm подключается

Определить AD Logon Server

Всем привет, простой вопрос — есть несколько серверов AD (Win Server), в сети «зоопарк клиентов» (WinLinuxMac)

Что бы узнать на каком сервере залогинился клиент Windows — достаточно ввести команду в cmd:

Есть ли аналогичная команда в Ubuntu?

Примечание: Linux-клиентов вводил в домен через sssd

Не работает squid на втором DC

Коллеги, добрый день! Бьюсь долгое время с данной проблемой. Имеем Squid 3.5.8, Active Directory (два DC). Настроена интеграция через керберос с AD. Все работает, всё здорово. Но когда отключаешь DC1 — сквид начинает блокировать весь траффик. Если включить тутже DC1, то все работает как надо. (группы, блокировки, ACL все работает) Пересоздавал krb5.keytab. При выключении DC1, squid получает билет от DC2, все отображается в klist. PTR записи имеются, всё резолвится. Ниже конфиги, логи.

В момент блокировки в access.log в основном код 407. А в cache.log следующее: kerberos_ldap_group: ERROR: ldap_sasl_interactive_bind_s error: Can’t contact LDAP server kerberos_ldap_group: ERROR: Error while binding to ldap server with SASL/GSSAPI: Can’t contact LDAP server

auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -s HTTP/prx.domen.local@DOMEN.LOCAL auth_param negotiate children 60 auth_param negotiate keep_alive off

external_acl_type inet_medium ttl=300 negative_ttl=60 %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl -g Internet-medium@DOMEN.LOCAL external_acl_type inet_full ttl=300 negative_ttl=60 %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl -g Internet-full@DOMEN.LOCAL external_acl_type inet_low ttl=300 negative_ttl=60 %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl -g Internet-low@DOMEN.LOCAL

acl localnet src 192.168.10.0/24

acl my_full external inet_full acl my_medium external inet_medium acl my_low external inet_low acl auth proxy_auth REQUIRED

Ссылка на основную публикацию
Adblock
detector