Configurați pentru aplicațiile Web este necesară autentificarea clasică a Windows utilizând protocolul Kerberos, astfel încât script-urile să funcționeze conform așteptărilor. În anumite scenarii, puteți utiliza verificarea bazată pe revendicări Windows, dar în acest caz rezultatele pot să nu corespundă celor descrise în scenariile următoare.
În acest scenariu, se efectuează următoarele acțiuni:
Configurați două aplicații Web cu zone implicite care utilizează Kerberos pentru autentificare
Creați două colecții de site-uri de testare, câte una în fiecare aplicație Web
Verificarea configurației IIS pentru o aplicație web
Verificați dacă aplicația Web poate efectua autentificarea clientului și poate folosi protocolul Kerberos pentru aceasta
Omiterea fiecărei aplicații Web și verificarea căutării conținutului în fiecare colecție de site-uri de testare
Creați conturi de servicii pentru aplicația Web IIS pentru aplicații IIS
Înregistrați numele principalelor servicii pentru aplicațiile Web din contul de serviciu creat pentru grupul de aplicații Web IIS
Configurați delegarea restricționată de Kerberos pentru conturile de servicii
Creați conturi SharePoint Server gestionate
Creați o aplicație de servicii de căutare SharePoint
Creați aplicații Web SharePoint
Verificați dacă autentificarea Kerberos este activată
Verificați dacă autentificarea cu kernel-mode este dezactivată
Instalați certificate pentru SSL
Client de Windows 7
Deschideți porturile de firewall pentru a permite traficului HTTP să treacă prin porturile implicite și prin porturi care nu sunt porturile implicite
Asigurați-vă că clienții se pot conecta la porturile Kerberos din Active Directory
Verificați autentificarea pentru browser
Verificați dacă autentificarea funcționează corect în browser
Verificați informațiile de conectare din jurnalul de evenimente de securitate al serverului Web
Folosind instrumentele terță parte, verificați dacă autentificarea Kerberos este configurată corect
Verificați cererile de index și de căutare pentru serverul SharePoint
Verificați disponibilitatea browserului de la serverele index
Treceți conținutul eșantionului și ocoliți-l
Pentru fiecare cont de serviciu, configurați setul de nume principale de servicii care sunt mapate la numele gazdă DNS alocate fiecărei aplicații Web.
Toate aplicațiile Web SharePoint Server, indiferent de numărul portului, utilizează următorul format de gazdă a serviciului:
HTTP /<имя узла DNS>
HTTP /<Полное доменное DNS-имя>
Pentru aplicațiile web care funcționează prin porturi non-standard (altele decât 80/443), înregistrați numele principalelor servicii principale cu numărul portului:
HTTP /<имя узла DNS>:<порт>
HTTP /<Полное доменное DNS-имя>:<порт>
Consultați anexa pentru a explica recomandările pentru configurarea denumirilor principale ale serviciului cu și fără număr de port pentru serviciile HTTP care nu funcționează prin porturile implicite (80, 443). Un mod corect din punct de vedere tehnic de a face trimitere la un serviciu HTTP care funcționează prin porturi non-standard este să adăugați un număr de port la numele principalului serviciu, dar din cauza problemelor cunoscute descrise în aplicație, trebuie să configurați numele membrilor serviciului și fără port. Rețineți că în exemplul nostru, numele membrilor serviciului fără a specifica portul pentru aplicația web a echipelor nu implică posibilitatea accesării serviciilor prin porturile implicite (80, 443).
În exemplul nostru, următoarele nume de servicii sunt configurate pentru cele două conturi create în etapa anterioară:
Următoarea diagramă arată în mod concret ce va fi configurat în acest scenariu:
Pentru a face acest lucru, veți configura o delegație limitată Kerberos care permite delegarea între conturile contului de fonduri IIS. Următoarea diagramă descrie, în principiu, căile necesare de delegare limitată.
Rețineți că aplicația Web este definită de numele serviciului utilizând numele principal al serviciului care este atribuit identității fondului de aplicații IIS. Conturile de servicii care procesează cererile trebuie să aibă permisiunea de a delega identitatea clientului către serviciile desemnate. În consecință, vor fi stabilite următoarele modalități de delegare limitată:
Pentru a configura delegarea, puteți utiliza modulul Active Directory Users and Computers. Faceți clic cu butonul din dreapta pe fiecare cont de serviciu și deschideți caseta de dialog pentru proprietăți. Această casetă de dialog afișează o filă pentru delegare (rețineți că această filă apare numai dacă obiectului i se atribuie un nume principal al serviciului, calculatoarele au numele principal al serviciului implicit). În fila delegare, selectați Încredere în acest utilizator pentru a delega serviciile specificate. apoi selectați Utilizați orice protocol de autentificare.
Faceți clic pe butonul Adăugați. Pentru a adăuga servicii care vor fi delegate utilizatorului (cont de serviciu). Pentru a selecta numele principal al serviciului, găsiți obiectul la care se referă numele principal al serviciului. În cazul nostru, se face o încercare de a delega serviciul HTTP, ceea ce înseamnă că efectuați o căutare pentru contul serviciului de bazin de servicii IIS, la care a fost atribuit numele principal al serviciului în pasul anterior.
În caseta de dialog Selectați utilizatori sau computere, faceți clic pe Utilizatori și computere. găsiți conturile serviciului bazin de servicii IIS (în exemplul nostru, vmlab \ svcPortal10App și vmlab \ svcTeams10App), apoi faceți clic pe OK.
Vi se va solicita să selectați serviciile atribuite obiectelor prin numele principal al serviciului.
Efectuați acești pași pentru fiecare cont de serviciu din mediul pentru care doriți să îl delegați. În exemplul nostru, aceasta este o listă de conturi de servicii
Înainte de a crea aplicațiile Web, configurați conturile de servicii create în pașii anteriori ca conturi gestionate în serverul SharePoint. Implementarea timpurie a acestei acțiuni vă va permite să o ignorați atunci când creați propriile aplicații web.
Pași pentru a configura un cont gestionatÎn Administrația centrală, faceți clic pe Securitate.
Sub Securitate generală, faceți clic pe Setări cont gestionate.
Faceți clic pe Înregistrați o intrare gestionată și creați un cont gestionat pentru fiecare cont de servicii. În acest exemplu, am creat cinci conturi de servicii gestionate:
Nume: SharePoint - Echipe5555
Când creați o nouă aplicație Web, creați de asemenea o zonă nouă, zona implicită care este configurată pentru a fi utilizată de furnizorul de autentificare Windows. Furnizorul și setările acestuia pentru zonă pot fi văzute la rularea aplicației Web, mai întâi selectând o aplicație Web, apoi făcând clic pe Furnizori de autentificare din bara de instrumente. Caseta de dialog Provider de autentificare afișează toate zonele pentru aplicația web selectată, împreună cu furnizorul de autentificare pentru fiecare zonă. După selectarea zonei, apar setările de autentificare pentru această zonă.
Dacă setările Windows sunt configurate incorect și NTLM este selectat incorect când creați aplicația Web, puteți utiliza caseta de dialog pentru editarea autentificării pentru zona pentru a comuta valoarea din zona de la "NTLM" la "Reconciliere". Dacă modul clasic nu a fost selectat ca mod de autentificare. trebuie să creați o zonă nouă prin extinderea aplicației Web pe noul site Web IIS sau să ștergeți și să re-creați aplicația Web.
Pentru acest exemplu, au fost configurate două seturi de site-uri web:
Calea de colectare a site-ului
Aplicația Web portal va fi configurată să utilizeze HTTPS, precum și HTTP, pentru a demonstra funcționarea delegării cu servicii SSL securizate. Pentru a configura SSL, aplicația Web portal va avea nevoie de oa doua mapare pentru acces alternativ la SharePoint Server (AAM) pentru punctul final HTTPS.
Acțiuni pentru configurarea mapărilor pentru accesul alternativÎn Administrația Centrală, faceți clic pe Managementul aplicațiilor.
În aplicația Web, faceți clic pe Configurați mapările pentru accesul alternativ.
În lista Selectați alternativ harta mapări, selectați Modificați setul de mapări de acces alternativ.
Selectați aplicația Web portal.
Faceți clic pe butonul Salvați.
Înainte de a testa autentificarea, asigurați-vă că clienții pot accesa aplicațiile Web SharePoint Server folosind porturile HTTP configurate. În plus, asigurați-vă că clienții se pot autentifica în Active Directory și pot solicita bilete Kerberos de la KDC prin porturile standard Kerberos.
În mod tipic, pentru a permite ca cererile să fie primite prin porturile TCP 80 și TCP 443, trebuie să configurați paravanul de protecție pe fiecare server Web frontal. Deschideți paravanul de protecție Windows cu securitate avansată și treceți la următoarele reguli pentru conexiunile de intrare:
Servicii Internet (trafic HTTP de intrare)
Servicii Internet (trafic HTTPS primit)
Verificați dacă porturile corespunzătoare sunt deschise în mediul dvs. În exemplul nostru, HTTP (portul 80) este utilizat pentru a accesa serverul SharePoint, deci această regulă a fost activată.
În plus, trebuie să deschideți un port care nu este portul implicit, dar folosit în exemplul nostru (TCP 5555). Dacă site-urile web funcționează prin porturi non-standard, va trebui, de asemenea, să permiteți traficul HTTP prin aceste porturi.
Centrul de distribuire a cheilor Kerberos - PCR (TCP-in)
Centrul de distribuire chei Kerberos - PCR (intrare UDP)
Centrul de distribuire a cheilor Kerberos (TCP Inbound)
Centrul de distribuire a cheilor Kerberos (intrare UDP)
Verificați dacă aceste reguli sunt activate în mediul în curs de utilizare și că clienții se pot conecta la KDC (controller-ul de domeniu) utilizând portul 88.
Acum, după ce ați configurat Active Directory, DNS și SharePoint Server, puteți testa configurarea corectă a autentificării Kerberos accesând aplicațiile web. Când testați în browser, asigurați-vă că sunt adevărate următoarele condiții:
Utilizatorul de test conectat la computerul Windows XP, Vista sau Windows 7 care este conectat la domeniul în care este instalat SharePoint Server sau a introdus un domeniu care este de încredere pentru domeniul SharePoint Server.
Browserul include autentificare Windows încorporată. În fila Complex, în fereastra Opțiuni Internet, asigurați-vă că este bifată caseta de selectare Enable Integrated Windows Authentication din secțiunea "Security":
Puteți configura datele de conectare automate pentru alte zone, dar subiectul recomandărilor pentru zonele de securitate IE este în afara domeniului de aplicare al acestui articol. În această demonstrație, zona intranet va fi utilizată pentru toate testele.
Asigurați-vă că caseta de lângă pentru a detecta automat rețeaua intranet stabilite în Opțiuni alineatul Internet -> Securitate -> Intranet local -> Site-uri.
Dacă utilizați un nume de domeniu complet calificat pentru a accesa aplicațiile Web SharePoint Server, asigurați-vă că numele completă a domeniilor sunt incluse în zona intranetului sau specificați explicit includerea utilizând un wildcard (de exemplu "* .vmlab.local").
Cea mai ușoară modalitate de a stabili dacă este utilizată autentificarea Kerberos este să introduceți stația de lucru pentru testare și să accesați site-ul de interes. Dacă utilizatorul nu este chemat să introducă acreditările și site-ul este afișat corect, puteți presupune că funcționează autentificarea integrată Windows. Următorul pas este să determinați dacă protocolul de negociere a fost utilizat pentru a negocia autentificarea Kerberos ca furnizor de autentificare pentru solicitare. Pentru a face acest lucru, puteți utiliza următoarele metode.
Dacă autentificarea Kerberos funcționează corect, jurnalele de evenimente de securitate de pe serverele Web front-end vor conține evenimente de conectare cu identificatorul ID eveniment = 4624. În informațiile generale pentru aceste evenimente trebuie să fie afișat identificatorul de securitate înregistrat pe un computer și folosit procesul de conectare, care trebuie să fie un proces Kerberos.
Dacă trebuie să ștergeți memoria cache a biletului, rulați Klist cu opțiunea de purjare opțională. Renunțarea la Klist
Navigați pe site-urile web care utilizează autentificarea Kerberos.
Asigurați-vă că biletele pentru aplicațiile Web care sunt autentificate se află în lista de bilete cache. În exemplul nostru, mergem la următoarele site-uri web, cu următorii membri înregistrați ai serviciului:
Ieșiți din spațiul de lucru și log înapoi pentru a șterge toate conexiunile din cache la serverul de web și browser-ul pentru a negocia autentificarea Kerberos și autentificarea.
Fiddler ar trebui să fie solicitat pentru serverul Web front-end SharePoint Server și răspunsurile sale.
Primul HTTP 401 este o încercare a browserului de a efectua o solicitare GET fără autentificare. Ca răspuns, serverul trimite înapoi "HTTP 401 - neautorizat", indicând în acest răspuns ce metode de autentificare suportă. În următoarea solicitare, clientul repetă trimiterea cererii anterioare, dar de această dată un bilet pentru aplicația web este trimis în antetele de cerere. Dacă autentificarea are succes, serverul trimite înapoi resursa solicitată.
NetMon vă permite să vedeți întreaga cerere și răspuns schimburile cu KDC TCP și servere Web SharePoint Server, creând o imagine completă a traficului, formând autentificarea completă cerere. Pentru a testa funcționarea autentificării Kerberos cu netmon, urmați acești pași:
Deconectați-vă de la sistemul client și reveniți pentru a șterge cache-ul de bilete Kerberos. În plus, puteți utiliza KerbTray, pentru a goli cache-ul de bilete, de KerbTray Purge Bilete pictograma și alegând clic dreapta (bilete clar).
Porniți NetMon în modul Administrator. Faceți clic dreapta pe scurtătura NetMon și selectați Run as administrator.
Începeți o captură nouă a interfețelor care se conectează la controlerul Active Directory al mediului dvs. și serverele Web frontal.
Deschideți Internet Explorer și accesați aplicația web.
După afișarea site-ului web, opriți capturarea și adăugați un filtru de afișare pentru a afișa cadre pentru autentificarea Kerberos și traficul HTTP.
Fereastra cadru trebuie să conțină atât traficul HTTP, cât și traficul KerberosV5.
Pentru a afișa în mod clar numele solicitanților de servicii solicitați când clientul accesează o resursă protejată de SSL, puteți utiliza un instrument precum netmon care captează traficul între client și server și verificați solicitările de bilete Kerberos.
Deconectați-vă și apoi conectați-vă la computerul client sau ștergeți toate biletele Kerberos cache utilizând KerbTray.
Porniți o nouă captură NetMon pe computerul client. Nu uitați să rulați NetMon cu privilegii de administrator.
Opriți captura NetMon și verificați traficul KerberosV5. Pentru instrucțiuni privind filtrarea afișajului de captare, consultați NetMon 3.4 din acest articol.
Găsiți cererea TGS trimisă de client. Cererea ar trebui să prezinte numele membrului de serviciu solicitat în parametrul "Sname".
Rețineți că "Sname" este HTTP / portal.vmlab.local, nu HTTPS / portal.vmlab.local.
Înainte de a rula accesarea cu crawlere, asigurați-vă că serverul index are acces la aplicațiile Web și că se autentifică cu succes. Conectați-vă la serverul index și deschideți colecțiile site-ului de testare din browser. Dacă site-urile sunt afișate cu succes și nu apar dialoguri de autentificare, continuați cu pasul următor. În cazul în care accesul la site-ul într-un browser, există probleme, du-te înapoi la pașii anteriori pentru a supraveghea toate acțiunile de configurare.
În fiecare colecție de site-uri, treceți un document "semințe" (ușor de identificat la căutare) în biblioteca de documente de colectare a site-urilor. De exemplu, creați un document text care conține cuvintele "alfa, beta, delta" și salvați-l în biblioteca de documente a fiecărei colecții de site-uri.
Apoi, mergeți la Administrația centrală SharePoint și executați o crawl completă pentru sursa de conținut locală a site-ului SharePoint (care implicit va conține două colecții de site-uri de testare).
Articole similare
Trimiteți-le prietenilor: