VPN-aliro sen rajtoj al fora labortablo: kvar apartaj pordegoj

Uzanto konektiĝas al la VPN, malfermas dosieran kunhavon kaj internan aplikaĵon, kaj poste RDP-provo redonas «la uzantokonto ne estas rajtigita por fora saluto». En tiu mesaĝo nenio pri la tunelo estas malĝusta. Kvar sendependaj pordegoj staras inter VPN-konto kaj interaga labortablo, kaj nur la lasta ĝin produktis. Homoj kutime aldonas la konton al Administrators, kio donas multe pli ol la labortablo kaj ne riparas la pordegon se grupa politiko malpermesas ĝin. Jen kion ĉiu pordego fakte faras, kaj kiel ŝanĝi nur tiun, kiu rifuzas.

Kvar pordegoj staras en fiksa ordo

La enirejo unue decidas ĉu la identeco entute rajtas starigi tunelon: RADIUS-politiko, grupa kondiĉo, atestila kontrolo, permeso de Access Server. Poste enkursigo kaj fajroŝirmiloj decidas ĉu la paketo el la tunela baseno atingas la TCP 3389 aŭskultanton de la celo. Poste la NLA-manpremo de la kliento aŭtentikigas la konton kontraŭ la celo. Nur post tiuj tri la loka sekureca aŭtoritato kontrolas ĉu la konto posedas la salutrajton, kiun postulas interaga fora sesio.

Ĉar la ordo estas fiksa, ĉiu pordego kaŝas tiujn malantaŭ si. Malsukcesa tunelo diras nenion pri enkursigo; blokita pordo diras nenion pri la salutrajto; sukcesa pordotesto diras nenion pri enlaso. Tial «la VPN funkcias sed RDP ne» estas ne unu problemo sed limo inter du el tiuj pordegoj, kaj tial la erarteksto estas la plej rapida maniero scii, kiun vi trafis.

La rajto, kiu fakte rifuzas la sesion

Saluto al fora labortablo postulas la uzantrajton Permesi saluton per servoj de fora labortablo, SeRemoteInteractiveLogonRight. Ĝi estas kontrolata ĉe saluto, ne ĉe tunela starigo, tial konto povas foliumi la reton dum horoj kaj tamen esti rifuzata labortablon. La dialogo, kiu montras ĝin, troviĝas sub Lokaj politikoj, Atribuo de uzantrajtoj, kaj la domajna ekvivalento troviĝas en GPO.

Defaŭlta membreco dependas de la rolo de la maŝino: laborejoj kaj membraj serviloj donas ĝin al Administrators kaj Remote Desktop Users, dum domajna regilo donas ĝin nur al Administrators. Tiu sola fakto klarigas la plejparton de la konfuzo, ĉar la sama konto sukcesas sur dosierservilo kaj malsukcesas sur DC. Rifuzrajto venkas la respondan permesrajton sendepende de grupa membreco, do konto, al kiu estas kaj permesite kaj rifuzite, estas rifuzata. Larĝa rifuzgrupo povas kapti administranton aldonitan kiel komplezon.

Legu la efektivan politikon, ne la lokan dialogon

Lokan politikon anstataŭigas ĉiu domajna GPO, kiu difinas la saman rajton, do la loka snap-in povas montri ĝustaspektan liston dum la efektiva stato malsamas. Eksportu tion, kion la maŝino fakte aplikas, poste serĉu la rajton kaj legu la SID-ojn anstataŭ la montratajn nomojn:

secedit /export /cfg C:\temp\secpol.cfg
Select-String -Path C:\temp\secpol.cfg -Pattern SeRemoteInteractiveLogonRight
gpresult /scope computer /v

En tiu eligo, *S-1-5-32-544 estas Administrators kaj *S-1-5-32-555 estas Remote Desktop Users.

Se aperas nek unu nek la alia, neniu krom politikposedanto povas malfermi labortablon, kion ajn la loka dialogo pri uzantoj kaj grupoj sugestas. Tiam gpresult nomas la GPO, kiu venkis, kaj tio estas la objekto, kiun vi devas redakti; ŝanĝi lokan politikon sur domajne aliĝinta maŝino estas testo, ne ripari.

Donu la plej mallarĝan taŭgan rajton

La kutima respondo estas la grupo Remote Desktop Users sur la celo. Ĝi portas la rajton defaŭlte, estas multe pli malgranda ol Administrators, kaj apartigas «povas malfermi labortablon» de «povas administri la servilon». Kie politiko eksplicite reatribuis la rajton, aldonu la grupon aŭ la konton al tiu politiko anstataŭ aldoni grupon, kiun neniu intencis kiel alirkontrolon.

Add-LocalGroupMember -Group "Remote Desktop Users" -Member "CORP\a.user"

Kontrolu la rifuzliston antaŭ ol aldoni ion. Se rifuzrajto nomas grupon, kiu enhavas la uzanton, la ĝusta ŝanĝo estas forigi la konton el tiu grupo aŭ mallarĝigi la rifuzon, ne aldoni duan permeson aliloke. Notu, kiun rajton vi ŝanĝis kaj kie, ĉar posta GPO-refreŝigo silente restarigos la antaŭan staton kaj la bileto remalfermiĝos kun la sama mesaĝo.

Tenu la retan vojon kiel apartan decidon

La VPN-grupo ne devas atingi ĉiun pordon. Kiam grupo bezonas aplikaĵon kaj ne labortablon, fajroŝirmila regulo limigita al la tunela baseno kaj la aplikaĵa pordo efektivigas tiun politikon, dum la salutrajto restas netuŝita.

Get-NetFirewallRule -DisplayGroup "Remote Desktop"
Test-NetConnection -ComputerName 10.20.0.50 -Port 3389

La propra agordo de OpenVPN por kliento kaj la grupaj permesoj de Access Server povas limigi la celprefiksojn en la sama spirito; neniu el ili donas Windows-salutrajton, kaj salutrajto ne povas malfermi pordon. Tenu ilin en apartaj ŝanĝfenestroj, ĉar pordan regulon kaj rajton aprobas malsamaj homoj.

Kontrolu laŭ la sama ordo, laŭ kiu la pordegoj validas: ĉu la konto povas starigi la tunelon, ĉu la sesio atingas la aŭskultanton, ĉu la kliento aŭtentikigas, kaj ĉu la konto havas la rajton. Ping, kiu malsukcesas dum la pordotesto sukcesas, estas fajroŝirmilo respondanta alie al ICMP, ne pruvo, ke RDP estas blokita. La referenco de Microsoft pri la salutrajto listigas la defaŭltojn laŭ maŝinrolo kaj la regulon, ke rifuzo venkas permeson.