простые вещи без мата или бешеной доли везения

[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 подтянем до автоматизма.

Comments

[voins.livejournal.com]

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

[abbra]

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

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

[poige.livejournal.com]

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

[andy-shev.livejournal.com]

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

[dalth.livejournal.com]

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

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

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

[abbra]

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

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

[dalth.livejournal.com]

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

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

[abbra]

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

[dalth.livejournal.com]

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

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

[abbra]

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