Автор Тема: Авторизация локального пользователя для NFS  (Прочитано 2578 раз)

2life

  • Новичок
  • *
  • Сообщений: 11
    • Просмотр профиля
Возможно ли на клиенте использовать локальную учётную запись, а через autofs использовать сетевые учетные данные?

Были настроены карты автоматического монтирования на сервере.

На клиенте локальная запись natalia, настроен AutoFS:

natalia@NataS:~$ sudo mount
....
ldap:ou=auto.nfs,ou=autofs,ou=services,dc=domain,dc=lan on /mnt/fssrv type autofs (rw,relatime,fd=7,pgrp=19919,timeout=600,minproto=5,maxproto=5,indirect,pipe_ino=240442)

natalia@NataS:~$ ls -la /mnt/fssrv/
итого 4
drwxr-xr-x 4 root root    0 авг  8 16:39 .
drwxr-xr-x 3 root root 4096 авг  8 16:39 ..
dr-xr-xr-x 2 root root    0 авг  8 16:39 storage2
dr-xr-xr-x 2 root root    0 авг  8 16:39 storage3

Директория storage2 сервер без LDAP, и файлы доступны. Директория storage3 c сервера на котором развёрнут LDAP, и в эту директорию попасть нельзя.

Так же с клиента проверяю работоспособность сервера:
natalia@NataS:~$ ldapsearch -xLLLWD cn=nssproxy,ou=users,dc=domain,dc=lan
Enter LDAP Password:
dn: dc=domain,dc=lan
objectClass: top
objectClass: dcObject
objectClass: organization
o: domain
dc: domain

dn: cn=admin,dc=domain,dc=lan
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator

dn: ou=users,dc=domain,dc=lan
ou: users
objectClass: organizationalUnit
objectClass: top

dn: ou=groups,dc=domain,dc=lan
ou: groups
objectClass: organizationalUnit
objectClass: top

dn: ou=services,dc=domain,dc=lan
ou: services
objectClass: organizationalUnit
objectClass: top

dn: cn=nssproxy,ou=users,dc=domain,dc=lan
uid: nssproxy
gecos: Network Service Switch Proxy User
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
shadowLastChange: 15140
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/false
uidNumber: 801
gidNumber: 801
homeDirectory: /home/nssproxy
cn: nssproxy
userPassword:: e1NTSEF9aHZQWddsfffgFdkZHRTVVVVVkxmNFZrWlF2Y0Y=

dn: uid=natalia,ou=users,dc=domain,dc=lan
uid: natalia
objectClass: account
objectClass: simpleSecurityObject
objectClass: top

dn: cn=nssproxy,ou=groups,dc=domain,dc=lan
cn: nssproxy
objectClass: top
objectClass: posixGroup
gidNumber: 801
description: Network Service Switch Proxy

dn: cn=sysadmin,ou=groups,dc=domain,dc=lan
cn: sysadmin
objectClass: top
objectClass: posixGroup
gidNumber: 1100
description: UNIX systems administrators

dn: ou=autofs,ou=services,dc=domain,dc=lan
ou: autofs
objectClass: organizationalUnit
objectClass: top

dn: ou=auto.nfs,ou=autofs,ou=services,dc=domain,dc=lan
ou: auto.nfs
objectClass: top
objectClass: automountMap

dn: ou=auto.master,ou=autofs,ou=services,dc=domain,dc=lan
ou: auto.master
objectClass: top
objectClass: automountMap

dn: cn=storage2,ou=auto.nfs,ou=autofs,ou=services,dc=domain,dc=lan
objectClass: top
objectClass: automount
cn: storage2
automountInformation: 192.168.1.39:/fileserver/storage2/

dn: cn=storage3,ou=auto.nfs,ou=autofs,ou=services,dc=domain,dc=lan
objectClass: top
objectClass: automount
cn: storage3
automountInformation: 192.168.1.29:/srv/storage3

dn: cn=/mnt/fssrv,ou=auto.master,ou=autofs,ou=services,dc=domain,dc=lan
objectClass: top
objectClass: automount
cn: /mnt/fssrv
automountInformation: ldap:ou=auto.nfs,ou=autofs,ou=services,dc=domain,dc=lan
  --timeout=600 --ghost rsize=8192,wsize=8192

natalia@NataS:~$

natalia@NataS:~$ getent passwd nssproxy
nssproxy:x:801:801:Network Service Switch Proxy User:/home/nssproxy:/bin/false


Я так понимаю, что тут бы должен помочь Mapping? Только я не очень понимаю, где его настраивать, на клиенте, или на сервере.

И правильная ли такая конфигурация?
[General]
Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
Domain = domain.lan

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

[Translation]
Method = static,nsswitch
GSS-Methods = static,nsswitch

[Static]
natalia@domain.lan = natalia

Погуглив данную тему я обнаружил, что вроде без LDAP этот маппинг делают, но он работает не у всех. Во всех вопросах задаваемых в сети делали маппинг на стороне клиента. Но на одном из форумов я нашёл объяснение, что это задача сервера, и поэтому маппингом должен он заниматься. Кто прав не знаю.
В самом мане по NFSv4 информации на этот вопрос я не нашёл, или плохо читал...



« Последнее редактирование: 09 Август 2019, 09:25:51 от 2life »

egor

  • Администратор
  • Старожил
  • *****
  • Сообщений: 464
    • Просмотр профиля
Прочитал раз десять, так и не понял, что в итоге Вы хотите. Всё в кучу: LDAP, mapping, локальные и нелокальные пользователи =) . Как я понял, с одного NFS-сервера директории монтируются, с другого -- нет. Покажите /etc/exports с обоих серверов.

Егор

2life

  • Новичок
  • *
  • Сообщений: 11
    • Просмотр профиля
Со второго сервера, на компьютере под локальной учетной записью, NFSv4 шара не монтировалось, т.к. там был фильтр *.domain.lan, сменил на 192.168.1.0/255.255.255.0 и всё заработало.
А нужно мне, что бы на компьютере работал локальный пользователь natalia, и его учётная запись маппилась с доменной natalia@domain.lan
Либо, не через маппинг, а что бы шара уже монтировалась с правами доменного пользователя.
Отвечаю на вопрос зачем так нужно. Т.к. компьютеров прилично (~20), и пока профиль переносить у всех нет возможности из локальной в доменную учётку. Хоть может быть это и просто копирование.
Спасибо.
« Последнее редактирование: 09 Август 2019, 13:01:36 от 2life »

egor

  • Администратор
  • Старожил
  • *****
  • Сообщений: 464
    • Просмотр профиля
Стало ещё более непонятно =) . Проблема с NFS решена?

Беда в том, что Вы используете нестандартную терминологию. Что Вы подразумеваете под "доменной записью"? Это сведения о пользователе в виде записи в LDAP-каталоге? В приведённом Вами выводе ldapsearch записи пользователя natalia или natalia@domain.lan в Вашем каталоге нет.

Я не слышал о возможности сопоставить локального пользователя (из /etc/passwd) со сведениями о пользователе из стороннего источника. Обычно делается наоборот: в стороннем источнике есть сведения о пользователях, и они каким-то образом могут быть представлены как "локальные" пользователи. По сути Вы уже это делаете, когда с помощью команды

getent passwd nssproxy
получаете сведения из каталога LDAP, представленные в виде локальной учётки.

Если бы Вы простыми словами обяснили бы текущую ситуацию с Вашей сетью и желаемый Вам результат, мне было бы проще Вам помочь.

Егор

2life

  • Новичок
  • *
  • Сообщений: 11
    • Просмотр профиля
Извините, может я действительно усложнил что-то. И пользуюсь терминологией, к который привык из AD.
С NFS проблем сейчас нет, если работать под пользователями из LDAP-каталога.

Пользователя natalia я завёл как simpleSecurityObject, в выводе он есть, это была ошибка с моей стороны.

dn: uid=natalia,ou=users,dc=domain,dc=lan
uid: natalia
objectClass: account
objectClass: simpleSecurityObject
objectClass: top

На самом деле я уже завёл его (пользователя) нормально.

dn: cn=natalia,ou=users,dc=domain,dc=lan
uid: natalia
gecos: Natalia User
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
shadowLastChange: 15140
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 5003
gidNumber: 7000
homeDirectory: /home/natalia
cn: natalia

К сожалению, что я хочу сделать, не вышло.

Суть моего вопроса, что бы сервер LDAP понимал, что удалённый пользователь natalia (UID 1000) это доменный пользователь natalia@domain.lan (UID 5003).
Могу привести пример такого сопоставления на стороннем ресурсе
https://serverfault.com/questions/915119/nfsv4-mapping-uid-and-gid-on-debian-stretch
Только тут всё делается без LDAP, а непосредственно между локальными записями пользователей, на разных машинах.


« Последнее редактирование: 09 Август 2019, 14:36:25 от 2life »

egor

  • Администратор
  • Старожил
  • *****
  • Сообщений: 464
    • Просмотр профиля
Давайте я Вам немножко расскажу о том, как работает идентификация/аутентификация в Linux и причём тут LDAP.

У каждого объекта в системе (процесса, файла) есть владелец, у которого есть числовой идентификатор и привязанное к этому идентификатору символьное имя. Чтобы понять, какое имя привязано к идентификатору, в Linux (и некоторых других системах) существуют системные вызовы типа getent. С помощью расширяемой библиотеки NSS (name service switch) вызовы getent могут получить сведения об именах (например, пользователей) из различных источников: какие дополнительные nss_* библиотеки установлены и настроены в системе, из таких источников может быть получена информация об именах. Чтобы системные вызовы знали, какие источники доступны в системе и в каком порядке их использовать, существует файл настройки NSS /etc/nsswitch.conf .

То, что Вы называете локальными пользователями, по сути -- это пользователи, сведения о которых имеются в "плоских" текстовых файлах /etc/passwd, /etc/shadow, /etc/group . Вызовы getent воспринимают эти сведения как источник данных о пользователях только потому, что в системе по умолчанию присутствует библиотека nss_files и использование этой библиотеки прописано в /etc/nsswitch.conf. Именно эта библиотека парсит указанные "плоские" файлы, и на запрос "какое имя соответствует идентификатору NNN" выдаёт имя, если знает. Если в /etc/nsswitch.conf в качестве источника данных для passwd не будет указан files, то система ничего не будет знать о таких "локальных пользователях".

Кроме "плоских" файлов в качестве источников информации о пользователях в системе могут выступать всевозможные базы данных, сетевые службы, да вообще всё что угодно. Если в системе присутствует библиотека, умеющая правильно обработать вызов getent, и настройки этой библиотеки позволяют подключаться к источнику данных о пользователях (назовём его базой данных), то пользователь из такого источника сразу же становится "локальным". То есть с точки зрения системы нет никакой разницы, хранятся ли сведения о пользователя в /etc/passwd или где-то в доступной по сети базе данных -- это совершенно одинаковые пользователи.

Так вот LDAP -- это всего-лишь такая сетевая база данных, не больше и не меньше. И если в системе Linux установлена библиотека, к примеру, nss_ldap, которая способна принимать вызовы getent, подключаться к LDAP-серверу, получать оттуда информацию о пользователе и отдавать её в формализованном виде обратно вызову getent, то сервер LDAP может служить информацией о пользователях наравне (или вместо) "плоских" системных файлов.

Так что сервер LDAP ничего не будет "понимать" и "сопоставлять". Его задача простая: хранить данные и выдавать их в ответ на запросы типа ldapsearch (а точнее на запросы протокола LDAP). Функционал базы данных -- это всё, что вы можете получить от LDAP-сервера. "Понимают" и "сопоставляют" системные библиотеки.

Ситуация с аутентификацией практически та же: расширяемая библиотека PAM (pluggable authentication modules) принимает запросы аутентификации и с помощью библиотек pam_* обращается к различным источникам и принимает на основе ответа от этих библиотек решение, прошёл пользователь аутентификацию или нет. Библиотека pam_unix принимает решение об аутентификации пользователя на основе "плоских" системных файлов, а, например, библиотека pam_ldap может принять такое решение на основании данных из каталога LDAP. Опять же, с точки зрения Linux разницы между пользователями из разных источников нет никакой.

Здесь я приводил описание нескольких системных библиотек, которые могут брать информацию для NSS и PAM из LDAP.

Почему администраторы Linux используют LDAP? Потому что это удобно. В сети есть единое хранилище данных о пользователях, к которому могут подключаться системные библиотеки с любого компьютера в сети и брать из этого хранилища информацию для идентификации/аутентификации пользователя. На всех компьютерах в сети информация будет одинакова.

Тут можно провести аналогию с AD (в принципе, поскольку в качестве хранилища данных о пользователях в AD исползуется каталог LDAP, то аналогия, практически прямая =) ). Итак, в AD есть централизованный источник информации о пользователях, и если компьютер знает об этом источнике (введён в домен), то пользователи из централизованного источника  могут пройти аутентификацию и получить права доступа на ресурсы этого компьютера и сетевые ресурсы других компьютеров от своего имени (на всех компьютерах у этого пользователя будет один и тот же идентификатор).

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

То есть если вы заведёте учётку пользователя в каталоге LDAP и на всех компьютерах одинаково настроите  библиотеки типа nss_ldap и pam_ldap, то этот пользователь будет сразу на всех компьютерах и ничего не надо будет сопоставлять.

Кстати, Linux-компьютер вполне реально "ввести" в домен AD (с помощью библиотек nss_sss и pam_sss), то есть доменные пользователи AD смогут пройти аутентификацию и получить права доступа к ресурсам на основании данных из AD. 

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

Егор
 

2life

  • Новичок
  • *
  • Сообщений: 11
    • Просмотр профиля
Егор, ваш ответ можно считать образцовым. Всё описано подробно, но при этом вы использовали всего несколько абзацев. Читать приятно, и всё необычайно просто описано. Спасибо за вашу работу!
По поводу частной задачи вы правы, не стоит делать такие костыли. К тому же,  я подумал, при маппинге за всем этим добром придётся следить, всё таки нужно пересилить себя, и настроить LDAP клиентов на конечных машинах.

egor

  • Администратор
  • Старожил
  • *****
  • Сообщений: 464
    • Просмотр профиля
Если Вы планируете серьёзно работать с Linux, я бы порекомендовал сразу начать изучения какой-нибудь системы управления конфигурациями типа ansible. Они позволяют запуском одного скрипта настроить сразу несколько (или все) компьютеры в сети из одной точки. Очень экономит время (и поднимает самомнение =) ).

Егор