Active Directory Hardening – Deo 1: Osnovna bezbednosna podešavanja

Active Directory je i dalje kičma autentifikacije u velikoj većini organizacija, i upravo zato ostaje najprivlačnija meta napadačima. Kad neko jednom dobije Domain Admin nalog, praktično dobija ceo IT sistem — mailove, fajl servere, baze, pa i mogućnost da preko Group Policy-ja u jednom potezu instalira ransomware na sve mašine u domenu.

Ova serija je zamišljena kao praktičan vodič za sistem inženjere koji svakodnevno održavaju AD, kao i za auditore i sve koji rade proveru bezbednosti IT infrastrukture. Prvi deo pokriva osnove: kako je organizovan privilegovan pristup, koje protokole treba isključiti, i šta konkretno proveriti kad radite bezbednosnu reviziju.

Zašto je AD toliki cilj

Kompromitovan domen znači da napadač može da:

• izvuče celu bazu naloga (NTDS.dit) sa svim heš vrednostima lozinki
• kreira skrivene naloge koji prežive čak i posle čišćenja sistema
• preko Group Policy-ja odjednom distribuira malver na sve računare u domenu
• ugasi bezbednosne alate centralno, za ceo domen

Zbog toga hardening AD-a nije jednokratan projekat, već stalna disciplina — svaka nova mašina, novi servis ili nalog koji se dodaju u domen mogu da otvore novu rupu.

Model nivoa privilegija (tier model)

Osnovni princip modernog pristupa (Microsoft-ov Enterprise Access Model, naslednik starijeg tier modela) jeste da se sve u domenu podeli u tri nivoa prema tome koliku štetu može da napravi ako bude kompromitovano:

Nivo	Šta obuhvata	Posledica kompromitacije
Tier 0	Domain kontroleri, AD CS (interna sertifikaciona tela), sistemi za sinhronizaciju identiteta	Potpuna kompromitacija celog domena
Tier 1	Aplikativni i bazni serveri	Gubitak podataka i servisa na nivou servera
Tier 2	Radne stanice krajnjih korisnika	Kompromitacija pojedinačnog korisnika ili uređaja

Ključno pravilo: nalog sa Tier 0 ovlašćenjima (npr. Domain Admin) nikada ne sme da se prijavljuje na mašinu nižeg nivoa — čak ni na svoj sopstveni laptop radi provere mejla. Razlog je tehnički: kredencijali ostaju u memoriji (LSASS) te mašine, pa ih napadač koji kompromituje taj laptop preko phishing mejla može jednostavno izvući.

Šta treba uraditi

• Administratori moraju imati odvojen nalog za svakodnevni rad (mejl, internet) i poseban, imenovan admin nalog bez mejl sandučeta i bez pristupa internetu
• Za administraciju domain kontrolera koristiti dedikovanu, hardversku radnu stanicu (PAW — Privileged Access Workstation) koja nema pristup internetu niti standardne produktivne aplikacije
• Trajno članstvo u grupama Domain Admins, Enterprise Admins i Schema Admins svesti na apsolutni minimum — u idealnom slučaju nula stalnih članova
• Uvesti privremeno (just-in-time) dodeljivanje privilegovanih prava, sa vremenskim ograničenjem, umesto stalnog članstva u administratorskim grupama
• Redovno (mesečno ili kvartalno) proveravati ko se zaista nalazi u privilegovanim grupama — u praksi se često zadrži nalog bivšeg zaposlenog ili servisni nalog dodat "privremeno" pre više godina

NTLM, LDAP signing i channel binding

Drugi veliki blok hardeninga tiče se protokola za autentifikaciju. NTLM je star protokol sa poznatim slabostima — najozbiljnija je mogućnost NTLM relay napada, gde napadač presretne i preusmeri autentifikacioni zahtev da bi se predstavio kao legitiman korisnik, bez potrebe da ikada sazna njegovu lozinku. Microsoft je zvanično najavio postepeno gašenje NTLM-a, sa punom primenom najavljenom za oktobar 2026, ali realno očekivanje je da će mnoge organizacije taj prelazak završiti tek 2027. i kasnije, zbog starijih aplikacija koje zavise od NTLM-a.

Dok traje taj prelazak, dva konkretna podešavanja bitno smanjuju rizik od relay napada:

• LDAP signing — digitalno potpisivanje LDAP komunikacije, sprečava izmenu poruka u prenosu
• LDAP channel binding — vezuje autentifikacioni zahtev za konkretnu TLS sesiju, tako da presretnut zahtev ne može biti iskorišćen na drugoj konekciji

Podrazumevano, mnogi domain kontroleri i dalje imaju channel binding podešen na "Never", što znači da zaštita uopšte nije aktivna. Preporuka je da se ovo podesi na "Always", ali pre toga obavezno uraditi period auditinga (dijagnostičko logovanje) da se vidi koji klijenti eventualno ne podržavaju channel binding, kako promena ne bi prekinula postojeće servise.

Šta treba uraditi

• Uključiti auditing NTLM autentifikacije u domenu (GPO: Network security — Restrict NTLM — Audit NTLM authentication) i pratiti logove pre nego što se NTLM počne blokirati
• Postaviti LDAP server signing requirements na "Require signing"
• Postaviti LDAP server channel binding token requirements na "Always", nakon perioda auditinga (događaji 3039/3074/3075 u Event Vieweru pokazuju koji klijenti nisu spremni)
• Uključiti SMB signing na domain kontrolerima i kritičnim serverima
• Isključiti WebClient (WebDAV) servis na domain kontrolerima ako nije neophodan — to zatvara jedan od poznatih vektora za prisilnu (coerced) NTLM autentifikaciju
• Segmentisati mrežni pristup ka AD CS (internim sertifikacionim telima) — dostupnost samo sa upravljačke mreže, ne sa cele korisničke mreže

Napomena o riziku: prelazak sa "Audit" na "Deny" režim za NTLM (Restrict NTLM authentication), kao i postavljanje LDAP signing zahteva na "Require signing", mogu prekinuti rad starijih aplikacija, mrežnih uređaja ili servisa koji i dalje zavise od NTLM-a ili nepotpisane LDAP komunikacije. Isto važi za isključivanje WebClient (WebDAV) servisa, ako neka interna aplikacija na njega ipak oslanja. Ni jedno od ovih podešavanja ne treba uključivati direktno u produkciji — obavezno prvo proći kroz period auditinga i pregledati logove pre prelaska na režim koji odbija ili blokira konekcije.

Servisni nalozi i lozinke

Servisni nalozi su čest slabija karika — često imaju lozinku koja se nikad ne menja, a nerealno visoka ovlašćenja "da ne bi bilo problema". Tamo gde je tehnički moguće, servisne naloge treba zameniti sa gMSA (Group Managed Service Account) nalozima, koji imaju automatski generisanu, dugu i redovno rotiranu lozinku bez potrebe da je iko ručno pamti ili menja.

Za lokalne administratorske naloge na radnim stanicama i serverima, rešenje je LAPS (Local Administrator Password Solution) — svaki uređaj dobija jedinstvenu, redovno rotiranu lokalnu admin lozinku, umesto iste lozinke na svim mašinama u domenu, što je i dalje iznenađujuće čest nalaz na tehničkim proverama.

Šta treba uraditi

• Popisati sve servisne naloge i njihova stvarna ovlašćenja — u praksi se često nađe servisni nalog član Domain Admins grupe "iz istorijskih razloga"
• Gde god je moguće, migrirati servisne naloge na gMSA
• Uvesti LAPS za sve lokalne administratorske naloge na serverima i radnim stanicama
• Proveriti stare, neaktivne naloge (korisničke i računarske) koji nisu korišćeni 30, 60 ili 90 dana — prvo ih onemogućiti, pa tek posle potvrde da nisu potrebni, obrisati

U sledećem delu serije prelazimo na konkretnu proveru Group Policy podešavanja i na deo koji se najčešće zaboravlja — delegiranje ovlašćenja unutar Active Directory strukture (OU delegation), gde se vremenom nakupi mnoštvo prava koja niko više ne prati.