[Windows 11] Internet Explorer definitief vervangen door Edg

[ibmpc]

In onze Microsoft 365 omgeving moet verplicht met phishing resistant worden ingelogd. Ik ben hard bezig om MFA overal uit te schakelen ten gunste van Yubikeys of andere phishing resistant zoals WHFB. Geen Yubikey of WHFB betekent geen toegang.

Helaas heeft Windows 11 nog steeds een aantal afhankelijkheden van de Internet Explorer engine, ook al is de Internet Explorer browser niet meer aanwezig. Om bijvoorbeeld met PowerShell in de adminportals in te loggen, dan kan dat helaas alleen met MFA, omdat het loginscherm nog gebruik maakt van de Internet Explorer engine. Nu heb ik een simpele AVD in een Hostpool gezet en dat IP adres uitgezonderd van phishing resistant, zodat alsnog met MFA kan worden ingelogd in PowerShell, alleen vanaf die specifieke AVD. Inloggen in de AVD wordt wel afgedwongen met phishing resistant.

Is er een mogelijkheid om Internet Explorer volledig uit Windows 11 te slopen, zodat loginpagina's voor Microsoft 365 gewoon met de Edge engine worden getoond, die wel phishing resistant ondersteunt? Ik zou bijvoorbeeld graag met een Yubikey in de PowerShell administraties willen inloggen.

[Killah_Priest]

Veel van de MS powershell modules gebruiken onder water de oude dotnet "webview" control welke gebruik maakt van de IE engine (waarom ze niet de nieuwere webview2 gebruiken die op chromium gebaseerd is: geen idee).
Je zou echter de devicode login flow kunnen gebruiken bij de meeste van deze cmdlets.

Een alternatief is om zelf de code te schrijven om tokens op te halen en dan ofwel handmatig alle api calls doen die deze Powershell modules doen wanneer je ze gebruikt OF heel hacky: zelf token opvragen en deze injecten in de Powershell sessie (helaas verschilt de manier waarop je dat moet doen per PS module en vaak vereist dit echt wel diepgaande dotnet kennis mbt "reflection" gebruiken om private properties en fields te kunnen wijzigen).

[ibmpc]

Werkt een token opvragen en deze injecteren wel? Staat de Conditional Access policy voor token protection dat toe? Vooralsnog werkt die policy alleen op de Office 365, maar in de toekomst wellicht op meer.

Zelfs het inloggen op een Edge profiel gebeurt nog met de IE engine... Daarop kan ik geen device login doen helaas.

[Killah_Priest]

Volgens de documentatie van https://learn.microsoft.c.../concept-token-protection werkt token protection alleen voor refresh tokens en niet voor access tokens (aangezien deze JWT zijn ook logisch, die worden in principe "offline" gevalideerd door de API waar je de betreffende request doet => signature en payload ok => signed door een trusted partij om tokens te signed (MS Identity platform) => API vindt het ok wat betreft het JWT deel).

Je kunt met de MSAL dotnet library of een webrequest gewoon tokens opvragen met Powershell (en er zijn ook 3rd party modules om dit te doen). Je kunt in veel gevallen gewoon de clientId van de default appreg van de betreffende PS module gebruiken (vereist vaak een beetje reverse engineer werk) of gewoon zelf een appreg maken met de gewenste API permissies. Veel modules hebben tegenwoordig ook een AccessToken parameter waarmee je een eigen token mee kunt geven, dat is vaak makkelijker als uitvogelen waar de token wordt opgeslagen en dit dmv reflection wijzigen.

wat betreft de device login: ik heb het niet over device login maar devicecode login.
Hierbij kun je een login via een ander device doen (of gewoon op dezelfde device maar met een andere browser):

code:

PS C:\Users\KP> Connect-MgGraph -DeviceCode
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code D6349KS92 to authenticate.

(vervolgens ga je in een browser naar die url, voer je de code in en vervolgens wordt je om je username/password geprompt en eventuele MFA meuk met authenticators)