Moja postavka uključuje jedan poslužitelj koji djeluje kao RD-web pristup, RD Gateway, RD Licensing i RD Connection Broker i pokreće Windows 2022. Nazovimo ga rds.internal.contoso.com
Postavio sam još jedan poslužitelj koji je Windows 2019 i djeluje kao domaćin RD sesije te objavljuje određeni program remoteApp. nazovimo ovo rds-host.internal.contoso.com
Čini se da sve radi normalno, ali nasumično, ja (ili neka druga osoba koja testira sustav) vidjet ću skočni prozor u aplikaciji s natpisom "Problem s licencom za udaljenu radnu površinu... bit ćete isključeni za 60 minuta." Nakon 60 minuta dolazi do prekida veze. Jedina pogreška koju vidim je na poslužitelju rds-host i glasi 50283 - "Host poslužitelj sesije udaljene radne površine nije mogao kontaktirati poslužitelj licence udaljene radne površine rds.intneral.contoso.com. Provjerite radi li usluga licenciranja udaljene radne površine na licencnom poslužitelju, prihvaća li licencni serviser mrežni zahtjev i je li licencni poslužitelj registriran u WINS i DNS."
Nemam postavke WINS-a, ali naziv rds.internal.contoso.com ispravno se rješava i nije se promijenio. Potvrdio sam da je usluga pokrenuta na računalu rds.internal.contoso.com i da je rds-host može pingati. Aplikacija za dijagnostiku licenciranja ne pokazuje nikakav problem i pokazuje ispravne licence dostupne i provjerene kada se gleda putem računala s rds-domaćinom, čak i kada korisnik ima problema.
Jedina stvar koju sam primijetio je da jedna osoba za koju se čini da ima više problema s ovim pokušava pokrenuti aplikaciju preko VPN veze, ali mislim da to nije važno jer mislio sam da licenciranje samo razgovara između rds-host i rds.internal.contoso.com, a ja sam održavao otvorene udaljene aplikacije i održavao ih na životu bez upozorenja danima u isto vrijeme kada drugi korisnik dobiva izbačen.
koliko god to vrijedilo, isprobao sam nekoliko drugih korisničkih računa i čini se da se neki računi žale na licenciranje, a drugi ne. Svi su u istim sigurnosnim grupama TS-a, iako imaju druge grupe koje ne bi trebale biti povezane, a koje nisu 100% identične.
Ovdje samo nagađam, ali možda je problem u DNS-u korisnika VPN-a.
ponovno pokretanje poslužitelja za licenciranje ili pristupnog poslužitelja nije pomoglo u rješavanju problema s tim lokalnim korisnikom, ali sam nisu htjeli ponovno pokrenuti računalo s rds-hostom dok je netko drugi uključen i potencijalno provodi vlastito testiranje raditi.
Nikad nisam imao ovaj problem dok nisam premjestio host sesije iza vatrozida Palo Alto. Imam 0 odbijanja u vatrozidu, radi veliku većinu vremena, ali povremeno ima problema i čini se da najviše muči jednog određenog korisnika (malo testno okruženje, 3 normalna korisnika tijekom 3 tjedna i 1 korisnik je to imao 1x, korisnik 2 0x, a ovaj barem 10x, ali prošao je 8 dana bez problem).
TerminalServices-RemoteConnectionManager\Admin
Upozorenje, ID događaja 50283
Host poslužitelj sesije udaljene radne površine nije mogao kontaktirati licencni poslužitelj udaljene radne površine WS01.XNI.local. Provjerite radi li usluga licenciranja udaljene radne površine na licencnom poslužitelju, prihvaća li licencni poslužitelj mrežne zahtjeve i je li licencni poslužitelj registriran u WINS-u i DNS-u.
Također sam primijetio da se gornja poruka poklapa s ovom porukom u istom odjeljku, ali operativnom dnevniku (međutim, ovo se pojavljuje s praznim korisnikom i domenom i u drugim slučajevima):
TerminalServices-RemoteConnectionManager\Operational
Upozorenje, ID događaja 1149
Usluge udaljene radne površine: provjera autentičnosti korisnika uspjela:
Korisnik:
Domena:
Mrežna adresa izvora:
Promjene danas čekam rezultate za:
Upravo sada testiram s gomilom dodatnih dopuštanja u vatrozidu kao hvataljkama da vidim pomaže li. Glavno pravilo bilo je dopuštanje samo aplikacije ms-rpc. Sada sam proširio catch pravila da dopustim netbios aplikacije i smb, zatim pravila da uključe samo portove (bez ID-a aplikacije). Kao još jedan pucanj u prazno resetirao sam korisnički profil, činjenica da je u skladu samo s njom, zaključio sam da vrijedi pokušati.
Dodatna jedinstvena stavka za ovog korisnika je da su ne dio Azure AD-a za koji je domaćin sesije postavljen s SSO-om za korištenje PRT-ova. Dakle, njihova prijava ima odgodu isteka vremena za početak autentifikacije drugog faktora. Ovo mi je upravo palo na pamet kao ono što bi moglo biti moj veći problem (doduše, ovo se nikada nije dogodilo dok nije premješteno iza vatrozida)
Drago mi je da ste to naizgled popravili.
Što se tiče prekidača, nikad ih ne bih ažurirao osim ako ne znam da rješava problem koji me brine, ali onda su moji prekidači gotovo svi vrlo osnovni Cisco Catalyst i Nexus preklopnici bez ičega posebnog što bi zahtijevalo ažuriranja (izolirana mreža za upravljanje, ograničene značajke u upotrebi, itd.). Firmware prekidača ažuriram možda najviše jednom godišnje.
@Paladin Pazio bih da ne segmentiram interno pomoću vatrozida i odgađam ažuriranja firmvera. Ovih dana naizgled cijelo vrijeme postoje greške nultog dana. Radio sam s mnogo tvrtki koje su testirane perom i zastrašujuće je kako se malo uporište može lako proširiti. Na svojim Nexus prekidačima provjerite svoj firmware jer su imali gadan nulti dan u zadnjih godinu dana.
@Paladin Općenito se pokušavamo pridružiti najnovijem izdanju radi značajki, ali pričekajte s pridruživanjem dok ne bude na zakrpi 3+ tog glavnog izdanja. Nismo mi "toliko" veliki... manje od 400 uređaja. Jedno staklo za pregled vatrozida + prekidača uređaja i prometa je stvarno lijepo kada radi. Nažalost, čini se da Fortinet QA dosljedno pokušava modelirati Microsoft iz sredine 2000-ih. Neću ulaziti u cjelovito brbljanje o toj temi, već ću reći da je tako lijepo kada radi, ali prava je noćna mora kada se pokvari. Za nas, ono što nas drži jesu vizija i uvid za koje je sposoban i lakoća upravljanja mrežom, ali ako ikada dobijem radijus+automatsko dodjeljivanje VLAN-a, bit će mi ugodnije izgubiti taj pogled s jednim oknom koji trenutno imamo [većinu vremena].
