![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
простые вещи без мата или бешеной доли везения
На ЛОРе анонсировали некий проект по созданию аналога 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.
Далее автор заявляет, цитирую:
Что же происходит, когда мы хотим сделать упомянутую простую вещь? Ответ зависит от нескольких моментов. Если имеющаяся машина входит в домен AD, в котором находится windowshost.company.com (smbd запущен как domain member, ключи из Windows для этой машины скопированы в /etc/krb5.keytab, winbindd настроен), то достаточно иметь настроенный корректно DNS на этой машине и /etc/krb5.conf вроде такого:
и можно делать 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:
Ошибки, которые показывает smbclient сейчас (connection to ... failed), относятся к последней строке -- NetBIOS поверх TCP/IP в W2K8 R2 по умолчанию запрещен и поэтому получить информацию о рабочих группах нельзя, ее там просто нет. Остальное -- более-менее работает, к FreeIPA 3.1 подтянем до автоматизма.
Зацепился я за этот по той причине, что для 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 подтянем до автоматизма.