nfs4 и kerberos: как оно вообще работает?

Question

[mayorovp]

В интернете я нашел кучу всяких how-to для разных дистрибутивов, но почему-то не смог найти, как эта связка вообще работает.

От чьего имени nfs-клиент авторизуется на nfs-сервере? От имени компьютера или от имени пользователя?

Каким образом это имя проверяется сервером? Где настраивать права? Если chmod, то как, опять-таки, соотносятся uid, gid и учетные записи kerberos?

Что-то меня начинает преследовать ощущение, что с поддержкой kerberos меня обманули…

Comments

[mayorovp]

Да, вот что конкретно меня смущает: во всех how-to обязательно делается ktadd, и никогда — kinit

Answer 1

[DmZ]

Может плохие how-to читали? Вот очень хорошо расписано: NFS4Howto

Kerberos используется для аутентификации пользоваля (валидный или нет), а для авторизации (пермишины на файлах) используются стандартные средства nfs4 (idmapd).
В случае без kerberos — аутентификацией пользователя занимается локальная система (PAM например). Т.е. использовать NFS шару может любой локальный пользователь у которого есть авторизация (пермишины на файлах). В случае с kerberos пользователю не достаточно иметь локальный вход — чтобы пользоваться шарой у него должен быть валидный тикет, ну и соответствующие пермишины на файлах.

Как соотносятся «учетные записи» kerberos зависит от того КАК настроена система аутентификации. Керберос никак за авторизацию в данном случае не отвечает — только за аутентификацию.
Например если Kerberos + LDAP + PAM — то uid/gid пользователя может передаваться из LDAP, соотв. он будет одинаковый везде.
Если нет центрального хранения пользователей, то нужно разруливать через маппинг id в nfs.

Comments

[mayorovp]

Допустим, на сервер «стучится» клиент с euid 1014 и тикетом, говорящим, что он — [e-mail]
Каким образом сервер будет проверять аутентичность (без LDAP)? Отбросит реалм и проверит по /etc/passwd? Или алгоритм более сложен?
А что изменится при наличии LDAP?

И еще вопрос: зачем клиенту нужен ключ в keytab? Зачем серверу проверять аутентичность не только клиента, но и рабочей станции? А то я как-то никак не могу найти угрозу, от которой подобным образом защищаются.

[DmZ]

Сервер будет проверять аутентичность по своей личной базе, это уже никак к NFS не относится :) Читайте howto по настройке Kerberos (конкретно Principals и Realm administration). В общем случае [e-mail] не имеет никакого отношения к uid или passwd — он проверятся по локальной базе principal.
UID же мапится nfs сервером, а не керберос, и проверяется клиентом при доступе к файлам.

По поводу тикета для рабочей станции — шара мапится при включении, когда пользовательского тикета еще нет.
— Соответственно именно маунт шары происходит благодаря тикету workstation.
— Далее, грубо говоря, просто что бы сделать ls на шару, пользователь должен получить свой тикет от KDC. NFS сервер его проверит и позволит ls.
— Предыдущие два пункта не происходят если NFS без kerberos — т.е. маунт шары и ls никак сервером не контролируются
А вот когда NFS сервер будет передавать метаданные файлов — в качестве владельца будет подставлен UID пользователя на локальной машине. Например владелец на сервере user14 с uid=1014 а на клиенте этот же пользователь с uid=514 — NFS перемапит пользователя и клиент увидит файл с владельцем user14/uid=514 (но это так и без керберос)
В случае использования LDAP — просто uid пользователя всегда будет одинаковый на всех машинах.

Немного не понял про угрозу — вы хотите знать от какой угрозы защищаются используя NFS + Kerberos?
Это не угроза — это удобство управления. Kerberos используется как централизованная система аутентификации. Пользователь один раз получит тикет при логине в систему и использует его для авторизации в NFS, в почте, при логине на FTP и т.д. и т.п. — таким образом пароль вводится только один раз. Проведите аналогию с Active Directory — домен активно использует Kerberos — пользователю достаточно ввести один раз пароль при логине и он имеет доступ к другим шарам без пароля, имеет доступ на IIS без пароля и тп.

К защите от угроз может относится то, что при использовании керберос появляется возможность криптовать NFS трафик…

[mayorovp]

По поводу угрозы — я хотел узнать, зачем вообще контролируют, кто монтирует удаленную ФС, если основные проверки происходят позже?

[DmZ]

Контроль — это авторизация. Керберос занимается аутентификацией — посмотрите разницу в /etc/exports — без кербероса вы указываете конкретные IP-диапазоны кому можно маунтить, а с керберосом — достаточно валидного тикета. Т.е. в данном случае керберос «контролирует» кто может маунтить шару вместо «контроля» по IP. Таким образом разрешается доступ в большой сети предприятия без необходимости трекать IP-адреса всех клиентов.

Имхо, пользовательсий тикет нужен если на одной workstation может работать несколько пользователей — локальные видят только локальную систему, а если залогинился «корпоративный» пользователь — то он сразу и увидел какие-то свои и общие документы.

[mayorovp]

Да что вы мне все про Kerberos пишете, когда я вас про всю связку спрашиваю?
Мне не интересно, чего Kerberos не делает, мне интересно, кто этим занимается.

[DmZ]

Хорошо, напишу с другого конца, отвечая на вопрос «кто». Керберос контролирует кто может подключить шару, а NFS контролирует кто может прочитать/записать из шары. Это ответило на ваш вопрос?
Зачем два тикета — затем что пользователь не может примонтировать шару, это может только root от имени workstation. Пользовательский тикет просто тупо запрещает anonymous access на шару.

[mayorovp]

Нда, где-то меня обманули…