The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Проблемы с SSO на связке SSHd + kerberos"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Информационная безопасность (Авторизация и аутентификация)
Изначальное сообщение [ Отслеживать ]

"Проблемы с SSO на связке SSHd + kerberos"  +/
Сообщение от Vitto74 email(ok) on 05-Апр-16, 10:02 
Доброго дня. Столкнулся с проблемой в настройке OSS на ubuntu, а конкретно с настройкой SSHd. Привожу конфиги.

/etc/ssh/sshd_config

# Kerberos options
KerberosAuthentication yes
KerberosGetAFSToken yes
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
GSSAPIKeyExchange yes

AllowGroups adm BUILTIN\administrators

UsePAM yes

/etc/samba/smb.conf
[global]
workgroup = MARKET
realm = MARKET.LOCAL
security = ADS
encrypt passwords = true
dns proxy = no
socket options = TCP_NODELAY
domain master = no
local master = no
preferred master = no
os level = 0
domain logons = no

load printers = yes
show add printer wizard = yes
printcap name = cups
disable spoolss = no

idmap uid = 10000 - 40000
idmap gid = 10000 - 40000
winbind enum groups = yes
winbind enum users = yes
winbind use default domain = no
winbind normalize names = yes
winbind nested groups = yes
template shell = /bin/bash
winbind refresh tickets = yes
kerberos method  = secrets and keytab

winbind offline logon = yes
winbind cache time = 300
#password server = market.local
dedicated keytab file = /etc/krb5.keytab

/etc/krb5.conf
[libdefaults]
    default_realm = MARKET.LOCAL

    kdc_timesync = 1
    ccache_type = 4
    forwardable = true
    proxiable = true
    v4_instance_resolve = false
    v4_name_convert = {
        host = {
            rcmd = host
            ftp = ftp
        }
        plain = {
            something = something-else
        }
    }
    fcc-mit-ticketflags = true

[realms]
    MARKET.LOCAL = {
        kdc = market.local
        admin_server = market.local
        default_domain = market.local
    }

[domain_realm]
    .market.local = MARKET.LOCAL
    market.local = MARKET.LOCAL

[login]
    krb4_convert = false
    krb4_get_tickets = false

root@Admin-pc:/etc# net ads keytab list
Vno  Type                                        Principal
  2  des-cbc-crc                                 HOST/admin-pc.market.local@MARKET.LOCAL
  2  des-cbc-md5                                 HOST/admin-pc.market.local@MARKET.LOCAL
  2  aes128-cts-hmac-sha1-96                     HOST/admin-pc.market.local@MARKET.LOCAL
  2  aes256-cts-hmac-sha1-96                     HOST/admin-pc.market.local@MARKET.LOCAL
  2  arcfour-hmac-md5                            HOST/admin-pc.market.local@MARKET.LOCAL
  2  des-cbc-crc                                 HOST/admin-pc@MARKET.LOCAL
  2  des-cbc-md5                                 HOST/admin-pc@MARKET.LOCAL
  2  aes128-cts-hmac-sha1-96                     HOST/admin-pc@MARKET.LOCAL
  2  aes256-cts-hmac-sha1-96                     HOST/admin-pc@MARKET.LOCAL
  2  arcfour-hmac-md5                            HOST/admin-pc@MARKET.LOCAL
  2  des-cbc-crc                                 ADMIN-PC$@MARKET.LOCAL
  2  des-cbc-md5                                 ADMIN-PC$@MARKET.LOCAL
  2  des-cbc-crc                                 host/admin-pc@MARKET.LOCAL
  2  des-cbc-crc                                 host/admin-pc.market.local@MARKET.LOCAL
  2  des-cbc-md5                                 host/admin-pc@MARKET.LOCAL
  2  des-cbc-md5                                 host/admin-pc.market.local@MARKET.LOCAL
  2  aes128-cts-hmac-sha1-96                     host/admin-pc@MARKET.LOCAL
  2  aes128-cts-hmac-sha1-96                     host/admin-pc.market.local@MARKET.LOCAL
  2  aes256-cts-hmac-sha1-96                     host/admin-pc.market.local@MARKET.LOCAL
  2  arcfour-hmac-md5                            host/admin-pc.market.local@MARKET.LOCAL
  2  arcfour-hmac-md5                            host/admin-pc@MARKET.LOCAL
  2  aes256-cts-hmac-sha1-96                     host/admin-pc@MARKET.LOCAL
  2  aes128-cts-hmac-sha1-96                     ADMIN-PC$@MARKET.LOCAL
  2  arcfour-hmac-md5                            ADMIN-PC$@MARKET.LOCAL
  2  aes256-cts-hmac-sha1-96                     ADMIN-PC$@MARKET.LOCAL

root@Admin-pc:/etc# groups MARKET\\vitto
MARKET\vitto : MARKET\пользователи_домена
MARKET\adm-ssh
MARKET\администраторы_домена
MARKET\пользователи_терминала_sever
MARKET\terminalusers
MARKET\администраторы_схемы
MARKET\администраторы_предприятия
MARKET\debugger_users
MARKET\группа_с_запрещением_репликации_паролей_rodc
BUILTIN\users
BUILTIN\administrators

root@Admin-pc:/etc# id MARKET\\vitto
uid=10005(MARKET\vitto)
gid=10001(MARKET\пользователи_домена)
группы=10001(MARKET\пользователи_домена),
10041(MARKET\adm-ssh),
10003(MARKET\администраторы_домена),
10035(MARKET\пользователи_терминала_sever),
10027(MARKET\terminalusers),
10010(MARKET\администраторы_схемы),
10008(MARKET\администраторы_предприятия),
10024(MARKET\debugger_users),
10030(MARKET\группа_с_запрещением_репликации_паролей_rodc),
10037(BUILTIN\users),
10036(BUILTIN\administrators)

В принципе, если разрешить доступ всем, т.е. закомментить опцию AllowGroups, то я могу авторизоваться по паролю от имени доменных пользователей
ssh MARKET\\vitto@admin-pc.market.local

Но через GSSAPI авторизация не проходит. Странность в том, что на локальной машине тоже есть пользователь vitto и если я зайду от пользователя MARKET\vitto на Win-машину и зайду по ssh через putty, используя GSSAPI, то меня авторизует как локального vitto, а не доменного! Если же я введу логин MARKET\vitto, то авторизация пойдет только по паролю, а в логе будет вот это

sshd[7168]: debug3: fd 5 is not O_NONBLOCK
sshd[7168]: debug1: Forked child 7328.
sshd[7168]: debug3: send_rexec_state: entering fd = 8 config len 891
sshd[7168]: debug3: ssh_msg_send: type 0
sshd[7168]: debug3: send_rexec_state: done
sshd[7328]: debug3: oom_adjust_restore
sshd[7328]: Set /proc/self/oom_score_adj to 0
sshd[7328]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
sshd[7328]: debug1: inetd sockets after dupping: 3, 3
sshd[7328]: Connection from 192.168.101.10 port 60076 on 192.168.100.31 port 22
sshd[7328]: debug1: Client protocol version 2.0; client software version PuTTY_Release_0.63
sshd[7328]: debug1: match: PuTTY_Release_0.63 pat PuTTY-Release-0.5*,PuTTY_Release_0.5*,PuTTY_Release_0.60*,PuTTY_Release_0.61*,PuTTY_Release_0.62*,PuTTY_Release_0.63*,PuTTY_Release_0.64* compat 0x00004000
sshd[7328]: debug1: Enabling compatibility mode for protocol 2.0
sshd[7328]: debug1: Local version string SSH-2.0-OpenSSH_6.9p1 Ubuntu-2ubuntu0.1
sshd[7328]: debug2: fd 3 setting O_NONBLOCK
sshd[7328]: debug2: Network child is on pid 7329
sshd[7328]: debug3: preauth child monitor started
sshd[7328]: debug3: privsep user:group 121:65534 [preauth]
sshd[7328]: debug1: permanently_set_uid: 121/65534 [preauth]
sshd[7328]: debug2: compat_kex_proposal: original KEX proposal: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1 [preauth]
sshd[7328]: debug2: Compat: skipping algorithm "diffie-hellman-group-exchange-sha256" [preauth]
sshd[7328]: debug2: compat_kex_proposal: compat KEX proposal: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1 [preauth]
sshd[7328]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
sshd[7328]: debug3: mm_request_send entering: type 42 [preauth]
sshd[7328]: debug3: mm_request_receive_expect entering: type 43 [preauth]
sshd[7328]: debug3: mm_request_receive entering [preauth]
sshd[7328]: debug3: mm_request_receive entering
sshd[7328]: debug3: monitor_read: checking request 42
sshd[7328]: debug3: mm_request_send entering: type 43
sshd[7328]: debug1: SSH2_MSG_KEXINIT sent [preauth]
sshd[7328]: debug1: SSH2_MSG_KEXINIT received [preauth]
sshd[7328]: debug2: kex_parse_kexinit: gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1 [preauth]
sshd[7328]: debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
sshd[7328]: debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com [preauth]
sshd[7328]: debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com [preauth]
sshd[7328]: debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 [preauth]
sshd[7328]: debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 [preauth]
sshd[7328]: debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
sshd[7328]: debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
sshd[7328]: debug2: kex_parse_kexinit:  [preauth]
sshd[7328]: debug2: kex_parse_kexinit:  [preauth]
sshd[7328]: debug2: kex_parse_kexinit: first_kex_follows 0  [preauth]
sshd[7328]: debug2: kex_parse_kexinit: reserved 0  [preauth]
sshd[7328]: debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa2048-sha256,rsa1024-sha1 [preauth]
sshd[7328]: debug2: kex_parse_kexinit: ssh-rsa,ssh-dss [preauth]
sshd[7328]: debug2: kex_parse_kexinit: aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 [preauth]
sshd[7328]: debug2: kex_parse_kexinit: aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 [preauth]
sshd[7328]: debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5 [preauth]
sshd[7328]: debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5 [preauth]
sshd[7328]: debug2: kex_parse_kexinit: none,zlib [preauth]
sshd[7328]: debug2: kex_parse_kexinit: none,zlib [preauth]
sshd[7328]: debug2: kex_parse_kexinit:  [preauth]
sshd[7328]: debug2: kex_parse_kexinit:  [preauth]
sshd[7328]: debug2: kex_parse_kexinit: first_kex_follows 0  [preauth]
sshd[7328]: debug2: kex_parse_kexinit: reserved 0  [preauth]
sshd[7328]: debug1: kex: client->server aes256-ctr hmac-sha2-256 none [preauth]
sshd[7328]: debug1: kex: server->client aes256-ctr hmac-sha2-256 none [preauth]
sshd[7328]: debug2: bits set: 1032/2048 [preauth]
sshd[7328]: debug1: expecting SSH2_MSG_KEXDH_INIT [preauth]
sshd[7328]: debug2: bits set: 1054/2048 [preauth]
sshd[7328]: debug3: mm_key_sign entering [preauth]
sshd[7328]: debug3: mm_request_send entering: type 6 [preauth]
sshd[7328]: debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth]
sshd[7328]: debug3: mm_request_receive_expect entering: type 7 [preauth]
sshd[7328]: debug3: mm_request_receive entering [preauth]
sshd[7328]: debug3: mm_request_receive entering
sshd[7328]: debug3: monitor_read: checking request 6
sshd[7328]: debug3: mm_answer_sign
sshd[7328]: debug3: mm_answer_sign: hostkey proof signature 0x558b77c5efc0(271)
sshd[7328]: debug3: mm_request_send entering: type 7
sshd[7328]: debug2: monitor_read: 6 used once, disabling now
sshd[7328]: debug2: set_newkeys: mode 1 [preauth]
sshd[7328]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
sshd[7328]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
sshd[7328]: debug2: set_newkeys: mode 0 [preauth]
sshd[7328]: debug1: SSH2_MSG_NEWKEYS received [preauth]
sshd[7328]: debug1: KEX done [preauth]
sshd[7328]: debug1: userauth-request for user MARKTE\\\\vitto service ssh-connection method none [preauth]
sshd[7328]: debug1: attempt 0 failures 0 [preauth]
sshd[7328]: debug3: mm_getpwnamallow entering [preauth]
sshd[7328]: debug3: mm_request_send entering: type 8 [preauth]
sshd[7328]: debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM [preauth]
sshd[7328]: debug3: mm_request_receive_expect entering: type 9 [preauth]
sshd[7328]: debug3: mm_request_receive entering [preauth]
sshd[7328]: debug3: mm_request_receive entering
sshd[7328]: debug3: monitor_read: checking request 8
sshd[7328]: debug3: mm_answer_pwnamallow
sshd[7328]: debug2: parse_server_config: config reprocess config len 891
sshd[7328]: Invalid user MARKTE\\vitto from 192.168.101.10
sshd[7328]: debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 0
sshd[7328]: debug3: mm_request_send entering: type 9
sshd[7328]: debug2: monitor_read: 8 used once, disabling now
sshd[7328]: input_userauth_request: invalid user MARKTE\\\\vitto [preauth]
sshd[7328]: debug3: mm_audit_event entering [preauth]
sshd[7328]: debug3: mm_request_send entering: type 112 [preauth]
sshd[7328]: debug3: mm_start_pam entering [preauth]
sshd[7328]: debug3: mm_request_send entering: type 100 [preauth]
sshd[7328]: debug3: mm_inform_authserv entering [preauth]
sshd[7328]: debug3: mm_request_send entering: type 4 [preauth]
sshd[7328]: debug2: input_userauth_request: try method none [preauth]
sshd[7328]: debug3: userauth_finish: failure partial=0 next methods="publickey,gssapi-keyex,gssapi-with-mic,password" [preauth]
sshd[7328]: debug3: mm_request_receive entering
sshd[7328]: debug3: monitor_read: checking request 112
sshd[7328]: debug3: mm_answer_audit_event entering
sshd[7328]: debug1: userauth-request for user MARKTE\\\\vitto service ssh-connection method gssapi-with-mic [preauth]
sshd[7328]: debug1: attempt 1 failures 0 [preauth]
sshd[7328]: debug2: input_userauth_request: try method gssapi-with-mic [preauth]
sshd[7328]: debug3: userauth_finish: failure partial=0 next methods="publickey,gssapi-keyex,gssapi-with-mic,password" [preauth]
sshd[7328]: debug3: mm_request_receive entering
sshd[7328]: debug3: monitor_read: checking request 100
sshd[7328]: debug1: PAM: initializing for "MARKTE\\vitto"
sshd[7328]: debug1: PAM: setting PAM_RHOST to "192.168.101.10"
sshd[7328]: debug1: PAM: setting PAM_TTY to "ssh"
sshd[7328]: debug2: monitor_read: 100 used once, disabling now
sshd[7328]: debug3: mm_request_receive entering
sshd[7328]: debug3: monitor_read: checking request 4
sshd[7328]: debug3: mm_answer_authserv: service=ssh-connection, style=, role=
sshd[7328]: debug2: monitor_read: 4 used once, disabling now

Для меня загадка полему при использовании GSSAPI передается логин MARKTE\\\\vitto (т.е. два экранированных слеша), а не один как в PAM? Варианты что делать у меня закончились.
В многочисленных мануалах по настройке Kerberos+SSHd всегда используется опция winbind use default domain = yes в smb.conf, но я считаю такую практику не правльной т.к. не возможно определить принадлежность пользователя или группы к домену.

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Проблемы с SSO на связке SSHd + kerberos"  +/
Сообщение от ACCA (ok) on 06-Апр-16, 19:44 
[...]
> Но через GSSAPI авторизация не проходит. Странность в том, что на локальной
> машине тоже есть пользователь vitto и если я зайду от пользователя

Это не странность, а разница между авторизацией и аутентификацией.

Kerberos через GSSAPI даёт тебе аутентификацию, авторизацию должен сделать кто-то другой (в твоём случае оказался локальный PAM).

Прочитай вторую часть: https://nsrc.org/workshops/ws-files/2011/sanog17/exercises/e...

Удачи потрахаться с NTP, DNS и nscd. Шаг влево, шаг вправо - подрываешься на растяжке, прыжок на месте - проваливаешься под землю.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Проблемы с SSO на связке SSHd + kerberos"  +/
Сообщение от Vitto74 email(ok) on 07-Апр-16, 09:11 
> [...]
>> Но через GSSAPI авторизация не проходит. Странность в том, что на локальной
>> машине тоже есть пользователь vitto и если я зайду от пользователя
> Это не странность, а разница между авторизацией и аутентификацией.
> Kerberos через GSSAPI даёт тебе аутентификацию, авторизацию должен сделать кто-то
> другой (в твоём случае оказался локальный PAM).

Вдумчивое изучение мануалов уверило меня в том, что при использовании GSSAPI подсистема PAM не вызывается. Я уже почти смирился, что реализовать все хотелки не получится, т.к. PAM не создаст home_dir, если не будет вызвана.
Получается, что PAM всё же участвует в процессе входа.
Спасибо за наводку. Буду ковыряться дальше.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Проблемы с SSO на связке SSHd + kerberos"  +/
Сообщение от Vitto74 email(ok) on 07-Апр-16, 10:47 
> Kerberos через GSSAPI даёт тебе аутентификацию, авторизацию должен сделать кто-то
> другой (в твоём случае оказался локальный PAM).

Т.е. я правильно понимаю, что если аутентификация через GSSAPI проходит (а она проходит от имени доменного vitto), то начинает работать PAM, для которого vitto - это локальный пользователь?
Если так возможно ли аутентифицированного с помощью GSSAPI пользователя
vitto авторизовать как MARKET\vitto?
Или у меня уже каша в голове от всевозможных мануалов?

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "Проблемы с SSO на связке SSHd + kerberos"  +/
Сообщение от Vitto74 email(ok) on 07-Апр-16, 14:36 
> Kerberos через GSSAPI даёт тебе аутентификацию, авторизацию должен сделать кто-то
> другой (в твоём случае оказался локальный PAM).

Методом проб и ошибок выяснилось, что сначала идет аутентификация и если она проходит успешно через GSSAPI, то начинает работать PAM, но уже не с auth, а сразу с account.

Более того, тем же методом я понял, что pam_winbind на этапе auth (если GSSAPI не сработал) корректно обрабатывает имя vitto@market.local и передает на этап account уже корректное имя MARKET\vitto, который уже есть в списке пользователей.

Но если pam_winbind не вызывается на этапе auth (а если GSSAPI отработал, то не вызывается), то в account передается обычное имя без доменной части и авторизация проходит уже от имени локального пользователя.
А теперь вопрос к тем, кто глубже разбирается или в PAM или в GSSAPI. Каким образом имя пользователя на этапе auth меняется с vitto@market.local на MARKET\vitto?
Получается, что pam_winbind находит у себя пользователя с символом [at] и ищет его в своей базе, находит, а потом два варианта. Либо pam_winbind меняет имя пользователя и передает работу секции account, либо передает в account идентификатор пользователя.
В первом случае, чтобы все заработало, нужно заставить GSSAPI делать тоже самое, а во втором заставить это сделать в секции account. Я не очень хорошо знаком с механизмом PAM и не могу найти информацию о таких тонкостях.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

5. "Проблемы с SSO на связке SSHd + kerberos"  +/
Сообщение от ACCA (ok) on 07-Апр-16, 17:47 
> Методом проб и ошибок выяснилось, что сначала идет аутентификация и если она
> проходит успешно через GSSAPI, то начинает работать PAM, но уже не

Надо немного подправить - ты поленился почитать словарь.

Аутентификация - подтверждение аутентичности. То есть сравнить фотографию с мордой лица и сказать - "это он". Возможно, с доп. ритуалами - осветить фотографию ультрафиолетом, чтобы понять, что она не подменная, пробить номер документа по базе и проч.

Авторизация - зная, что это MARKET\vitto, разрешить нажимать в лифте кнопку "2", но не разрешать "3" и "4".


[...]
> А теперь вопрос к тем, кто глубже разбирается или в PAM или
> в GSSAPI. Каким образом имя пользователя на этапе auth меняется с
> vitto@market.local на MARKET\vitto?

Это слово - idmap.
https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/...
Обрати внимание на первую картинку.

> Получается, что pam_winbind находит у себя пользователя с символом [at] и ищет
> его в своей базе, находит, а потом два варианта. Либо pam_winbind
> меняет имя пользователя и передает работу секции account, либо передает в
> account идентификатор пользователя.
> В первом случае, чтобы все заработало, нужно заставить GSSAPI делать тоже самое,

Не нужно GSSAPI заставлять, это не его забота. GSSAPI говорит - это корова. А пригодна ли она в пищу, решают PAM, LDAP, WINBIND, /etc/passwd и остальные.

> очень хорошо знаком с механизмом PAM и не могу найти информацию
> о таких тонкостях.

Ищи ещё. Там тебя поджидает ещё один сюрприз - это в Samba v3/Windows NT основным механизмом был winbind. А в новых Samba v4/Windows 2012 основным стал LDAP, со всеми вытекающими из него pam_ldap...


Напоследок - после того, как отработал pam, тебе нужно будет отработать login script (тот же /etc/profile), который, зная что это юзер XXX, создать ему /home/XXX и, скажем, примонтировать его каталог по, например, NFSv4. А когда юзер будет уходить, то отмонтировать его каталог и удалить /home/XXX.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Проблемы с SSO на связке SSHd + kerberos"  +/
Сообщение от Vitto74 email(ok) on 07-Апр-16, 18:14 
>> Получается, что pam_winbind находит у себя пользователя с символом [at] и ищет
>> его в своей базе, находит, а потом два варианта. Либо pam_winbind
>> меняет имя пользователя и передает работу секции account, либо передает в
>> account идентификатор пользователя.
>> В первом случае, чтобы все заработало, нужно заставить GSSAPI делать тоже самое,
> Не нужно GSSAPI заставлять, это не его забота. GSSAPI говорит - это
> корова. А пригодна ли она в пищу, решают PAM, LDAP, WINBIND,
> /etc/passwd и остальные.

Хорошо. GSSAPI сказал, что vitto это vitto. Но кто должен сказать, что это доменный vitto, а не локальный? И на каком основании?

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "Проблемы с SSO на связке SSHd + kerberos"  +/
Сообщение от ACCA (ok) on 07-Апр-16, 20:04 
> Хорошо. GSSAPI сказал, что vitto это vitto. Но кто должен сказать, что
> это доменный vitto, а не локальный? И на каком основании?

GSSAPI сказал, что это доменный principal vitto@MARKET или MARKET\vitto или ещё какой там синтаксис, он про локальных не знает ничего и знать не должен.

PAM/NSS (через pam_winbind или pam_ldap) по своим картам или правилам (idmap) смотрят, как MARKET\vitto назвать локально (например, root) и в какие группы включить. Группы имеют какие-то права на хосте, это то, что будет ему позволено делать локально.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

9. "Проблемы с SSO на связке SSHd + kerberos"  +/
Сообщение от Vitto74 email(ok) on 08-Апр-16, 08:49 
Всёже у меня каша в голове. Пойду вдумчиво курить мануалы по SAMBA и LDAP.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

10. "Проблемы с SSO на связке SSHd + kerberos"  +/
Сообщение от Vitto74 email(ok) on 18-Апр-16, 22:00 
Вдумчивое чтение документации и примеров показало, что для использования AD (LDAP) для хранения учёток необходимо в конфиге прописать binddn (учетка с правами на чтение) и bindpw (пароль этой учетки).
Вопрос такой - можно ли использовать для этой цели учетную запись компьютера, получая доступ на чтение каталога с помощью winbind? На сколько я понял пароль от учетки ПК обновляется раз в 30 дней и Samba хранит его у себя.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру