[WHFB] Kerberos certificate template auto enrollment

[Trommelrem]

In onze organisatie zijn we bezig met een transitie naar een Moderne Werkplek.

Er zijn nog een aantal legacy fileshares. We gaan binnenkort de eerste AAD Joined devices uitrollen, die niet hybrid zijn. Om AAD Joined Devices kunnen laten praten met de legacy shares is een CA en is WHFB ingericht volgens deze manual.

Dit werkt, op een puntje na.
De auto certificate enrollment van de kerberos template krijg ik niet voor elkaar.
Alle domain controllers zijn core only en je kunt dus niet via de certlm.msc een "Kerberos Authentication" template enrollen. Dus wordt dit commando handmatig uitgevoerd vanaf de commandline:

code:

certreq -enroll -machine -q "KerberosAuthentication"

Dit moet toch makkelijker kunnen? Kan ik niet via een ouderwetse GPO een auto enrollment van deze template doen? Als ik auto enrollment selecteer, dan kan ik alleen een Domain Controller, Computer, Enrollment Agent of IPSec template kiezen. Geen Kerberos Authentication. Wat doe ik verkeerd of wat moet ik anders doen?

[Trommelrem]

* schopje

[TheVMaster]

Waarom zo ingewikkeld doen? Voor zover ik het weet heb je geen WhfB nodig om dit specifieke scenario voor elkaar te krijgen: https://docs.microsoft.co...business/access-resources

No additional steps are required to get access to on-premises resources for Azure AD joined devices. This functionality is built into Windows 10.

[ Voor 29% gewijzigd door TheVMaster op 21-06-2021 13:23 ]

[Trommelrem]

TheVMaster schreef op maandag 21 juni 2021 @ 13:22:
Waarom zo ingewikkeld doen? Voor zover ik het weet heb je geen WhfB nodig om dit specifieke scenario voor elkaar te krijgen: https://docs.microsoft.co...business/access-resources


[...]

In datzelfde artikel staat ook:

If you have plans to login to the AADJ device other than password method Like PIN/Bio-metric via WHFB credential login and then access on-premise resources (shares, printers, etc.), please follow this article.

[TheVMaster]

Trommelrem schreef op Monday 21 June 2021 @ 19:48:
[...]

In datzelfde artikel staat ook:

[...]

Die requirement had ik even over het hoofd gezien

[Trommelrem]

TheVMaster schreef op maandag 21 juni 2021 @ 20:46:
[...]


Die requirement had ik even over het hoofd gezien

Het "probleem" van Windows Hello for Business is dat je zonder wachtwoord inlogt en dus niet met je on-prem servers kunt authenticeren. Als je computer Hybrid is, dan werkt alles out of the box aan de hand van een Active Directory Key Trust, mits je minimaal een Windows Server 2016 of hoger server met ADDS rol hebt (domain level hoeft niet op dat niveau te zijn). Maar omdat je computer AzureAD Joined is, praat je device niet met de ADDS. Vandaar dat je via Endpoint Manager en NDES een certificaat moet uitrollen, zodat je AzureAD Joined device toch kan authenticeren met servers met ADDS rol. Bijvoorbeeld om een file share te benaderen, zoals die van een on-prem fileserver, of een Azure File Share.

De certificaat uitrol is overigens zojuist gelukt naar servers met ADDS rol. Waar het mis ging is dat de Active Directory van deze organisatie in een ver verleden een Windows 2000 Mixed domain functional level was, met oude certificate templates. De Domain Controller template is deprecated en superseded door Kerberos. Als dit goed staat, dan krijgen servers met ADDS rol wel het juiste certificaat.

[ Voor 3% gewijzigd door Trommelrem op 22-06-2021 08:36 ]