forum.opennet.ru - "Проблемы с SSO на связке SSHd + kerberos" (9)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"Проблемы с SSO на связке SSHd + kerberos"

Форум Информационная безопасность (Авторизация и аутентификация)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Проблемы с SSO на связке SSHd + kerberos"	+/–
Сообщение от Vitto74 (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ообщить модератору

Оглавление

Проблемы с SSO на связке SSHd + kerberos, ACCA, 19:44 , 06-Апр-16, (1)

Проблемы с SSO на связке SSHd + kerberos, Vitto74, 09:11 , 07-Апр-16, (2)
Проблемы с SSO на связке SSHd + kerberos, Vitto74, 10:47 , 07-Апр-16, (3)
Проблемы с SSO на связке SSHd + kerberos, Vitto74, 14:36 , 07-Апр-16, (4)

Проблемы с SSO на связке SSHd + kerberos, ACCA, 17:47 , 07-Апр-16, (5)

Проблемы с SSO на связке SSHd + kerberos, Vitto74, 18:14 , 07-Апр-16, (6)

Проблемы с SSO на связке SSHd + kerberos, ACCA, 20:04 , 07-Апр-16, (7)

Проблемы с SSO на связке SSHd + kerberos, Vitto74, 08:49 , 08-Апр-16, (9)

Проблемы с SSO на связке SSHd + kerberos, Vitto74, 22:00 , 18-Апр-16, (10)

Сообщения по теме [Сортировка по времени | 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 (ok) on 07-Апр-16, 09:11

> [...]
>> Но через GSSAPI авторизация не проходит. Странность в том, что на локальной
>> машине тоже есть пользователь vitto и если я зайду от пользователя
> Это не странность, а разница между авторизацией и аутентификацией.
> Kerberos через GSSAPI даёт тебе аутентификацию, авторизацию должен сделать кто-то
> другой (в твоём случае оказался локальный PAM).
Вдумчивое изучение мануалов уверило меня в том, что при использовании GSSAPI подсистема PAM не вызывается. Я уже почти смирился, что реализовать все хотелки не получится, т.к. PAM не создаст home_dir, если не будет вызвана.
Получается, что PAM всё же участвует в процессе входа.
Спасибо за наводку. Буду ковыряться дальше.

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

3. "Проблемы с SSO на связке SSHd + kerberos" +/–

Сообщение от Vitto74 (ok) on 07-Апр-16, 10:47

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

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

4. "Проблемы с SSO на связке SSHd + kerberos" +/–

Сообщение от Vitto74 (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 (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 (ok) on 08-Апр-16, 08:49

Всёже у меня каша в голове. Пойду вдумчиво курить мануалы по SAMBA и LDAP.

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

10. "Проблемы с SSO на связке SSHd + kerberos" +/–

Сообщение от Vitto74 (ok) on 18-Апр-16, 22:00

Вдумчивое чтение документации и примеров показало, что для использования AD (LDAP) для хранения учёток необходимо в конфиге прописать binddn (учетка с правами на чтение) и bindpw (пароль этой учетки).
Вопрос такой - можно ли использовать для этой цели учетную запись компьютера, получая доступ на чтение каталога с помощью winbind? На сколько я понял пароль от учетки ПК обновляется раз в 30 дней и Samba хранит его у себя.

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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 (ok) on 07-Апр-16, 09:11
	> [...] >> Но через GSSAPI авторизация не проходит. Странность в том, что на локальной >> машине тоже есть пользователь vitto и если я зайду от пользователя > Это не странность, а разница между авторизацией и аутентификацией. > Kerberos через GSSAPI даёт тебе аутентификацию, авторизацию должен сделать кто-то > другой (в твоём случае оказался локальный PAM). Вдумчивое изучение мануалов уверило меня в том, что при использовании GSSAPI подсистема PAM не вызывается. Я уже почти смирился, что реализовать все хотелки не получится, т.к. PAM не создаст home_dir, если не будет вызвана. Получается, что PAM всё же участвует в процессе входа. Спасибо за наводку. Буду ковыряться дальше.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	3. "Проблемы с SSO на связке SSHd + kerberos"	+/–
	Сообщение от Vitto74 (ok) on 07-Апр-16, 10:47
	> Kerberos через GSSAPI даёт тебе аутентификацию, авторизацию должен сделать кто-то > другой (в твоём случае оказался локальный PAM). Т.е. я правильно понимаю, что если аутентификация через GSSAPI проходит (а она проходит от имени доменного vitto), то начинает работать PAM, для которого vitto - это локальный пользователь? Если так возможно ли аутентифицированного с помощью GSSAPI пользователя vitto авторизовать как MARKET\vitto? Или у меня уже каша в голове от всевозможных мануалов?
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


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

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