Как удалить ldap ubuntu
Обновлено: 04.07.2024
Для того чтобы OpenLDAP использовался как дополнение к Samba, теоретически в дереве (DIT) должны присутствовать атрибуты которые корректно описывают данные Samba. Такие атрибуты могут быть получены путем введения схемы Samba в LDAP . Сейчас мы это сделаем.
Для более детальной информации о схемах и их установке смотри Изменение базы данных настройки slapd.1. Такая схема находится в свежеустановленном вами пакете samba-doc. Ее требуется скопировать и разархивировать в директорию /etc/ldap/schema следующим образом:
2. Получаем файл конфигурации schema_convert.conf, который должен содержать следующие строки:
3. Оставляем каталог ldif_output для вывода.
4. Определяем индекс для схемы:
5. Конвертируем схему в формат LDIF:
6. Редактируем созданный файл cn=samba.ldif, удаляя индексную информацию, по достижению:
удалите строки в конце:
Внимание: Ваши данные могут отличаться!
7. Добавляем новую схему:
Для запроса и просмотра новой схемы введите:
Индексы Samba
Теперь, когда slapd знает о атрибутах Samba, мы можем создать несколько индексов на их основе. Индексация записей является способом повышения производительности, когда клиент осуществляет выборочный поиск в дереве (DIT).
Создайте файл samba_indices.ldif следующего содержания:
Используйте утилиту ldapmodify для загрузки новых индексов:
Если все настроено правильно, вы увидите новые индексы используя утилиту ldapsearch:
Добавление объектов Samba к LDAP
Далее настройте пакет smbldap-tools для соответствия среды работы. Пакет поставляется со скриптом конфигурации, в котором указаны вопросы о необходимых опциях установки. Для запуска скрипта введите в терминале:
Если у вас есть резервная копия, продолжайте наполнять директорию:
Конфигурация Samba
Есть несколько способов настройки Samba. Более подробную информацию смотри в разделе «Windows Networking». Чтобы настроить Samba для использования LDAP необходимо отредактировать конфигурационный файл /etc/samba/smb.conf указав комментарий в значении passdb и добавив некоторые значения для работы LDAP :
Измените значения для вашей конфигурации.
Перегрузите сервер Samba для применения изменений.
Теперь укажите Samba пароль DN пользователя root (который указывается при установке пакета slapd):
Вам будет предложено ввести пароль. Это рассматривается как выдача нового пароля пользователю, что делает его таким как прежде и является разумным решением.
Для настройки пользователей, групп и учётных записей на компьютерах используйте стандартные утилиты предоставляемые пакетом smbldap-tools. Вот несколько примеров:
1. Добавление нового пользователя:
2. Удаление пользователя:
3. Добавление группы:
4. Сделать существующего пользователя членом группы:
Опция -m может добавлять более одного пользователя за раз, если использовать список, разделенный запятыми.
5. Удаление пользователя из группы:
6. Добавить в Samba учетную запись компьютера:
Замените username на имя рабочей станции. Опция -t 0 создает учетную запись без задержки, в то время как опция -w определяет пользователя как учетную запись компьютера. Также обратите внимание, что параметр add machine script в /etc/samba/smb.conf изменен чтобы использовался smbldap-useradd.
Существуют утилиты в пакете smbldap-tools, которые тут не рассматривались. Здесь полный список:
Ссылки
Для дополнительной информации по установке и настройке Samba смотрите раздел Настройка сети Windows.
Относительно предыдущей ссылки, смотрите отдельно секцию passdb
Также устаревшее (2007) Linux Samba-OpenLDAP HOWTO, содержит важные заметки.
Основная страница документации сообщества Ubuntu по Samba содержит множество ссылок на статьи, которые могут оказаться полезными.
SSSD stands for System Security Services Daemon and it’s actually a collection of daemons that handle authentication, authorization, and user and group information from a variety of network sources. At its core it has support for:
- Active Directory
- LDAP
- Kerberos
SSSD provides PAM and NSS modules to integrate these remote sources into your system and allow remote users to login and be recognized as valid users, including group membership. To allow for disconnected operation, SSSD also can also cache this information, so that users can continue to login in the event of a network failure, or other problem of the same sort.
This guide will focus on the most common scenarios where SSSD is deployed.
SSSD and Active Directory
This section describes the use of sssd to authenticate user logins against an Active Directory via using sssd’s “ad” provider. At the end, Active Directory users will be able to login on the host using their AD credentials. Group membership will also be maintained.
Prerequisites, Assumptions, and Requirements
This guide does not explain Active Directory, how it works, how to set one up, or how to maintain it.
This guide assumes that a working Active Directory domain is already configured and you have access to the credentials to join a machine to that domain.
The domain controller is acting as an authoritative DNS server for the domain.
The domain controller is the primary DNS resolver (check with systemd-resolve --status )
System time is correct and in sync, maintained via a service like chrony or ntp
Software Installation
Install the following packages:
Join the domain
We will use the realm command, from the realmd package, to join the domain and create the sssd configuration.
Let’s verify the domain is discoverable via DNS:
This performs several checks and determines the best software stack to use with sssd. sssd can install the missing packages via packagekit, but we installed them already previously.
Now let’s join the domain:
That was quite uneventful. If you want to see what it was doing, pass the -v option:
By default, realm will use the Administrator account of the domain to request the join. If you need to use another account, pass it to the tool with the -U option.
Another popular way of joining a domain is using an OTP, or One Time Password, token. For that, use the --one-time-password option.
SSSD Configuration
The realm tool already took care of creating an sssd configuration, adding the pam and nss modules, and starting the necessary services.
Let’s take a look at /etc/sssd/sssd.conf :
Note
Something very important to remember is that this file must have permissions 0600 and ownership root:root, or else sssd won’t start!
Let’s highlight a few things from this config:
Automatic home directory creation
What the realm tool didn’t do for us is setup pam_mkhomedir , so that network users can get a home directory when they login. This remaining step can be done by running the following command:
Checks
You should now be able to fetch information about AD users. In this example, John Smith is an AD user:
Let’s see his groups:
Note
If you just changed the group membership of a user, it may be a while before sssd notices due to caching.
Finally, how about we try a login:
Notice how the home directory was automatically created.
You can also use ssh, but note that the command will look a bit funny because of the multiple @ signs:
Note
In the ssh example, public key authentication was used, so no password was required. Remember that ssh password authentication is by default disabled in /etc/ssh/sshd_config .
Kerberos Tickets
If you install krb5-user , your AD users will also get a kerberos ticket upon logging in:
Note
realm also configured /etc/krb5.conf for you, so there should be no further configuration prompts when installing krb5-user
Let’s test with smbclient using kerberos authentication to list he shares of the domain controller:
Notice how we now have a ticket for the cifs service, which was used for the share list above:
Desktop Ubuntu Authentication
The desktop login only shows local users in the list to pick from, and that’s on purpose.
To login with an Active Directory user for the first time, follow these steps:
- type in the login name followed by the password:
- the next time you login, the AD user will be listed as if it was a local user:
Resources
SSSD and LDAP
SSSD can also use LDAP for authentication, authorization, and user/group information. In this section we will configure a host to authenticate users from an OpenLDAP directory.
Prerequisites, Assumptions, and Requirements
For this setup, we need:
- an existing OpenLDAP server with SSL enabled and using the RFC2307 schema for users and groups
- a client host where we will install the necessary tools and login as an user from the LDAP server
Software Installation
Install the following packages:
SSSD Configuration
Create the /etc/sssd/sssd.conf configuration file, with permissions 0600 and ownership root:root, and this content:
Make sure to start the sssd service:
Note
sssd will use START_TLS by default for authentication requests against the LDAP server (the auth_provider), but not for the id_provider. If you want to also enable START_TLS for the id_provider, specify ldap_id_use_start_tls = true .
Automatic home directory creation
To enable automatic home directory creation, run the following command:
Check SSL setup on the client
The client must be able to use START_TLS when connecting to the LDAP server, with full certificate checking. This means:
If using a custom CA, an easy way to have a host trust it is to place it in /usr/local/share/ca-certificates/ with a .crt extension and run sudo update-ca-certificates .
Alternatively, you can edit /etc/ldap/ldap.conf and point TLS_CACERT to the CA public key file.
Note
You may have to restart sssd after these changes: sudo systemctl restart sssd
Once that is all done, check that you can connect to the LDAP server using verified SSL connections:
The -ZZ parameter tells the tool to use START_TLS, and that it must not fail. If you have LDAP logging enabled on the server, it will show something like this:
START_TLS with err=0 and TLS established is what we want to see there, and, of course, the WHOAMI extended operation.
Final verification
In this example, the LDAP server has the following user and group entry we are going to use for testing:
The user john should be known to the system:
And we should be able to authenticate as john:
SSSD, LDAP and Kerberos
Finally, we can mix it all together in a setup that is very similar to Active Directory in terms of the technologies used: use LDAP for users and groups, and Kerberos for authentication.
Prerequisites, Assumptions, and Requirements
For this setup, we will need:
- an existing OpenLDAP server using the RFC2307 schema for users and groups. SSL support is recommended, but not strictly necessary because authentication in this setup is being done via Kerberos, and not LDAP.
- a Kerberos server. It doesn’t have to be using the OpenLDAP backend
- a client host where we will install and configure SSSD
Software Installation
On the client host, install the following packages:
At this point, you should alreaedy be able to obtain tickets from your Kerberos server, assuming DNS records point at it like explained elsewhere in this guide:
But we want to be able to login as an LDAP user, authenticated via Kerberos. Let’s continue with the configuration.
SSSD Configuration
Create the /etc/sssd/sssd.conf configuration file, with permissions 0600 and ownership root:root, and this content:
This example uses two KDCs, which made it necessary to also specify the krb5_kpasswd server because the second KDC is a replica and is not running the admin server.
Start the sssd service:
Automatic home directory creation
To enable automatic home directory creation, run the following command:
Final verification
In this example, the LDAP server has the following user and group entry we are going to use for testing:
Note how the john user has no userPassword attribute.
The user john should be known to the system:
Let’s try a login as this user:
We logged in using the kerberos password, and user/group information from the LDAP server.
SSSD and KDC spoofing
When using SSSD to manage kerberos logins on a Linux host, there is an attack scenario you should be aware of: KDC spoofing.
The objective of the attacker is to login on a workstation that is using Kerberos authentication. Let’s say he knows john is a valid user on that machine.
The attacker first deploys a rogue KDC server in the network, and creates the john principal there with a password of his choosing. What he has to do now is to have his rogue KDC respond to the login request from the workstation, before (or instead of) the real KDC. If the workstation isn’t authenticating the KDC, it will accept the reply from the rogue server and let john in.
There is a configuration parameter that can be set to protect the workstation from this attack. It will have SSSD authenticate the KDC, and block the login if the KDC cannot be verified. This option is called krb5_validate , and it’s false by default.
To enable it, edit /etc/sssd/sssd.conf and add this line to the domain section:
The second step is to create a host principal on the KDC for this workstation. This is how the KDC’s authenticity is verified. It’s like a “machine account”, with a shared secret that the attacker cannot control and replicate in his rogue KDC…The host principal has the format host/<fqdn>@REALM .
After the host principal is created, its keytab needs to be stored on the workstation. This two step process can be easily done on the workstation itself via kadmin (not kadmin.local ) to contact the KDC remotely:
Then exit the tool and make sure the permissions on the keytab file are tight:
You can also do it on the KDC itself using kadmin.local , but you will have to store the keytab temporarily in another file and securely copy it over to the workstation.
Once these steps are complete, you can restart sssd on the workstation and perform the login. If the rogue KDC picks the attempt up and replies, it will fail the host verification. With debugging we can see that happening on the workstation:
And the login is denied. If the real KDC picks it up, however, the host verification succeeds:
And the login is accepted.
Debugging and troubleshooting
Here are some tips to help troubleshoot sssd.
debug_level
The debug level of sssd can be changed on-the-fly via sssctl , from the sssd-tools package:
Or change add it to the config file and restart sssd:
Either will yield more logs in /var/log/sssd/*.log and can help identify what is going on. The sssctl approach has the clear advantage of not having to restart the service.
Caching
Caching is useful to speed things up, but it can get in the way big time when troubleshooting. It’s useful to be able to remove the cache while chasing down a problem. This can also be done with the sssctl tool from the sssd-tools package.
Атрибут имеет тип (имя/описание) и одно или несколько значений.
Каждый атрибут должен быть определен как минимум в одном objectClass.
Атрибуты и объектные классы определяются в схемах (объектный класс фактически рассматривается как специальный вид атрибута).
Каждая запись имеет уникальный идентификатор: свое Отличительное имя (DN или dn). Она состоит из своего Относительного отличительного имени (RDN), следующим за записью родительского DN.
DN записи - это не атрибут. Оно не является рассматриваемой частью собственно записи.
Термины объект, контейнер и узел (node) имеют определенный подтекст, но они все по существу обозначают такую вещь, как запись, технически корректный термин.Например, далее мы имеем одну запись, содержащую 11 атрибутов. Ее DN - это "cn=John Doe,dc=example,dc=com"; ее RND - это "cn=John Doe"; а родительский DN - "dc=example,dc=com".
Установка
Установка сервиса сервера OpenLDAP и привычных утилит управления LDAP . Они находятся в пакетах slapd и ldap-utils соответственно.
Установка slapd создаст работающую конфигурацию. В частности она создаст экземпляр базы данных, которую вы можете использовать для хранения своих данных. Однако суффикс (или базовый DN) этого экземпляра будет определен из доменного имени localhost. Если вы хотите использовать что-то другое, отредактируйте /etc/hosts и замените доменное имя на подходящее. В качестве примера, если вам нужен суффикс dc=example,dc=com, то ваш файл должен иметь подобную строку:
Вы можете отменить изменения после установки пакета.
Это руководство будет использовать суффикс базы данных dc=example,dc=com.Продолжим с установкой:
Начиная с Ubuntu 8.10 slapd проектируется, чтобы настраиваться самостоятельно, выделяя отдельный DIT для этой цели. Это позволяет динамически настраивать slapd без необходимости перестартовывать сервис. Эта конфигурационная база данных содержит коллекцию текстовых LDIF файлов, расположенных в /etc/ldap/slapd.d. Этот вариант работы известен под разными именами: метод slapd-config, RTC метод (настройка в реальном времени) или cn=config метод. Вы все еще можете использовать традиционный метод плоского файла (slapd.conf), но это не рекомендуется; данная функциональность в конечном счете будет убрана.
Ubuntu теперь использует метод slapd-config для настройки slapd и данное руководство это отражает.Некоторые классические схемы (cosine, nis, inetorgperson) выпускаются теперь для slapd. Это также включает базовую (core) схему, которая предполагается для любой рабочей схемы.
Проверка после установки
Процесс установки создаст 2 DIT. Один для slapd-config и один для ваших данных (dc=example,dc=com). Давайте взглянем:
Здесь показано как выглядит дерево (DIT) базы данных slapd-config. Напомним, что эта база основана на LDIF и находится в /etc/ldap/slapd.d:
Не редактируйте базу slapd-config напрямую. Вносите изменения через протокол LDAP (утилитами).Здесь показано как выглядит дерево slapd-config через LDAP протокол:
Объяснение по записям:
cn=config: глобальные настройки
cn=module,cn=config: динамически загружаемый модуль
cn=schema,cn=config: содержит жестко запрограммированную схему системного уровня
cn=core,cn=schema,cn=config: жестко запрограммированная схема ядра (core)
cn=cosine,cn=schema,cn=config: схема cosine
cn=nis,cn=schema,cn=config: схема nis
cn=inetorgperson,cn=schema,cn=config: схема inetorgperson
olcDatabase=frontend,cn=config: база переднего плана, настройка по умолчанию для других баз данных
olcDatabase=config,cn=config: конфигурационная база slapd (cn=config)
olcDatabase=hdb,cn=config: экземпляр вашей базы данных (dc=examle,dc=com)
А здесь показано как выглядит дерево dc=example,dc=com:
Объяснение по записям:
dc=example,dc=com: базовый уровень вашего дерева (DIT)
cn=admin,dc=example,dc=com: администратор (rootDN) данного дерева (заполняется в процессе установки пакета)
Изменение/заполнение вашей базы данных
Давайте введем некоторые данные в нашу базу. Мы добавим следующее:
ноду с названием People (сохранять пользователей)
ноду с названием Groups (сохранять группы)
группу с названием miners
пользователя с именем john
Создайте следующий LDIF файл и назовите его add_content.ldif:
Важно, чтобы значения uid и gid в вашем каталоге не совпадали с локальными значениями. Используйте диапазон больших чисел, начинающийся, например, с 5000. Устанавливая значения uid и gid высокими для ldap, вы сможете проще контролировать что могут делать локальные пользователи, а что ldap. Подробнее далее.Мы можем проверить, что информация добавлена правильно с помощью утилиты ldapsearch:
Объяснения по параметрам:
-x: "простое" связывание; не будет использоваться метод SASL по умолчанию
-LLL: отключить вывод посторонней информации
uid=john: "фильтр" для нахождения пользователя john
cn gidNumber: запрос на вывод определенных атрибутов (по умолчанию выводятся все атрибуты)
Изменение базы данных настройки slapd
Дерево (DIT) slapd-config также может запрашиваться и изменяться. Здесь приведено несколько примеров.
Используйте ldapmodify для добавления индекса (атрибут DbIndex) для вашей hdb,cn=config базы (dc=example,dc=com). Создайте файл с названием uid_index.ldif следующего содержания:
Затем выполните команду:
Вы можете подтвердить изменения следующим способом:
Давайте добавим схему. Это будет первый раз, когда потребуется конвертация в LDIF формат. Вы можете найти несконвертированные схемы в добавление к сконвертированным в каталоге /etc/ldap/schema.
Удаление схемы из базы slapd-config - нетривиальная задача. Потренируйтесь добавлять схемы на тестовой системе.
Перед добавлением любой схемы, вам следует проверить какие схемы уже установлены (показан вывод по умолчанию, для состояния "из коробки"):
В следующем примере мы добавим схему CORBA.
Создайте конфигурационный файл преобразования schema_convert.conf, содержащий следующие строки:
Создайте каталог назначения ldif_output.
Определите индекс схемы:
Когда slapd вводит объекты с тем же родительским DN, он создает индекс для этого объекта. Индекс обрамляется скобками: .Используйте slapcat для выполнения преобразования:
Сконвертированная (преобразованная) схема теперь в cn=corba.ldif
Редактируйте cn=corba.ldif, по достижении следующих атрибутов:
Также удалите следующие строки в конце:
Значения ваших атрибутов могут быть другими.
Наконец, используйте ldapadd для добавления новой схемы к дереву slapd-config:
Проверьте текущую загруженную схему:
Ведение журналов
Создайте файл logging.ldif со следующим содержимым:
Вы можете решить изменить настройки rsyslog. В файл /etc/rsyslog.conf поместите следующее:
А затем перезапустите сервис rsyslog:
Репликация
Репликация доступна через механизм Syncrepl. Он позволят синхронизировать изменения используя модель Потребитель-Поставщик. Специфический вид репликации, который мы будем реализовывать в этом руководстве, является комбинацией следующих режимов: refreshAndPersist и delta-syncrepl. Это подразумевает что Потребитель передает измененные записи Поставщику, как только они появляются, но при этом посылаются только актуальные изменения, а не все записи.
Настройка Поставщика
Начнем с настройки Поставщика.
Создадим LDIF файл со следующим содержимым и назовем его provider_sync.ldif:
Замените rootDN в LDIF файле на соответствующий вашему каталогу.
Профиль apparmor для slapd нужно будет отрегулировать для расположения базы accesslog. Отредактируйте /etc/apparmor.d/local/usr.sbin.slapd, добавив следующее:
Создаем каталог, устанавливаем файл настроек базы данных и перегружаем профиль apparmor:
Добавляем новый контент и, поскольку изменили apparmor, перестартуем сервис:
Поставщик теперь настроен.
Настройка Потребителя
А теперь настроим Потребителя.
Установим программное обеспечение как указано в Установке. Убедитесь, что база slapd-config аналогична базе Поставщика. Особенно проверьте, что одинаковы схемы и суффикс базы.
Создайте LDIF файл со следующим содержимым и назовите его consumer_sync.ldif:
Убедитесь, что следующие атрибуты имеют корректные значения:
binddn (DN администратора, которым вы пользуетесь)
credentials (пароль для DN администратора, который вы используете)
searchbase (суффикс базы, которую вы используете)
olcUpdateRef (hostname сервера Поставщика или его IP адрес)
rid (Replica ID, уникальное трехзначное число, идентифицирующее данную копию. Каждый Потребитель должен иметь минимум один rid)
Добавьте новый контент:
Вы сделали это! Две базы (суффикс: dc=example,dc=com) будут теперь синхронизированы.
Проверка
Как только репликация стартует, вы можете отслеживать ее запустив:
Если contextCSN Потребителя отсутствует или не совпадает со значением Поставщика, вы должны остановиться и понять причину проблемы перед тем как продолжить. Попробуйте проверить slapd (syslog - системный журнал) и файлы журналов авторизации Поставщика, чтобы увидеть удачны ли были запросы авторизации Потребителя и не возвращались ли ошибки в ответ на запросы данных (они будут видны как множество записей ldapsearch).
Чтобы проверить, что все работает, просто запросите на Потребителе DN из базы:
Контроль доступа
Управление какой тип доступа (чтение, запись и пр.) пользователей должен быть предоставлен к ресурсам известен как контроль доступа. Сочетания подобных директив называются Списками контроля доступа (ACL ).
Это может быть представлено по-другому для лучшего понимания:
Атрибут userPassword не доступен для всех других пользователей за исключением rootDN, который имеет полный доступ.
Для того чтобы пользователи могли менять собственные пароли, используя passwd или иные утилиты, атрибут shadowLastChange должен быть доступен как только пользователь авторизовался.
Как указывалось ранее, никаких административных пользователей не создается для базы slapd-config. Однако существует идентификация SASL, которая обеспечивает полный к ней доступ. Она подобна суперпользователю для localhost (root/sudo). Вот она:
Следующая команда покажет ACL базы slapd-config:
Вы должны использовать sudo для идентификации как root чтобы ACL сработали.
Механизм EXTERNAL работает через IPC (доменные сокеты UNIX). Это означает , что вы должны использовать ldapi формат адресации (URI ).
Короткий путь для получения всех ACL выглядит следующим образом:
Есть еще много что сказать по контролю доступа. Смотрите страницу руководства по slapd.access.
Когда происходит аутентификация на OpenLDAP сервере, лучше всего это делать используя зашифрованную сессию. Это может быть достигнуто использованием транспортного уровня шифрования (TLS).
Устанавливаем пакеты gnutls-bin и ssl-cert:
Создаем секретный ключ Центра сертификатов:
Создаем временный файл /etc/ssl/ca.info для определения CA:
Создаем самоподписанный сертификат центра:
Создаем секретный ключ для сервера:
Замените ldap01 в имени файла на имя вашего сервера (hostname). Имена сертификата и ключа для узла и сервиса, которые будут их использовать, помогут сохранять ясность понимания.Создаем информационный файл /etc/ssl/ldap01.info, содержащий следующее:
Данный сертификат будет действителен 10 лет (3650 дней). Вы можете выбрать другое значение.
Создаем серверный сертификат:
Используйте команду ldapmodify, чтобы сказать slapd о работе нашего TLS через базу данных slapd-config:
Вопреки распространенному мнению, вам не обязательно указывать ldaps:// в /etc/default/slapd чтобы использовать шифрование. Вам достаточно указать:
Сужаем права на владение и доступ:
Проверьте ваши системные журналы (/var/log/syslog) чтобы убедиться что сервер запустился правильно.
Репликация и TLS
Если вы настроили репликацию между серверами, существует общая практика шифровать (StartTLS) трафик репликации для исключения прослушивания. Лучше всего использовать шифрование с аутентификацией как мы делали выше. В этой секции мы будем основываться на проделанной работе по TLS-аутентификации.
Здесь предполагается, что вы настроили репликацию между Поставщиком и Провайдером в соответствии с секцией Репликация и настроили TLS для аутентификации на Поставщике следуя инструкциям секции TLS.
На Поставщике:
Создаем промежуточный каталог (который будет использоваться для переноса) и затем секретный ключ Потребителя:
Создаем информационный файл ldap02.info для сервера Потребителя; подставляйте свои соответствующие значения:
Создаем сертификат Потребителя:
Получаем копию сертификата CA:
Все готово. Теперь переносим каталог ldap02-ssl на сервер Потребителя. Здесь мы использовали scp (данные изменяем соответственно):
На Потребителе:
Настраиваем TLS аутентификацию:
Создаем файл /etc/ssl/certinfo.ldif со следующим содержимым (исправляйте соответственно):
Настраиваем базу slapd-config:
Настраиваем /etc/default/slapd как на Поставщике (SLAPD_SERVICES).
На Потребителе:
Настраиваем TLS для репликации на стороне Потребителя. Изменяем существующий атрибут olcSyncrepl присоединяя некоторые TLS опции. Делая это, мы увидим в первый раз как изменять значения атрибутов.
Создаем файл consumer_sync_tls.ldif со следующим содержимым:
Применяем эти изменения:
И перестартуем slapd:
На Постащике:
Установление подлинности через LDAP
Результат диалога можно увидеть в /etc/ldap.conf. Если ваш сервер требует опции, недоступные в меню, редактируйте этот файл самостоятельно.
Настраиваем систему на использование LDAP для аутентификации:
Теперь вы имеете возможность входить в систему, используя учетные записи на основе LDAP .
Запросы имеют таймаут и будет попытка обратиться к Потребителю (ldap02), если Поставщик (ldap01) станет недоступным.
Альтернативой пакету libnss-ldap является пакет libnss-ldapd. Однако он добавит в систему пакет nscd, который, возможно, нежелателен. Просто впоследствии удалите его.Управление пользователями и группами
Пакет ldap-utils поставляется с достаточным количеством утилит для управления каталогами, но необходимость использовать длинные строки с опциями делает их применение обременительным. Пакет ldapscripts содержит оберточные сценарии (wrapper scripts) для этих утилит, которые некоторые находят более удобными в использовании.
Затем редактируем файл /etc/ldapscripts/ldapscripts.conf для получения нечто похожего на следующее:
Теперь создаем файл ldapscripts.passwd чтобы разрешить rootDN доступ к каталогу:
Замените "secret" на действующий пароль для пользователя rootDN вашей базы.Сценарии теперь готовы помогать в управлении вашим каталогом. Здесь несколько примеров как их использовать:
Создать нового пользователя:
Это создаст пользователя с uid george и установит gid example в качестве первичной пользовательской группы.
С выходом Ubuntu 10.04 решил я перевести свои сервера на неё. Перевод начал с контроллера домена. Предыдущий контроллер домена представлял из себя Ubuntu 8.04, Samba3 (PDC) + OpenLDAP (Master), администрирование осуществлялось при помощи smbldap-tools. Как оказалось не всё так просто как хотелось, некоторые настройки претерпели серьёзные изменения и в добавок мне захотелось какую нибудь GUI для моего PDC. В процессе поиска GUI я наткнулся на Gosa. Меня вполне устроили возможности Gosa поэтому я остановил свой выбор на ней. Дабы не забыть как это всё настраивается я записал весь процесс настройки, собственно этими записями и решил поделится, может кому понадобиться. Это моя первая статья, так что сильно не пинайте :).
И так, имеется свежеустановленная Ubuntu 10.04 в процессе установки был выбран LAMP сервер, в связи с этим я здесь не буду описывать настройку apache2 + php5.
Все действия в этой статье выполняются от пользователя root.
Первым делом скачиваем Gosa 2.6.13 с оф. сайта. В ней находится ряд схем которые понадобятся при настройке LDAP .
Распаковываем содержимое архива
Копируем в /usr/share/gosa
Создаём каталоги необходимые Gosa
Разрешим группе www-data запись в каталоги
1. Приступаем к настройке LDAP.
Устанавливаем необходимые пакеты
Подключаем базовые схемы
Теперь нужно подключить схемы необходимые для работы Gosa и samba.
Копируем схему samba в каталог /etc/ldap/schema
Схему samba3.schema необходимо перевести в формат ldif. Для этого переходим в каталог /etc/ldap
и создаём файл schema_convert.conf
Затем создадим временный каталог и конвертируем в него схему
Переходим в каталог с полученной схемой
Далее приступаем к редактированию полученной схемы. Открываем схему cn=samba3.ldif в вашем любимом редакторе (я пользуюсь редактором в mc) и приводим её к следующему виду
В конце схемы удаляем строки примерно следующего содержания
То есть удаляем всё начиная с structuralObjectClass: и до конца файла.
Ну и на последок копируем и переименовываем файл схемы
Далее необходимо подобным образом отредактировать все ldif файлы находящиеся в /usr/share/gosa/contrib/openldap/
К примеру возьмём файл trust.ldif.
При редактировании схем Gosa НЕ ЗАБЫВАЙТЕ в первой строке по мимо удаления скобок с номером дописывать ,cn=schema,cn=config иначе схемы Gosa не будут подключены что в дальнейшем приведёт к множеству ошибок.Теперь копируем их в каталог /etc/ldap/schema
Подключаем схемы в следующем порядке
Переходим в каталог /etc/ldap
Установите пароль администратора в соответствующей строке файла
olcRootPW: Xr4ilOzQ4PCOq3aQ0qbuaQ== в данном примере пароль будет secret
для получения шифрованного пароля была использована утилита slappasswd, использовать её надо следующим образом
Запомните имя и пароль администратора - GOsa потом спросит. Теперь загрузим эту конфигруацию:
Далее включаем шифрование для нашего LDAP .
Устанавливаем пакет gnutls-bin
Создаём ключ для Certificate Authority (CA)
Создаём файл /etc/ssl/ca.info
Example Company меняем на своё
Теперь создаём self-signed CA сертификат
Создаём закрытый ключ для нашего сервера При создании замените ldap01 на hostname вашего сервера
Чтобы подписать сертификат сервера с СА, создадим файл /etc/ssl/ldap01.info
следующего содержания (При создании замените ldap01 на hostname вашего сервера):
Example Company меняем на своё
Создаём сертификат для сервера (При создании замените ldap01 на hostname вашего сервера)
Теперь мы имеем certificate, key, и CA cert для установки, используем утилиту ldapmodify для добавления новых опций в конфигурацию
Вводим в консоли
затем вставляем следующее:
После чего жмём дважды enter должна появится надпись modifying entry «cn=config» и Ctrl+D для выхода.
Далее редактируем /etc/default/slapd опцию SLAPD_SERVICES
Теперь пользователь openldap дорлжен иметь доступ к сертификату (не забываем менять ldap01 на своё)
Если после перезагрузки ldap не запустился, а в syslog присутствует main: TLS init def ctx failed: -1, это ошибка конфигурации, проверьте содержимое файла /etc/ldap/slapd.d/cn=config.ldif правильно ли в нём указаны пути и названия сертификатов и убедитесь в том что группа ssl-cert имеет возможность читать закрытый ключ /etc/ssl/private/ldap01_slapd_key.pem
Теперь добавим индексы для samba
Добавляем в базу
Добавим индексы для gosa
Добавляем в базу
Редактируем /etc/ldap/ldap.conf Указываем суффикс базы, в данном случае это dc=example,dc=com
Если при этом slapd на перезагрузится, а команда
то удалите файл /etc/ldap/slapd.d/cn=config/olcDatabase=hdb.ldif
и повторите попытку перезагрузить LDAP
2. Конфигурируем сервер на использование LDAP аутентификации
Устанавливаем необходимые пакеты
На вопросы отвечаем следующим образом:
Вносим изменения в аутентификацию на сервере
Настраиваем pam аутентификацию, для этого выполняем
и активируем профили аутентификации LDAP и UNIX.
3. Заполняем нашу базу в LDAP и настраиваем samba
Устанавливаем необходимые пакеты
Запускаем скрипт конфигурации smbldap-tools
И начинаем отвечать на вопросы:
Теперь нам необходимо проверить SID нашего домена. Для этого делаем следующее, набираем команду
ответом должна быть строка следующего вида
Теперь идём в файл /etc/smbldap-tools/smbldap.conf находим там опцию SID и проверяем, должно совпадать с тем что мы получили выше.
Если при конфигурировании на вопрос «default password validation time (time in days) [45] >» вы поставили « . » точку, тогда ищем опцию
и комментируем её.
Необходимо узнать администратора samba, для этого выполняем команду
Ответом должно показать двух пользователей, один из них nobody а второй и есть администратор samba (в моём случае это admins)
Формируем ldif файл sambadb.ldif
Вместо admins указываете своего админа samba.
Переходим в /etc/ldap
Необходимо отредактировать sambadb.ldif Выполняем команду
Ищем «User SID», записываем его (копируем или запоминаем :) ), далее открываем sambadb.ldif для редактирования, ищем описание администратора, начинается оно так
ищем в описании sambaSID и меняем его значение на то что получили выше.
Я ещё сделал следующее, поменял значение gidNumber и uidNumber на 1000, прописал homeDirectory: /home/admins и loginShell: /bin/sh (это значения локального пользователя admins), и в описании домена
изменил gidNumber и uidNumber на 1001. Думаю вы можете этого не делать.
Заполняем нашу базу
Устанавливаем пароль администратору samba в LDAP
Добавим нового пользователя
Переходим к конфигурированию samba. Идём в /etc/samba
и делаем копию дефолтного конфига
Ниже приведу конфиг моей самбы:
Создаём необходимые каталоги, в моём случае это
Теперь samba необходимо указать пароль админа LDAP
вместо secret поставьте ваш пароль.
Устанавливаем пароль админу samba такой же как установили в LDAP командой smbldap-passwd
Проверяем как работает samba для этого получим список групп в домене
ответом должно быть
Всё настройка samba окончена. Пробуем добавить виндовую машину в домен. Если всё ок продолжаем настраивать дальше.
4. Назначаем права администратору домена и добавляем сервер в домен
Дадим группе Domain Admins права администратора домена для этого выполним следующее:
Ответом должно быть Successfully granted rights.
Теперь любой пользователь входящий в эту группу будет иметь права администратора домена.
Добавим наш сервер в домен
Ответом должно быть Joined domain EXAMPLE.
Проверить добавлен сервер в домен или нет можно командой
Команды для администрирования samba c помощью smbldap-tools
Добавление пользователя: smbldap-useradd -a -P username
Удаление пользователя: smbldap-userdel username
Добавление группы: smbldap-groupadd -a groupname
Добавление пользователя в группу: smbldap-groupmod -m username groupname
Удаление пользователя из группы: smbldap-groupmod -x username groupname
Добавление компьютера в домен: smbldap-useradd -t 0 -w username
Установить основную группу пользователя: smbldap-usermod -g groupname username
Если для администрирования будет использоваться Gosa то этими командами пользоваться нельзя, так так пользователей и группы добавленные этими командами Gosa видеть не будет.
5. Настраиваем Gosa.
Создадим в каталоге /etc/apache2/conf.d файл gosa
Устанавливаем необходимые пакеты для gosa
Заходим в каталог с gosa и запускаем update-gosa
Обновляем интернационализацию gosa
Заходим на сервер через браузер
и приступаем к конфигурации:
Welcome
Здесь вас попросят выполнить непосредственно на сервере команду приблизительно следующего содержания
команда указана на странице.
Language setup
Выбираем язык интерфейса. К сожалению перевод на русский ещё не закончен поэтому при выборе русского интерфейс будет русско-английский
Installation check
License
Раздел лицензии. Естественно нужно принять :)
Здесь указываются настройки для соединения с LDAP .
Местоположение — пишем что хотим
TLS connection — yes
DN администратора — cn=admin
Пароль администратора — secret
Ставим галочку на «Automatically append LDAP base to admin DN»
Use rfc2307bis compliant groups — no
Поле Информация должна быть подсвечена зелёным.
Enable schema validation when logging in — yes Check status должен быть Schema check succeeded в противном случае что-то не так со схемами и это необходимо устранить прежде чем продолжить настройку.
GOsa settings 1/3
Настройки Gosa этап первый. Здесь я укажу только то что я изменил, все остальные настройки оставил как есть.
People DN attribute — uid
People storage subtree — ou=Users
Group storage subtree — ou=Groups
Password encryption algorithm — md5
GOsa settings 2/3
Настройки Gosa этап второй.
Samba SID — S-1-5-21-2252343921-2211050572-3431777101
Workstation container — ou=Computers
Samba SID mapping - yes
Enable Copy & Paste - yes
GOsa settings 3/3
Настройки Gosa этап третий. Здесь я всё оставил как есть
В этом этапе Gosa также предложит мигрировать компьютеры имеющиеся в LDAP , как минимум это будет ваш сервер который вы добавили в домен в предыдущем разделе, как максимум это будут все машины уже добавленные в домен. Мигрировать компьютеры НЕ НУЖНО оставьте их как есть и продолжайте настройку.Feedback
Здесь я ничего не писал а просто нажал Next
Готово
Конфигурация Gosa законченна. Скачиваем конфигурационный файл нажатием на кнопку Download configuration и помещаем его на сервер в папку /etc/gosa, после чего назначаем ему права
Более подробно о всех этапах настройки можно почитать здесь.
После того как gosa.conf помещён в указанный каталог и ему присвоены необходимые права, жмём next и попадаем на страницу авторизации. Для входа используем логин и пароль админа gosa который был создан в разделе LDAP inspection.
Теперь создадим дополнительные каталоги, чтоб в gosa не появлялись предупреждения
Вместо создания каталогов можно удалить плагин asterisk, но я не стал на этом заморачиваться.
Ну вот и всё, настройка Gosa законченна.
Попробуем создать пользователя при помощи Gosa.
Заходим в gosa, в разделе Administration выбираем пункт Пользователи. Далее выбираем Действия — Создать — Пользователь. На открывшейся странице есть три обязательных поля Last name — фамилия пользователя, First name — Имя пользователя, Имя пользователя — логин пользователя, который будет использоваться для авторизации указываем их, далее переходим на вкладку Unix и жмём кнопку Add Posix settings, здесь указываем Домашний каталог, в моём случае это /bin/false. Переходим на вкладку Samba, жмём кнопку Add samba settings, на этой вкладке я ничего не изменял. В низу страници жмём Ок, вас попросят задать пароль пользователя, указываем новый пароль и подтверждение, жмём изменить пароль. Всё пользователь создан.
Также необходимо открыть администратора samba перейти на вкладку Samba и нажать кнопку Применить. Это нужно сделать для внесения необходимых параметров для Gosa.
Если вам необходимо чтоб после создания, удаления, изменения пользователя выполнялся какой нибудь скрипт, то вам необходимо выполнить следующее:
Добавить в конец файла /etc/sudoers следующую строку
В /etc/gosa/gosa.conf находим комент <!– User dialog –> ниже его идёт блок <usertabs> в котором описаны все вкладки диалога по созданию пользователя, к примеру вы хотите чтоб после создания пользователя создавался его домашний каталог, тогда необходимо изменить
если необходимо чтоб ещё выполнялись скрипты при удалении и изменении пользователя то необходимо добавить следующее
%uid - это переменная подставляющая имя пользователя, /etc/gosa/scripts/createuserfolder.sh - это полный путь к скрипту.
Скрипты должны иметь права 750 и быть доступны для группы www-data.
Если же вам необходимо чтоб скрипты выполнялись к примеру только при создании samba акаунта пользователя тогда вместо строки
Если же хотим выполнять скрипты после создания, удаления, изменения группы то ищем комент <!– Group dialog –> и изменяем строку
%cn - это переменная подставляющая название группы
Ну вот собственно и всё. Надеюсь кому нибудь эта информация пригодится
P.S. Gosa довольно мощный инструмент для администрирования, немного в нём покопавшись я обнаружил что в Gosa реализована возможность администрирования почтового сервера Postfix. Так, что я решил перевести свой почтовик на LDAP и администрировать его через Gosa. О том что у меня получилось я напишу в следующей статье
Читайте также: