Speaker Rabbit

abbra


CIFS: curious information funneled sometimes


Previous Entry Share Next Entry
простые вещи без мата или бешеной доли везения
Speaker Rabbit
abbra
На ЛОРе анонсировали некий проект по созданию аналога Active Directory для не-Windows. Проект как проект, автору придется еще многое понять и выяснить, а также реализовать. Я обратил внимание на то, что у него "не срослось" с FreeIPA, поэтому он решил написать самостоятельно, используя тот же 389-ds и MIT krb5 в качестве базиса. Посмотрел я на патчи, зацепился взглядом за патчи к MIT krb5 KDC, которые добавляют поддержку нечувствительных к регистру идентификаторов (case-insensitive principals). Вот патч, можете оценить сами: http://relay.logotek.ru/~viking/opendirectory/patches/krb5-1.9-mscompat.patch

Зацепился я за этот по той причине, что для FreeIPAv3 я как раз делал поддержку нечувствительных к регистру идентификаторов. Вот она: http://git.fedorahosted.org/git/?p=freeipa.git;a=commitdiff;h=cbb1d626b913a7ce802150aa15bda761c9768695. Особенность задачи в том, что сравнивать "нечувствительно" идентификаторы необходимо только при обработке TGS запросов и только, если KDC разрешает это делать, указав специальный флаг. Во всех остальных случаях это чревато проблемами с безопасностью, которые Артемий игнорирует. Ну и особенность LDAP схемы для хранения базы данных идентификаторов Керберос в том, что оба атрибута krbPrincipalName и krbCanonicalName в схеме определены как EQUALITY caseExactIA5Match SUBSTR caseExactSubstringsMatch, что не дает возможности поиска в базе нечувствительно к регистру, а принудительно приводить к нижнему регистру перед сохранением нельзя, потому что это сломает софт, использующий поиск по этим атрибутам непосредственно в LDAP.

Далее автор заявляет, цитирую:
Но даже эта "связка" [FreeIPA] не позволит вам без мата или бешеной доли везения сделать например такую простую вещь как smbclient -L windowshost.company.com -k.

Что же происходит, когда мы хотим сделать упомянутую простую вещь? Ответ зависит от нескольких моментов. Если имеющаяся машина входит в домен AD, в котором находится windowshost.company.com (smbd запущен как domain member, ключи из Windows для этой машины скопированы в /etc/krb5.keytab, winbindd настроен), то достаточно иметь настроенный корректно DNS на этой машине и /etc/krb5.conf вроде такого:
[libdefaults]
 default_realm = COMPANY.COM
 dns_lookup_realm = true
 dns_lookup_kdc = true
[domain_realm]
 .company.com = COMPANY.COM
 company.com = COMPANY.COM

и можно делать kinit user@COMPANY.COM, smbclient -k -L windowshost.company.com, все должно работать.

Если у нас свой, отдельный реалм Kerberos, все это будет работать с теми изменениями, которые мы сделали для FreeIPAv3 -- cross-realm trust с доменом AD как раз для этого предназначен. Вот что происходит сейчас в FreeIPAv3 (git master), когда мы делаем smbclient -k -L windowshost.company.com, имея в кеше билет от нашего KDC:
$ kinit admin
Password for admin@IPA.LOCAL: 
$ KRB5_TRACE=/dev/stderr smbclient -k -L winda.ad.local 
lp_load_ex: changing to config backend registry
[23387] 1339617491.359399: Getting credentials admin@IPA.LOCAL -> cifs/winda.ad.local@AD.LOCAL using ccache FILE:/tmp/krb5cc_1000
[23387] 1339617491.359931: Retrieving admin@IPA.LOCAL -> cifs/winda.ad.local@AD.LOCAL from FILE:/tmp/krb5cc_1000 with result: -1765328243/Matching credential not found
[23387] 1339617491.360307: Retrieving admin@IPA.LOCAL -> krbtgt/AD.LOCAL@IPA.LOCAL from FILE:/tmp/krb5cc_1000 with result: -1765328243/Matching credential not found
[23387] 1339617491.360682: Retrieving admin@IPA.LOCAL -> krbtgt/IPA.LOCAL@IPA.LOCAL from FILE:/tmp/krb5cc_1000 with result: 0/Победа
[23387] 1339617491.360891: Starting with TGT for client realm: admin@IPA.LOCAL -> krbtgt/IPA.LOCAL@IPA.LOCAL
[23387] 1339617491.361176: Retrieving admin@IPA.LOCAL -> krbtgt/AD.LOCAL@IPA.LOCAL from FILE:/tmp/krb5cc_1000 with result: -1765328243/Matching credential not found
[23387] 1339617491.361401: Requesting TGT krbtgt/AD.LOCAL@IPA.LOCAL using TGT krbtgt/IPA.LOCAL@IPA.LOCAL
[23387] 1339617491.361699: Generated subkey for TGS request: aes256-cts/641F
[23387] 1339617491.361875: etypes requested in TGS request: rc4-hmac
[23387] 1339617491.362337: Sending request (1207 bytes) to IPA.LOCAL
[23387] 1339617491.363031: Sending initial UDP request to dgram 192.168.111.138:88
[23387] 1339617491.366403: Received answer from dgram 192.168.111.138:88
[23387] 1339617491.366743: Response was from master KDC
[23387] 1339617491.367040: TGS reply is for admin@IPA.LOCAL -> krbtgt/AD.LOCAL@IPA.LOCAL with session key rc4-hmac/48ED
[23387] 1339617491.367324: TGS request result: 0/Success
[23387] 1339617491.367588: Removing admin@IPA.LOCAL -> krbtgt/AD.LOCAL@IPA.LOCAL from FILE:/tmp/krb5cc_1000
[23387] 1339617491.367766: Storing admin@IPA.LOCAL -> krbtgt/AD.LOCAL@IPA.LOCAL in FILE:/tmp/krb5cc_1000
[23387] 1339617491.368070: Received TGT for service realm: krbtgt/AD.LOCAL@IPA.LOCAL
[23387] 1339617491.368308: Requesting tickets for cifs/winda.ad.local@AD.LOCAL, referrals on
[23387] 1339617491.368568: Generated subkey for TGS request: rc4-hmac/A0D9
[23387] 1339617491.368747: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac
[23387] 1339617491.369039: Sending request (1203 bytes) to AD.LOCAL
[23387] 1339617491.372160: Resolving hostname winda.ad.local.
[23387] 1339617491.373457: Sending initial UDP request to dgram 192.168.111.207:88
[23387] 1339617491.445276: Received answer from dgram 192.168.111.207:88
[23387] 1339617491.446401: Response was not from master KDC
[23387] 1339617491.446747: TGS reply is for admin@IPA.LOCAL -> cifs/winda.ad.local@AD.LOCAL with session key aes256-cts/5FFA
[23387] 1339617491.447045: TGS request result: 0/Success
[23387] 1339617491.447352: Retrying TGS request with desired service ticket enctypes
[23387] 1339617491.447682: Requesting tickets for cifs/winda.ad.local@AD.LOCAL, referrals off
[23387] 1339617491.447963: Generated subkey for TGS request: rc4-hmac/D8FA
[23387] 1339617491.448232: etypes requested in TGS request: rc4-hmac
[23387] 1339617491.448628: Sending request (1194 bytes) to AD.LOCAL
[23387] 1339617491.449689: Resolving hostname winda.ad.local.
[23387] 1339617491.450530: Sending initial UDP request to dgram 192.168.111.207:88
[23387] 1339617491.455554: Received answer from dgram 192.168.111.207:88
[23387] 1339617491.456485: Response was not from master KDC
[23387] 1339617491.456749: TGS reply is for admin@IPA.LOCAL -> cifs/winda.ad.local@AD.LOCAL with session key rc4-hmac/5728
[23387] 1339617491.456978: TGS request result: 0/Success
[23387] 1339617491.457151: Received creds for desired service cifs/winda.ad.local@AD.LOCAL
[23387] 1339617491.457395: Removing admin@IPA.LOCAL -> cifs/winda.ad.local@AD.LOCAL from FILE:/tmp/krb5cc_1000
[23387] 1339617491.457613: Storing admin@IPA.LOCAL -> cifs/winda.ad.local@AD.LOCAL in FILE:/tmp/krb5cc_1000
[23387] 1339617491.458030: Creating authenticator for admin@IPA.LOCAL -> cifs/winda.ad.local@AD.LOCAL, seqnum 0, subkey rc4-hmac/DB18, session key rc4-hmac/5728
OS=[Windows Server 2008 R2 Enterprise 7601 Service Pack 1] Server=[Windows Server 2008 R2 Enterprise 6.1]

	Sharename       Type      Comment
	---------       ----      -------
	ADMIN$          Disk      Remote Admin
	C               Disk      
	C$              Disk      Default share
	IPC$            IPC       Remote IPC
	NETLOGON        Disk      Logon server share 
	SYSVOL          Disk      Logon server share 
Connection to winda.ad.local failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)
NetBIOS over TCP disabled -- no workgroup available

Ошибки, которые показывает smbclient сейчас (connection to ... failed), относятся к последней строке -- NetBIOS поверх TCP/IP в W2K8 R2 по умолчанию запрещен и поэтому получить информацию о рабочих группах нельзя, ее там просто нет. Остальное -- более-менее работает, к FreeIPA 3.1 подтянем до автоматизма.

  • 1
switch повторенный трижды доставляет :) На остальное можно уже не смотреть.

Доставляет также дискуссия на ЛОРе.

> switch повторенный трижды доставляет :)

Более того — доставляет и сам switch, причём не меньше.

+100500!
Школьник практикуется в IT? Не, если объяснить челу, и он примет к сведению и исправит, то может получится толковый инженер.

Я охотно верю, что в схеме с cross-realm у вас "всё и так работает".

Но теперь предложение - исключите _вообще_ AD вообще из схемы, и введите пару Windows'ов в домен kerberos, осблуживаемый FreeIPA (да, у вас это IPA.LOCAL, делается это через ksetup в Windows), и потом попробуйте smbclient на эту Windows, и пару запросов с одной Windows до другой. Ну и пару раз перезагрузите компьютеры.

Потом можно и вернуться к дискуссии, если у вас всё заработает.

Поскольку smbd в такой конфигурации является обычным DC, то машины Windows можно ввести в его домен нормальным способом и использовать их как обычно. В этом случае kerberos auth на эти машины работать не будет.

Использовать режим совместимости с RFC4120 в Windows, конечно, можно, но тогда придется вручную мапить все приниципалы, которые должны ходить на эту машину, в имеющихся (в домене или локально, не важно), пользователей. Если у вас количество таких сущностей ограничено, то особой проблемы нет.

> но тогда придется вручную мапить все приниципалы, которые должны ходить на эту машину, в имеющихся (в домене или локально, не важно), пользователей

А этим занимается виндовый компонент (сервис ODClient, оно же ODirectory.exe + samhelper.exe). Так что вручную как раз мапить ничего более не надо.

Вот это замечательно.

> Поскольку smbd в такой конфигурации является обычным DC

А почему вы опять решили, что smbd будет каким-то "DC"? :-) Он такой же рядовой член домена как и рабочая станция с виндой или линуксом.

Вы невнимательны. "такой конфигурации" -- упомянутой в заметке. smbd там работает как контроллер домена и обеспечивает все, о чем говорится. Если Вы хотите трудностей, делайте обычный domain member.

  • 1
?

Log in

No account? Create an account