Securitate

Securitate 101 Solutii

Cum se colectează date din registrul Windows folosind Intune

Această funcționalitate a fost anunțată pentru prima dată odată cu lansarea din iulie (2607) a Microsoft Intune, permițând administratorilor să colecteze date din registru fără a mai fi nevoie de scripturi PowerShell personalizate, colectarea datelor realizându-se prin intermediul Microsoft Device Inventory Agent.

Cu ajutorul acestei noi funcționalități, administratorii IT pot colecta în mod nativ date selectate din registrul HKEY_LOCAL_MACHINE și le pot vizualiza pentru fiecare dispozitiv în inventarul dispozitivelor. Astfel, puteți verifica dacă valorile așteptate din registru există după implementarea politicii. Este o funcționalitate foarte utilă și cred că va fi una dintre cele mai populare funcții din Microsoft Intune. Colectarea datelor din registru de către Intune în inventarul dispozitivelor este inclusă în Microsoft Intune Plan 1.

Nota Bene: La lansarea inițială, datele din registru apar în inventarul dispozitivelor pentru fiecare dispozitiv în parte. Aceasta înseamnă că va trebui să vizualizați datele inventariate accesând fiecare dispozitiv în parte. Microsoft a indicat, de asemenea, că se așteaptă ca experiențele de raportare și explorare mai ample să se extindă în timp.

[mai mult...]

Personalizarea numelui folderului root de sincronizare OneDrive folosind Intune

În mod implicit, numele folderului vizibil pentru utilizator este „OneDrive – {numele organizației}”. Scurtarea acestui nume mărește lungimea disponibilă a căii pentru folderele și fișierele imbricate și asigură coerența mărcii pe toate dispozitivele gestionate.
Când utilizatorii sincronizează OneDrive pe Windows, numele implicit al folderului apare de obicei ca „OneDrive – {numele organizației}”. Acest lucru funcționează bine în multe medii, dar uneori organizațiile doresc un format de denumire mai clar și mai ușor de recunoscut, din motive de branding, consecvență sau simplitate a asistenței. Aici intervine Intune, ajutându-vă să configurați un nume unic al organizației afișat de OneDrive utilizatorilor.

Rețineți că, atunci când aplicați această configurație prin Intune, aceasta modifică, practic, numele afișat pentru folderul rădăcină OneDrive sincronizat în File Explorer. Aceasta nu afectează folderele OneDrive ale conturilor personale Microsoft.

Nota Bene: Nu este necesar să importați fișierele șablon ADMX pentru OneDrive, deoarece cele mai recente setări pentru OneDrive sunt deja incluse în catalogul de setări. Importul este necesar doar dacă nu puteți găsi o politică specifică pe care o căutați.

De ce să setați un nume personalizat pentru folderul OneDrive?

Din câte cunoastem, pentru majoritatea utilizatorilor, numele folderelor reprezintă un detaliu minor și nimeni nu le acordă atenție în timpul activității. Pentru echipele IT, acestea fac adesea diferența între „totul pare standardizat” și „de ce fiecare captură de ecran de la departamentul de asistență arată diferit?”. O mică ajustare, dar una care conferă implementărilor la nivel de întreprindere un aspect mai bine gândit.

Dacă conduceți o organizație, iată câteva motive pentru care ar trebui să le sugerați utilizatorilor OneDrive să ia în considerare schimbarea numelui vechi al directorului rădăcină de sincronizare.

  • Menținerea consecvenței mărcii pe toate dispozitivele gestionate.
  • O experiență de utilizare mai simplă, cu un nume de folder mai prietenos.
  • Documentație de asistență și capturi de ecran mai ușor de realizat.
  • O distincție clară atunci când utilizatorii lucrează cu mai mulți chiriași sau biblioteci sincronizate.

Ce politică Intune controlează acest aspect?

Microsoft Intune oferă o setare administrativă cunoscută sub numele de „Setare nume personalizat pentru folderul OneDrive”, care vă permite să definiți numele de afișare al organizației care apare în folderul OneDrive local. De obicei, aceasta se configurează prin politica Catalog de setări.

Conform descrierii politicii, dacă activați această setare și furnizați un nume personalizat pentru folder, OneDrive va utiliza acel nume la crearea folderului rădăcină de sincronizare pentru utilizatorii noi. Dacă nu configurați această setare, se va utiliza numele implicit al folderului. Când dezactivați această setare, numele folderului va reveni la „OneDrive – {numele organizației}“.

Utilizatorii existenți care au un nume de folder personalizat trebuie să-și deconecteze și să-și reconecteze contul pentru ca modificările să intre în vigoare, aceasta fiind o cerință a aplicației OneDrive, nu a politicii.

Cerințe preliminare

  1. Înregistrare: Asigurați-vă că dispozitivele Windows sunt înregistrate în Intune. Consultați ghidul de înregistrare Windows 11 în Intune. Utilizatorii trebuie să se autentifice cu un cont de serviciu sau școlar.
  2. Permisiuni: Cont de utilizator care face parte din rolul încorporat „Global Admin” sau „Policy and Profile Manager” din Microsoft Intune.
  3. ID-ul tenantului: Politica pe care o vom configura necesită introducerea ID-ului tenantului. Prin urmare, aceasta este o cerință prealabilă importantă, iar în secțiunea următoare voi arăta unde se poate vedea ID-ul tenantului.
  4. Aplicația OneDrive: Aplicația OneDrive trebuie să fie instalată pe dispozitivele finale pe care intenționați să implementați politica. De asemenea, asigurați-vă că aplicația OneDrive este actualizată la cea mai recentă versiune.

Reguli și restricții privind denumirea

Înainte de a configura politica în cadrul organizației dvs., asigurați-vă că cunoașteți regulile de denumire pentru folderul rădăcină OneDrive și limitările aferente.

  • Trebuie să introduceți cel puțin un caracter pentru numele folderului personalizat.
  • Alegeți un nume care să corespundă identității companiei dvs. și, pe cât posibil, alegeți unul scurt.
  • Calea completă a folderului rădăcină de sincronizare OneDrive (de exemplu, C:\Users{alias}\OneDrive – {numele organizației}) nu poate depăși 120 de caractere.
  • Numele folderelor personalizate nu pot conține caractere nevalide pentru folderele Windows.
  • Cel mai important, numele folderului personalizat nu poate fi „OneDrive”. Va apărea un conflict, iar politica ar putea să nu se aplice în cele din urmă.
  • De asemenea, nu sunt permise spațiile la începutul și la sfârșitul numelor de fișiere sau de foldere.

Găsiți ID-ul de tenant Microsoft Entra

Există mai multe modalități de a găsi ID-ul de tenant Microsoft Entra, iar cea mai simplă este să îl obțineți din Centrul de administrare Entra ID.

  • Conectați-vă la Centrul de administrare Microsoft Entra.
  • Accesați Entra ID > Overview.
  • În secțiunea Basic Information, puteți găsi ID-ul de tenant.
  • Copiați ID-ul de tenant în Notepad sau în orice editor de text; se va folosi în timpul configurării politicii.
[mai mult...]

Actualizarea cumulativa din septembrie 2026 impacteaza RDS

Windows Update are obiceiul de a provoca probleme, iar de data aceasta este vorba despre Remote Desktop Services = Serviciul de desktop la distanță. Gazdele de sesiune funcționează fără probleme câteva ore după repornire, dar apoi conexiunile rămân blocate la „Connecting…”, utilizatorii nu se pot deconecta, iar în cele din urmă singura soluție este o resetare forțată.

Revenirea la versiunea anterioară a actualizării este adesea cea mai simplă soluție, dar versiunea lansată luna Septembrie 2026 remediază vulnerabilitatea CVE-2026-69525, o vulnerabilitate critică de tip RCE = de execuție a codului la distanță pentru Serviciile de desktop remote, cu un scor CVSS de 9,8, plus două vulnerabilități de tip zero-day care sunt deja exploatate activ. Așadar, revenirea la versiunea anterioară s-ar putea să nu fie cea mai bună opțiune.

Ce se întâmplă

Mai mulți administratori au descris același tipar de eroare si anume ca gazdele sesiunilor RDS funcționează normal după o repornire, apoi se blochează câteva ore mai târziu, când utilizatorii încep să se deconecteze.

Odată ce problema apare, noile conexiuni RDP rămân blocate la „Connecting…” și nu ajung niciodată la ecranul de autentificare. Sesiunile existente nu se pot deconecta corect. Task Manager, Setări și majoritatea instrumentelor care interacționează cu starea sesiunii intră în blocaj, deoarece nu pot obține un răspuns de la Local Session Manager (LSM). Chiar și o repornire normală se blochează. Numai o resetare forțată restabilește funcționarea gazdei.

Problema pare să fie legată de o rutină numită RDPSERVERBASE!WDLIB_Close, care este apelată în timpul închiderii sesiunii. Atunci când un anumit indicator de funcționalitate intern(3802373433) este activ, această rutină apelează funcția RtlWaitOnAddress fără limită de timp, ceea ce determină firul de execuție să aștepte pe termen nelimitat.

Deoarece LSM serializează modificările stării sesiunii printr-o singură secțiune critică, acel thread blocat blochează tot ce se află în aval de el = conexiuni noi, deconectări și solicitări către broker, până când host-ul este resetat forțat.

Acestea sunt semnăturile si avertismentele din jurnalul de evenimente care indică această eroare specifică:

  • Eveniment 20498 din TerminalServices-RemoteConnectionManager: „Remote Desktop Services has taken too long to complete the client connection”
  • Eveniment 6005 din Winlogon: „The winlogon notification subscriber SessionEnv is taking long time to handle the notification event (Disconnect)”
  • Starea TermService: StopPending în loc de Running

Problema afectează toate versiunile actuale de Windows Server prin intermediul actualizărilor cumulative din septembrie 2026.

De ce revenirea la o versiune anterioară este o soluție de ultimă instanță

Aceeași actualizare care a provocat defecțiuni la RDS a remediat și vulnerabilitatea CVE-2026-69525, o vulnerabilitate critică de execuție a codului la distanță în Serviciile de desktop la distanță, cu un scor CVSS de 9,8. Versiunea din septembrie a remediat, de asemenea, vulnerabilitățile CVE-2026-81963(Windows Update) și CVE-2026-85880 (Windows Advanced Local Procedure Call), ambele fiind vulnerabilități de tip „zero-day” deja exploatate activ și incluse în catalogul CISA al vulnerabilităților cunoscute ca fiind exploatate.

Dacă serverele RDS sunt utilizate doar intern și nu sunt expuse la internet, riscul este mai mic, iar revenirea la versiunea anterioară ar putea fi cea mai simplă opțiune. Însă, dacă serverul RDS este accesibil de pe internet, revenirea la versiunea anterioară ar trebui să fie ultima soluție.

[mai mult...]

Detecție phishing cu RAG local – reducere fals-pozitive prin bază de cunoștințe cu campanii cunoscute

Detecția de phishing cu un LLM simplu (prompt direct către model) funcționează, dar generează fals-pozitive: emailuri legitime cu ton urgent sunt marcate greșit ca phishing, iar modelul nu are context despre campaniile specifice care vizează organizația.

Această soluție adaugă un strat RAG peste detecția existentă: o bază de cunoștințe locală cu exemple de phishing confirmate, emailuri legitime cunoscute (newsletter-e interne, notificări de sistem) și politici interne. Modelul compară emailul suspect cu exemplele similare înainte de a da verdictul — rezultat: mai puține alarme false și motivare explicită bazată pe cazuri concrete.

[mai mult...]

Raport zilnic automat de sănătate a serverelor generat cu AI – interpretare Event Log și trimitere pe email

Verificarea zilnică a Event Viewer pe mai multe servere este consumatoare de timp, iar codurile de eroare Windows sunt greu de interpretat rapid. Multe probleme sunt observate abia după ce devin incidente.

Această soluție colectează evenimentele critice și de eroare din ultimele 24 de ore de pe mai multe servere, le trimite unui model AI local care le explică în limbaj uman (ce înseamnă eroarea, ce ar trebui verificat, cât de urgentă e), grupează problemele similare și trimite un raport HTML pe email — automat, în fiecare dimineață.

[mai mult...]