Blog
Zaštita LDAP servisnih naloga u Active Directory-ju: Mirket NHI LDAP Proxy
10. novembar 2026.
Firewall, VPN, NAC, serveri za štampu, ERP i stare aplikacije gotovo svi se povezuju na Active Directory preko LDAP-a, svaki sa servisnim nalogom čija se lozinka nikada ne menja. U novom videu od tri minuta Mirket Security pokazuje kako se ti nalozi kompromituju i kako ih štiti Mirket NHI – LDAP Proxy. U ovom tekstu sažimamo pristup iz videa i ono što treba znati pre uvođenja.
Zašto su nalozi sa lozinkom koja se nikada ne menja toliko rizični
Među neljudskim identitetima (non-human identity, NHI), LDAP servisni nalozi su najrašireniji i najmanje upravljani. Mirketov pregled rešenja opisuje problem kao pet slojeva koji se nadovezuju jedan na drugi:
- Otvoren tekst: Pri jednostavnom bind-u preko 389/tcp korisničko ime i lozinka putuju mrežom nešifrovani; dovoljno je uhvatiti jedan paket.
- Paraliza rotacije: Ista lozinka stoji u konfiguraciji svakog proizvoda, u rezervnim kopijama, instalacionim dokumentima i tiketima podrške. Promena znači dirati desetine proizvoda, pa se u praksi nikada ne menja.
- Široko pravo čitanja: Podrazumevana dozvola čitanja direktorijuma retko se sužava po proizvodu; svaka integracija može da izlista korisnike, grupe, OU, SPN-ove i lozinke ostavljene u poljima opisa.
- Sam LDAPS nije dovoljan: Neki proizvodi ne podržavaju LDAPS, drugi isključuju proveru sertifikata. Jedan stari proizvod koji ne govori LDAPS blokira uvođenje LDAP potpisivanja i channel binding-a na kontroleru domena.
- Praznina u detekciji: Izviđanje sa važećim servisnim kredencijalom ne proizvodi neuspele prijave i stapa se sa uobičajenim saobraćajem.
Lanac napada kojem nije potrebna ranjivost
Scenario iz videa upečatljiv je po tome što se ni u jednom koraku ne iskorišćava ranjivost. Put napadača izgleda ovako:
- Dolazi do pozicije u mreži sa koje vidi saobraćaj.
- Hvata kredencijal servisnog naloga tokom jednostavnog bind-a.
- Sa njim se povezuje na kontroler domena sa bilo kog mesta.
- Čita gotovo ceo direktorijum.
- Na osnovu prikupljenog priprema ciljani napad eskalacije privilegija.
Pošto servisni nalog nema MFA, a lozinka je godinama ista, uhvaćeni kredencijal postaje ključ koji važi neograničeno.
Gde Mirket NHI LDAP Proxy prekida lanac
Rešenje postavlja jednu tačku prolaza sa primenom politike između proizvoda i kontrolera domena. Ima dve komponente: LDAP Proxy agent, koji završava saobraćaj, primenjuje odluku i beleži bind operacije, i Mirket Portal, koji procenjuje status kredencijala, izvornu IP adresu, DN opseg i MFA. Proxy ne odlučuje sam; odluka dolazi sa Portala.
Virtuelni kredencijali
Svaki proizvod dobija sopstveni virtuelni kredencijal koji prepoznaje samo Mirket i koji nema pandan u Active Directory-ju. Prava AD lozinka nikada ne ulazi u konfiguraciju proizvoda. Tako se zna koji bind dolazi od kog proizvoda, pristup jednog proizvoda može se opozvati bez diranja ostalih, a ukradeni virtuelni kredencijal je beskoristan za Kerberos, SMB ili bilo koji drugi sistem.
Dnevna automatska rotacija lozinke
Pošto pravu lozinku zna samo Mirket, lozinka na strani AD-a može se menjati svakog dana bez diranja ijednog proizvoda. Rotacija koja se godinama odlaže prestaje da bude projekat i postaje rutina u pozadini.
Izvorna IP adresa i DN opseg
Svaki kredencijal prihvata se samo sa definisanih izvornih IP adresa i ograničen je na određeni DN opseg; na primer, VPN proizvod može da pretražuje samo OU u kojem su VPN korisnici. Pretrage van opsega proxy odbija. Ukradeni kredencijal ne može se preneti na drugu mašinu.
Podizanje protokola i ADV190023
Čak i ako proizvod sa proxy-jem govori običan LDAP, proxy se na kontroler domena povezuje preko LDAPS-a ili potpisanog LDAP-a. Deo u kojem saobraćaj ide otvorenim tekstom svodi se na deonicu između proizvoda i proxy-ja, a LDAP potpisivanje i channel binding iz Microsoftove preporuke ADV190023 mogu se uključiti bez diranja starih proizvoda. I sertifikatima se upravlja na jednom mestu.
MFA za stare aplikacije koje govore samo LDAP
Stare aplikacije koje ne podržavaju ni RADIUS, ni SAML, ni OIDC nemaju fazu za drugi faktor. Proxy bind operacije krajnjih korisnika prosleđuje Portalu; na telefon korisnika stiže push obaveštenje, bind se prosleđuje ako je odobren, a blokira ako je odbijen ili ostane bez odgovora. Bind operacije servisnih naloga izuzete su iz ovog koraka i nije potrebna izmena koda aplikacije.
Ugrađeni honeytoken
Pojava virtuelnog kredencijala bilo gde van proxy-ja nema legitimno objašnjenje, pa je Mirket tretira kao signal proboja sa stopom lažno pozitivnih blizu nule. Pokušaj sa izvora van politike se i blokira i prijavljuje kao bezbednosni događaj. Taj signal dopunjuje otkrivanje pretnji po identitet koje se sprovodi uz Mirket ITDR.
Pre i posle
| Tema | Pre proxy-ja | Posle proxy-ja |
|---|---|---|
| Kredencijal u proizvodu | Prava lozinka domena u svakom proizvodu | Samo virtuelni kredencijal |
| Rotacija | U praksi se nikada ne radi | Svakog dana, bez diranja proizvoda |
| Ukradeni kredencijal | Pravi nalog upotrebljiv sa bilo kog mesta | Važi samo sa definisane IP adrese, u opsegu i preko proxy-ja |
| Opseg upita | Gotovo ceo direktorijum | Definisan DN opseg |
| Signal kompromitacije | Ne postoji | Bezbednosni događaj za izvor van politike |
| ADV190023 | Čeka zbog jednog starog proizvoda | Potpisivanje obavezno, a stari proizvod i dalje radi |
| MFA u starim aplikacijama | Nije moguće | Push odobrenje |
| Vidljivost | Rasuta | Centralno beleženje bind operacija po proizvodu |
Šta treba znati pre uvođenja
Pregled rešenja jasno navodi i redosled uvođenja i njegova ograničenja. Pri planiranju se izdvajaju sledeće tačke:
- Prvo inventar: Koji proizvod se odakle i kako povezuje utvrđuje se iz događaja 2886, 2887, 2888 i 2889 na kontroleru domena. Ti događaji ne prikazuju LDAPS i potpisane klijente, pa ih treba dopuniti hvatanjem saobraćaja na nivou mreže.
- Ne zaboraviti Global Catalog: Kontrola mora da obuhvati i portove 3268 i 3269 pored 389 i 636; u suprotnom gubi smisao.
- Pravilo „blokiraj sve osim proxy-ja“ ne može se napisati: Grupne politike, automatski upis sertifikata i upiti između kontrolera zahtevaju LDAP. Blokiranje se ograničava na izvore trećih strana.
- Proizvodi se prebacuju jedan po jedan: Za svaki proizvod kreira se virtuelni kredencijal, adresa LDAP servera usmerava se na proxy i rezultat se proverava. Tek potom se uvode blokada portova i obavezno potpisivanje; automatska rotacija i MFA dolaze na kraju, prvo sa pilot grupom.
- Scenario prekida mora biti zapisan: Proxy radi u režimu aktivan-aktivan, a Portal je redundantan. Da li se zahtevi odbijaju ili važi vremenski ograničena putanja izuzetka kada sloj odlučivanja nije dostupan, određuje se unapred prema sklonosti organizacije ka riziku.
- Potpisivanje nije šifrovanje: Za poverljivost su potrebni LDAPS, StartTLS ili SASL sealing.
Pored ADV190023, Mirket rešenje povezuje sa ISO/IEC 27001:2022, PCI DSS v4 (zahtev 8.6) i članom 32 GDPR-a, ali to mapiranje predstavlja kao orijentaciono i preporučuje da se potvrdi sa timom za usklađenost.
Pogledajte video
Video od oko tri minuta redom prikazuje problem, lanac napada i gore navedene mogućnosti: How to Secure LDAP Service Accounts in Active Directory | Mirket NHI.
Ako želite da zajedno utvrdimo koliko se proizvoda u vašem okruženju povezuje na Active Directory preko LDAP-a i kada su ti nalozi poslednji put menjani, obratite se našem timu za rešenja za sajber bezbednost.