Je Mac verstuurt het verkeerde Windows-account via RDP

De tunnel maakt opnieuw verbinding, de Mac bereikt het kantoornetwerk weer, en Extern bureaublad antwoordt nog steeds met een aanmeldingsfout. Die fout is niet van de VPN. De tunnel brengt de Mac op een goedgekeurd netwerk; een Windows-account meldt zich aan op de externe computer, en de verbindingsvermelding kan een account blijven sturen dat je maanden geleden niet meer gebruikte.

Bekijk de vermelding voordat je de sleutelhanger aanraakt.

Het VPN-account en het Windows-account zijn verschillende dingen

Een VPN-identiteit authenticeert het apparaat of de persoon bij de gateway van de tunnel. Ze zegt niets over welk Windows-account de externe host accepteert, en kan dat niet vervangen. Wanneer de tunnel gezond is en het bureaublad de aanmelding weigert, is het probleem de netwerklaag al voorbij. Behandel de twee authenticaties als aparte gebeurtenissen met aparte logboeken. De gateway kan een schone sessie tonen terwijl het beveiligingslogboek van Windows een mislukte aanmelding om een heel andere reden vastlegt.

Stel dat de beheerder je zei EXAMPLE\alex te gebruiken en de opgeslagen vermelding nog steeds een kale alex selecteert. Dat zijn verschillende accounts. De niet-gekwalificeerde naam wordt tegen de lokale accounts van de externe computer opgelost, en op een domeingekoppelde machine lost die misschien helemaal niet op naar de domeinidentiteit.

Het domeinvoorvoegsel verwijderen is dus geen algemene reparatie. Het verandert welk account wordt aangevraagd, en het kan een weigering opleveren die op een wachtwoordprobleem lijkt terwijl het wachtwoord nooit het probleem was.

Open de verbindingsvermelding, niet de hele sleutelhanger

Zoek in de huidige Windows App voor macOS de externe pc onder Apparaten, open de actie Bewerken en bekijk het account dat aan die specifieke vermelding is gekoppeld. De app biedt bediening voor opgeslagen inloggegevens waarmee je een ander opgeslagen account kunt kiezen of een verouderd account kunt verwijderen. Dat is de ondersteunde plek om de selectie te corrigeren. Wijzig één eigenschap per keer, zodat je weet welke bewerking echt van belang was. Een wijziging van inloggegevens en een wijziging van de hostnaam samen leveren een resultaat op dat niemand kan toeschrijven.

Begin niet met het verwijderen van elk sleutelhangeritem waarvan de naam de servernaam bevat. Sleutelhangeritems worden tussen apps gedeeld, en een brede verwijdering kan ongerelateerde toegang weghalen zonder iets aan de Windows-kant te veranderen. Het vernietigt ook het bewijs dat je zou willen hebben als het echte probleem de hostnaam, de route of de RDP-service blijkt te zijn.

Als één opgeslagen inloggegeven door meerdere externe pc's wordt gebruikt, controleer dan die afhankelijkheden voordat je het verwijdert. Het bewerken van de vermelding voor één pc is omkeerbaar; het verwijderen van een gedeeld inloggegeven is een wijziging met een grotere impact en een slechter auditspoor.

Gebruik de accountvorm die de beheerder heeft opgegeven

Typ het account precies zoals het is uitgegeven, in de vorm die de omgeving verwacht: DOMAIN\user voor een domein in NetBIOS-stijl, of de user principal name als dat is wat de map gebruikt. Sla het daarna op voor deze pc en doe één bewuste verbindingspoging.

Let op welk account de aanmeldingsprompt toont. Een prompt die al een andere naam bevat, betekent dat de opgeslagen selectie niet is vervangen, en de poging die je net deed testte opnieuw de oude inloggegevens.

Houd het wachtwoord buiten notities, tickets en schermafbeeldingen. Noteer in plaats daarvan de accountnaam en de exacte foutcode, want de code onderscheidt slechte inloggegevens van een beleidsweigering, een verlopen wachtwoord of een machine die RDP helemaal niet accepteert.

Een mislukte verbinding vóór de aanmelding is een ander defect

Als de viewer faalt voordat er enige Windows-aanmelding verschijnt, zijn de inloggegevens niet de verdachte. Controleer of de hostnaam wordt opgelost, of de route naar de host via de tunnel bestaat en of de RDP-service luistert. Een TCP-verbinding die nooit tot stand komt, bereikt nooit de accountlaag.

Omgekeerd is een expliciete accountweigering geen bewijs dat DNS kapot is of dat certificaatvalidatie moet worden versoepeld. Zulke wijzigingen verzwakken de verbinding en laten de weigering meestal precies waar die was.

Test in de kleinst mogelijke stappen: bevestig dat de poort bereikbaar is, dat de aanmeldingsprompt verschijnt, dat het getoonde account het bedoelde is, en geef dan het wachtwoord. Elke stap heeft een eigen defect en een eigen oplossing.

Laat automatische herverbinding met rust

Automatische herverbinding hergebruikt de bestaande vermelding, inclusief het opgeslagen account. Het is een gemak, geen reparatie van inloggegevens, dus uitschakelen lost een verkeerde selectie niet op en inschakelen maakt er geen. Als de vermelding nu het juiste account bevat, zal herverbinding dat gebruiken.

Sla de gecorrigeerde vermelding op, maak één keer handmatig verbinding en noteer welk account werkte. Juist die ene regel maakt de diagnose van de volgende persoon vijf minuten in plaats van een middag sleutelhangerarcheologie.