Re: OpenLDAP - začátečnická rada

[Jan Dušátko]

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ý
>>