Ahoj, male rozsireni, kdyz uz se tu o tom tak bavime:
Port 389 je plaintext kanál (otevreny text), ktery v pripade podpory sifrovaní umoznuje pouzit klauzuli STARTTLS a na tom samem portu pouzit TLS sifrovani (upgrade kanalu na sifrovany text) Port 636 je sifrovany kanal, kterym probiha SSL/TLS komunikace. Dnes se plaintext bere jako zastaraly, protoze zpravidla neobsahuje zadne kryptograficke overeni prenaseneho textu. Proto pozadavek na SSL/TLS nebo STARTTLS. Pro jednotlive aplikace pak zalezi na tom, zda podporuji plaintext, plaintext s moznosti upgrade (STARTTLS), pripadne SSL/TLS sifrovani. Stale uvadim pojem SSL/TLS, prestoze SSL ma mnoho dobrych duvodu byt odejito do vecnych lovist. Napr. jiz zminovane Active Directory pouziva LDAP strukturu k ukladani dat, ale ta je doplnena o urcite konktretni zaznamy v DNS. Tedy Active Directory je kombinaci obeho. Nejsem z toho nijak nadseny, ale tak to je (je na samostatnou diskusi, zda zvolit BIND nebo neco jineho a nasledne problemy implementace, ktere s tim souvisi). Navic, AD vyuziva pro autentizaci Kerberos, nastesti soucasne systemy bez vyjimky Kerberos v5. Ten z principu vyzaduje funkcni synchronizaci casu (pozor na NTP), k tomu je nutne overit i podporu konkretniho sifrovani na obou stranach. Zde je nutne upozornit na V4 (pozor na starsi systemy, stale se vyskytuje, tusim ze byl podporovan na Win2000/2003) ktere pouzivalo RC4, DES-CBC a DES-PCBC. FreeBSD uz od verze 5 obsahuje v base podporu pro Kerberos v5, ktery obsahuje algoritmy DES-CBC, DES3-CBC, RC4, AES128-CTS, AES256-CTS, Camellia128-CTS, Camellia256-CTS pricemz puvodni mody obsazene ve v4 jsou brane jako zastarale. A to se nebavim o kontrolnich souctech(CRC32, MD4, MD5, SHA1, HMAC, CMAC). Jestli si to dobre pamatuji (uz jsem to nejaky cas nedelal), stare systemy pouzivaly bez vyjimky RC4+MD5, novejsi (Windows 2008/2012) podporuji moznosti konfigurace, kde je to DES-CBC+CRC32 nebo MD5, RC4+MD5 ale a to je hlavni, AES+SHA1 (usetri se strojovy cas a zvysi bezpecnost). V tuto chvili jsou tedy nasledujici mozne implementace base (kerberos v5, MIT klon) security/heimdal (kerberos v5 - http://www.h5l.org/) secuirty/krb5 (MIT - http://www.kerberos.org/) Mezi Heimdal a MIT implementaci je rozdil prakticky jenom v detailech (function replay cache atd., k tomu nejake extra funkcionality navic v HEIMDAL, rozdilnost v parametrech pro kadmin ...), ktere nemaji na funkcnost zivocichare prakticky zadny vliv. Pouzival jsem klasicky MIT Kerberos spise z duvodu jeho multiplatformniho sireni, pouziva ho skoro kazdy a tedy riziko problemu je nizsi nez Heimdal vs MIT. Cyrus-SASL pridava podporu pro dalsi autentizacni mechanismy, tedy anonymous, cram/digest MD5, login, NTLM, OTP ... ale nezahrnuje Kerberos. Ten je resen jednim z jiz vyse zminovanych modulu. Rozsireni OpenLDAP o podporu OpenSSL umoznuje podporu SSL/TLS kanálu a podporu klauzule STARTTLS, tedy jedná se o něco jiného, než vlastní autentizace pomoci Kerberos pripadne Cyrrus/SASL. Ta je na sifrovanem kanale nezavisla, autentizacnim metodam je jedno, jaky je kanal. Aby toho nebylo malo, sifrovani na urovni SSL/TLS ma samo o sobe ma spoustu zadrhelu, ale to neni duvodem tohoto popisu. Kazdopadne stejne jako u ostatnich kanalu doporucuji zablokovat vse s vyjimkou TLSv1.2 a nekterych konkretnich modu, bohuzel vzajemna kompatibilita je strasna vec. Pro nektere systemy a aplikace je alespon SSLv2 jako objev ohne. Honza P.S.: Omlouvam se za dlouhe cteni, ale vyznat se v tom zmatku mne stalo mnoho casu a usili. Mozna se to nekomu bude hodit ;o) Dne 31.10.2016 v 15:22 Vilem Kebrt napsal(a): > Vzhledem k tomu , ze sasl byva posledni dobou temer "vynucovan" na vsech > implementacich ktere kde vidim, nejsem si jistej zda tve reseni je > "jednodussi". > > Jinak z RFC2222 : > > The Simple Authentication and Security Layer (SASL) is a method for > adding authentication support to connection-based protocols. To use > this specification, a protocol includes a command for identifying and > authenticating a user to a server and for optionally negotiating a > security layer for subsequent protocol interactions. > > Imho tvoris kolo tam kde je hotovy vozidlo, ale v ramci zjednoduseni budiz. > Jinak radsi doplnim bleskem informaci nez me stihnete sepsout za > nepresnosti : > OpenLdap = otevrena implementace protokolu LDAP (Lightweight Directory > Access Protocol), takze je to protokol pro komunikaci s tim DIRECTORY > (Jeho odlehcena verze). > Jinak pro dotazujiciho, jeden z nejcasteji vyuzivanych mechanismu je > LDAP komunikace s AD (nebot Active Directory [ tfuj tfuj tfuj, nemam rad > mrkvosoft, ale musel jsem] neni nic jineho nez mrkvosofti implementace > toho directory). > Hadam ze konkretne tam casem miri tve usili :-) > Vilem > > On 10/31/2016 03:09 PM, Martin Bily wrote: >> Zdravím vespolek, >> >> já bych to zjednodušil do polopatistické podoby: Zapomeňte zpočátku na >> všechny SASL metody, Kerbera atd. Používejte autentizaci heslem v jeho >> plain-text podobě. Veškerou komunikaci mezi klientem a serverem ale >> prohánějte šifrovaným kanálem (ldaps, port 636). V rámci toho >> ochráníte před zneužitím i heslo. >> >> Pro server budete potřebovat certifikát, ať už self-signed nebo nějaký >> lepší. V konfiguraci openldap klienta si nastavte, jak moc server a >> jeho certifikát prověřujete nebo ignorujete >> (/usr/local/etc/openldap/ldap.conf, TLS_REQCERT, TLS_CACERT). >> >> V určitých ldap kruzích se nedoporučuje komunikovat zabezpečeně na >> portu 636 (označováno též jako SSL). Místo toho upřednostňují navázat >> spojení nezabezpečeně na ldap port 389, a poté překlopit do >> zabezpečené šifrované podoby. V té souvislosti se to zkráceně označuje >> jako STARTTLS nebo TLS komunikace. Osobně je mi to proti mysli. Můžete >> ale potkat aplikace, které umějí jen jednu z obou variant. >> >> S pozdravem, >> Martin Bílý >> -- FreeBSD mailing list ([email protected]) http://www.freebsd.cz/listserv/listinfo/users-l
