În acest articol, mă voi concentra asupra principiilor de bază și arhitecturii DRS. Detalii despre setări pot fi găsite în cel de-al patrulea modul al cursului "Dispozitive pentru întreprinderi. Cum să gestionați acreditările hibride. "
Care este principala problemă?
Într-o rețea de domenii, este ușor să eviți astfel de situații prin intermediul politicilor de grup. Începând cu parola pentru conectarea la dispozitivul de domeniu, terminând cu certificate pentru autentificare la accesarea aplicației. Cum rămâne cu dispozitivele care nu pot fi incluse în domeniu? Abordările pot fi diferite: puteți configura utilizarea obligatorie a unei parole sau a unui cod PIN pentru a vă conecta la dispozitiv, puteți genera și instala un certificat pe tabletă. Numai pentru diferite platforme, aceste proceduri diferă, trebuie să fie realizate manual și sigur de personalul IT, iar fiecare dispozitiv nou generează un lanț de acțiuni corespunzător. Și vreau să pot face față acestei sarcini proprietarului dispozitivului și apoi, când va avea nevoie de el.
Care este ideea principală?
După cum indică numele serviciului, DRS implementează procedura de înregistrare a dispozitivului. În timpul procesului de înregistrare, DRS generează un certificat X.509 care este descărcat pe dispozitiv și creează un obiect nou în Active Directory care conține informații despre dispozitiv și despre utilizatorul care a efectuat înregistrarea.
De fiecare dată când un utilizator se conectează de dispozitivul înregistrat la aplicație, utilizatorul este autentificat (fie introduce o parolă, fie utilizează un modul cookie), iar certificatul este verificat. Și numai dacă ambele verificări sunt finalizate cu succes, utilizatorul primește acces la aplicație. De fapt, avem de-a face cu autentificare cu doi factori.
Dar este important să observăm câteva aspecte:
- Procedura de înregistrare este cât mai simplă posibil și nu necesită o configurație inițială a dispozitivului de către un profesionist IT.
- DRS suportă diferite platforme:
- Windows 8.1 și versiuni ulterioare
- iOS 6 și de mai sus
- Android - Samsung KNOX
- Windows 7 Pro (inclus în domeniu)
- DRS nu necesită implementarea PKI
Cum arata?
Procesul de înregistrare a dispozitivului este prezentat în figura următoare.
Deci, angajatul companiei este în afara companiei și în browserul tabletei, care nu este inclus în domeniu, formează adresa URL a portalului corporate SharePoint. Solicitarea prin WAP este redirecționată de către ADFS și vedem o astfel de imagine.
După cum puteți vedea, elementele paginii de autentificare ADFS, precum și paginile mesajului de eroare (imagine, logo, texte de mesaje) sunt configurate. Utilizatorul specifică datele de conectare și parola contului său de domeniu, iar datele de conectare sunt introduse în formatul Nume utilizator principal (UPN). Deoarece dispozitivul nu este înregistrat încă, accesul este refuzat.
Faceți clic pe butonul Alăturați. consultați fereastra deja cunoscută a autentificării ADFS.
Dacă parola este introdusă corect, dispozitivul este înregistrat și revenim la fereastra anterioară, unde puteți vedea că operația Workplacejoin este finalizată.
Ce se întâmplă în spatele scenei? Pe tableta însăși, cu modulul de completare Certificări, puteți descoperi apariția unui nou certificat.
Acesta va fi folosit acum ca al doilea factor de autentificare la conectarea la aplicație.
În Active Directory, obiectul de potrivire a certificatului poate fi găsit în noul container RegisteredDevices. Numele obiectului este același cu certificatul CN. Atributele acestui obiect pot fi văzute, de exemplu, utilizând ADSI Edit.
Printre atributele vom găsi numele dispozitivului, tipul și versiunea sistemului de operare, SID-ul utilizatorului care a efectuat înregistrarea, data și ora înregistrării,
Încercăm din nou să ne conectăm la portal, revenim din nou pe pagina ADFS, reintroducem acreditările contului AD. Dar acum, în afară de verificarea parolei, certificatul este, de asemenea, finalizat cu succes, iar accesul la aplicație a fost primit.
Mai mult, după prima conexiune de succes, utilizatorul primește un SSO pentru această aplicație. Se poate închide browserul, se repornește aparatul, se deschide din nou browserul, se introduce URL-ul și ... se accesează aplicația fără alte întrebări. Într-adevăr, modulele cookie furnizează primul factor de autentificare, certificatul - al doilea. Firește, nu pentru totdeauna, iar periodic utilizatorul va trebui să-și confirme autenticitatea introducând o parolă. Dar acest termen este controlat de IT.
Considerații suplimentare privind securitatea
Să revenim la situația cu pierderea / furtul tabletei. Dacă dispozitivul este deja înregistrat, aplicația este implementată SSO, iar dispozitivul a căzut în mâinile greșite. Prima linie de protecție este parola sau codul PIN pentru a intra în dispozitiv. Pentru dispozitivele non-temporare, puteți activa blocarea obligatorie, de exemplu, prin Microsoft Intune sau o altă soluție MDM. Dacă nu sa făcut asta? Se pare că am dat atacatorului cărți de atu suplimentare - trebuie doar să deschidă browserul și să introducă URL-ul. Evident, în această situație, proprietarul ar trebui să notifice serviciul IT cât mai curând posibil. Ce va face atunci? Să ne uităm la mai multe opțiuni.
Dacă serviciul de înregistrare a dispozitivului nu este utilizat deloc.
Ambele soluții, precum și alte opțiuni care pot fi propuse, sunt destul de aplicabile, dar nu sunt ideale.
Dacă dispozitivul a fost înregistrat.
Administratorul este suficient să găsească în AD obiectul asociat cu dispozitivul pierdut și fie să șterge obiectul, fie să stabilească valoarea lui pentru atributul msDS-IsEnabled la FALSE.
Apoi, când vă conectați la aplicație, certificatul dispozitivului nu va trece testul și utilizatorul va primi un mesaj de eroare. Astfel, blocăm accesul la un anumit dispozitiv.
Dar acesta este subiectul unei conversații separate.
Detalii privind instalarea și configurarea ADFS și DRS pot fi găsite, de exemplu aici:
Personalizarea setărilor pentru dispozitivele iOS, crearea politicilor de acces condiționat, implementarea WAP etc.: