Windows CE EAP-TLS Enrollment

[Anoniem: 282355]

Momenteel ben ik bezig met een project waarbij de toegang tot het bekabelde netwerk alleen wordt toegestaan door apparatuur die van het bedrijf is. Apparatuur die niet bekend is zal alleen verbinding mogen maken tot het internet.

Momenteel wordt al op een paar locaties MAC Authenticatie gebruikt, maar hier zit natuurlijk een beveiligingsrisico aan.

Nu wordt er binnen het bedrijf gebruik gemaakt van terminals en clients. De clients maken gebruik van Windows XP SP3 en de terminals van Windows CE. De terminals en sommige clients maken verbinding met Citrix.

Ik heb heel wat dingen onderzocht en 802.1x (EAP-TLS) met MAC Authenticatie lijkt mij een mooie oplossing. MAC Authenticatie wordt alleen gebruikt voor apparaten die niet met 802.1x kunnen communiceren. De keuze voor EAP-TLS heb ik gemaakt omdat het de meest veilige oplossing is. Nu zit ik echter met de vraag hoe het zit met de certificaten. Volgens de stof zou je voor TLS op de client een computer, root ca en gebruikers certificaat moeten hebben. Waarvoor dient het gebruikerscertificaat? Of dient elke user een gebruikerscertificaat te krijgen? Of is het zinvol om toch gewoon voor MS-CHAPv2 te kiezen, hiervoor is alleen een Root CA certificaat nodig.

Het grootste probleem waarmee ik momenteel zit is hoe gaan de certificaten op de Thin Clients (Windows CE) geïnstalleerd worden? Windows CE zou EAP-TLS moeten kunnen ondersteunen, en ik heb al een keer een certificaat van een website geprobeerd, en dat werkte gewoon. Ik had het idee om op één Thin client de benodigde certificaten te installeren en daar een image van te maken, en het image d.m.v. een stick of via HP Device manager te pushen. Of is het mogelijk om via HP Device manager certificaten uit te rollen?

[marc181982]

Volgens de stof zou je voor TLS op de client een computer, root ca en gebruikers certificaat moeten hebben. Waarvoor dient het gebruikerscertificaat?

Bij EAP-TLS en PEAP-TLS worden de client certificates gebruikt om de clients identity te valideren. Het is mogelijk om client-certificates naar een bepaalde groep uit te rollen, zodat alleen deze groep toegang krijgt.

Gebruik je een self-signed certificate voor MS-CHAPv2, dan moet de client het certificaat "vertrouwen" welke geinstalleerd is op de NPS server.

[ Voor 3% gewijzigd door marc181982 op 09-10-2012 20:36 ]

[Anoniem: 282355]

marc181982 schreef op dinsdag 09 oktober 2012 @ 20:33:
Volgens de stof zou je voor TLS op de client een computer, root ca en gebruikers certificaat moeten hebben. Waarvoor dient het gebruikerscertificaat?

Bij EAP-TLS en PEAP-TLS worden de client certificates gebruikt om de clients identity te valideren. Het is mogelijk om client-certificates naar een bepaalde groep uit te rollen, zodat alleen deze groep toegang krijgt.

Gebruik je een self-signed certificate voor MS-CHAPv2, dan moet de client het certificaat "vertrouwen" welke geinstalleerd is op de NPS server.

En waarvoor dient het computer certificaat dan? Daarmee authenticeert de computer zich toch? De Thin clients zijn geen lid van het domein, deze zouden zich dan niet moeten kunnen identificeren..

[marc181982]

Anoniem: 282355 schreef op dinsdag 09 oktober 2012 @ 21:09:
[...]


En waarvoor dient het computer certificaat dan? Daarmee authenticeert de computer zich toch? De Thin clients zijn geen lid van het domein, deze zouden zich dan niet moeten kunnen identificeren..

Klopt, het is mogelijk om EAP-TLS te gebruiken met non-domain computers. Om EAP-TLS te gebruiken voor non-domain computers zul je het certificaat handmatig moeten importeren. Maar er zijn meer stappen nodig om dit werkend te krijgen, toegang tot de CRL enz. Het handmatig importeren zul je niet aan ontkomen,

When you use Extensible Authentication Protocol (EAP) with a strong EAP type, such as Transport Layer Security (TLS) with smart cards or certificates, both the client and the server use certificates to prove their identities to each other. This process is called mutual authentication. Certificates must meet specific requirements to allow the server and the client to use them for mutual authentication.

Van : http://technet.microsoft....rary/dd197563(WS.10).aspx

PEAP-MSCHAPv2

Can I use PEAP-MS-CHAP v2 for authenticating both the domain devices and the non domain devices?
Yes, you could use PEAP-MS-CHAP v2 for non domain device, but it's not recommend.
First, you need to import trusted root CA.
Then, you need to create AD account for each device. It need to identify each device instead of use only one user account.
Next, you need to change NPS setting, create rule to change user to domain\user to authenticate with AD account. Or setup 802.1x supported clients not to "automatically use my Windows logon name and password".These clients will be prompted
to enter domain credentials.
If you use EAP-TLS authentication, you just need to install certificate via web CA. The certificate name installed is same as device name.

EAP-TLS non-domain machines

1) Find a way of distributing and installing a computer and/or user certificate to the PC

2) Verify that the SAN of the computer certificate has a DNS name that equals a domain created computer account. It does not need to be the same name as the name of the PC on which the certifcate is installed.

3) Verify that the SAN of the user certificate (is used) has an UPN entry that equas a user account matching the given user

4) When the Radius server receives the computer certificate, it often complains that it can’t validate account host/<dns name>. This is because no Service Principal name (SPN) has been created in AD for the computer account. You could manually create this by using setspn -S host/<dns name> <computeraccountname> or instead of making a SPN, you could configure Radius proxy to remove "host/" from the account name before validating it. It would require a Radius proxy sending it to a normal Radius server. They can’t run on the same server, so you would need two servers for the Radius server infrastructure.

5) Also verify that the non-domain joined PC can access the CRL and AIA information

[ Voor 48% gewijzigd door marc181982 op 09-10-2012 22:33 ]

[Anoniem: 282355]

Thanks voor het snelle antwoord.

Dan lijkt het mij verstandiger om gewoon EAP-MSCHAPv2 te gebruiken. Aangezien PEAP MS-CHAP niet aan geraden wordt voor non domain users. En om nu voor elk systeem een account aan te maken maakt het beheer in configuratie ook niet eenvoudiger.

Als ik het goed begrijp hoef ik bij EAP-MSCHAPv2 alleen een root certificaat te installeren en authentiseert de user zich via username + password. Nu is mij alleen nog onduidelijk hoe de computer zich dan authentiseert want op technet staat bij Client computer certificate in the certificate store of the client.: "No. User authentication is performed with password-based credentials, not certificates."

[ Voor 3% gewijzigd door Anoniem: 282355 op 10-10-2012 08:46 ]

[marc181982]

Gebruik je een certificaat welke standaard niet word vertrouwd door de computers (bijv selfsigned certificate), dan moet je het certificaat exporteren welke geinstalleerd is op de NPS server/Router (Alleen de public key) en deze installeren op de client pc's. Door het importeren van de public key op de pc's van de NPS server/Router ''vertrouwd'' de client pc de NPS.

EAP-MSCHAPv2 zet eerst een beveiligde verbinding op, waarna je MS-CHAPv2 gebruikt voor username/password authenticatie. Op deze manier worden je credentials over een beveiligde verbinding verzonden naar de NPS server.

[ Voor 4% gewijzigd door marc181982 op 10-10-2012 13:12 ]

[Anoniem: 282355]

Maar zou jij dan voor EAP-TLS of voor PEAP-MS-CHAPv2 gaan? Nadeel van EAP-TLS voor mij is dat ik dan alle certificaten e.d. moet installeren. Bij PEAP-MS-CHAP alleen een CA installeren, daar een certificaat aanmaken en die installeren op de clients. De clients die lid zijn van het domein dmv group policies het certificaat uitdelen, en de thin clients via Windows CE handmatig installeren. Want voor EAP-TLS moet weer een PKI aangemaakt worden zover ik heb begrepen.

En is voor 802.1x via Server 2008 R2 een NAP persé nodig? In feite zou je toch alles via NPS kunnen regelen? Op internet lees ik telkens het gebruik van NPS + NAP. Het is niet van belang dat de clients gecontroleerd worden of ze virusscanners o.i.d. hebben.

[marc181982]

Onder de NPS (Network Policy Server, het zit hem al in de naam ) kun je een NAP policy aanmaken, deze zal bestaan uit een 3-tal policy's connection request policy's en network policy's en health policy's.

Of je EAP-TLS of EAP-MSCHAPv2 wilt gebruiken ligt aan je omgeving. Zou persoonlijk een kleine test omgeving opzetten of de Network policy opzetten in monitoring mode.

NAP is niet even wat je in een paar uur opzet, helaas heb ik hier geen ervaring mee. Zou onderstaand goed doornemen.

Network Access Protection Design Guide

http://technet.microsoft....ry/dd125338(v=ws.10).aspx

[Anoniem: 282355]

NAP is voor mij niet belangrijk, het gaat erom dat alleen bekende apparatuur toegang kan hebben tot het netwerk en dat via NPS geregeld kan worden dan is dat prima!

Grootste issue waar ik nu mee zit is hoe ik de clients (Thin clients met Windows CE) die niet in het domein zitten toe ga voegen als bekend apparaat. Als alles lid was van het domein was het vrij eenvoudig, omdat de certificaten e.d. gewoon via policies kunnen worden doorgevoerd. Voor de thin clients zou voor elke client een computer certificaat aangemaakt moeten worden. En dat is nogal wat werk voor 300 stuks en 12 locaties

Daarom leek het mij nu om misschien toch voor PEAP-MSCHAPv2 te kiezen. Ik hoef dan alleen het root CA van de server op één thin client te installeren, daar een image van maken en het image uitrollen. Of gaat dat zo niet werken?

[marc181982]

Gebruik je een certificaat welke al vertrouwd word door de client's

Stukje uit : http://technet.microsoft....ry/cc772401(v=ws.10).aspx

Some of these trusted root CA certificates, which are issued by public trusted root certification authorities, are included by default in all installations of Windows; they are included on the product installation compact disc or they are present on computers sold by original equipment manufacturers (OEMs) that provide computers that have Windows installed on them.

For example, in the certificate store on computers running Windows XP, in the Trusted Root Certification Authorities folder, there are CA certificates from the Verisign Trust Network CA, the Thawte Premium Server CA, and the Microsoft Root Certification Authority. If a computer running Windows XP is presented with a certificate that was issued by one of these CAs and the certificate is configured properly and is valid, the computer running Windows XP trusts the certificate.

You can purchase additional certificates from many companies, such as Verisign and Thawte, to use in your authentication infrastructure. For example, when you deploy PEAP-MS-CHAP v2 and the Validate server certificate setting is enabled on the client, the client computer authenticates the NPS server using the NPS server certificate. If you do not want to deploy your own CA and issue your own server certificates to NPS servers, you can purchase a server certificate from a company whose CA is already trusted by client computers.

[Anoniem: 282355]

Heb even gekeken en op de Windows XP clients staan idd heel erg veel certificaten, alleen op de Server 2008 machine en Windows CE machines weer een stuk minder (heb gekeken bij de trusted authorities).

Wat ik alleen niet begrijp is dat ze aangeven dat je bij MSCHAPv2 geen PKI nodig hebt. Maar als je NPS gaat gebruiken heb je een computer certificaat nodig, en het CA certificaat moet op elke NPS server en client geïnstalleerd worden. Dit gaat toch niet zonder Certifcation Authority? Dan heb je dus toch nog een PKI..

En een computer certificaat moet dat uniek zijn? Ik heb een policy gemaakt dat elke client een computer certificaat moet aanmaken. Als ik nu voor de Windows CE machine een computer certificaat maak, dit installeer en dmv een image te maken en terug te zetten op andere machines gaat dit werken?

[Equator]

Anoniem: 282355 schreef op donderdag 11 oktober 2012 @ 09:38:

Wat ik alleen niet begrijp is dat ze aangeven dat je bij MSCHAPv2 geen PKI nodig hebt.

MSCHAPv2 gebruikt de credentials van de gebruiker, niet die van de computer.

Maar als je NPS gaat gebruiken heb je een computer certificaat nodig, en het CA certificaat moet op elke NPS server en client geïnstalleerd worden. Dit gaat toch niet zonder Certifcation Authority? Dan heb je dus toch nog een PKI..

En een computer certificaat moet dat uniek zijn? Ik heb een policy gemaakt dat elke client een computer certificaat moet aanmaken. Als ik nu voor de Windows CE machine een computer certificaat maak, dit installeer en dmv een image te maken en terug te zetten op andere machines gaat dit werken?

Als jij alleen de computers van het bedrijf wilt toestaan op het netwerk, dan moet de computer zich authentiseren tegen de switch. Daar kan je dan een computercertificaat voor gebruiken. Deze dienen natuurlijk uniek te zijn, anders kan je het certificaat van een computer die gestolen is, niet intrekken.

De certificaten uitgeven is niet zo heel moeilijk. Dat kan volledig automatisch, mits je een domain integrated PKI configureert. Als je dat gaat doen, dan adviseer ik je een PKI te installeren op een Enterprise Server, zodat jij de controle hebt over de gebruikte certificaat sjablonen.
Ik heb daarvoor ooit in mijn tweakblog een stuk over geschreven.

[Anoniem: 282355]

Equator schreef op donderdag 11 oktober 2012 @ 11:14:
[...]

MSCHAPv2 gebruikt de credentials van de gebruiker, niet die van de computer.


[...]

Als jij alleen de computers van het bedrijf wilt toestaan op het netwerk, dan moet de computer zich authentiseren tegen de switch. Daar kan je dan een computercertificaat voor gebruiken. Deze dienen natuurlijk uniek te zijn, anders kan je het certificaat van een computer die gestolen is, niet intrekken.

De certificaten uitgeven is niet zo heel moeilijk. Dat kan volledig automatisch, mits je een domain integrated PKI configureert. Als je dat gaat doen, dan adviseer ik je een PKI te installeren op een Enterprise Server, zodat jij de controle hebt over de gebruikte certificaat sjablonen.
Ik heb daarvoor ooit in mijn tweakblog een stuk over geschreven.

Ja ok, maar de NPS dient een certificaat te bezitten zodat hij zich kan authentiseren. Dit certificaat dient dan toch in een ADCS gemaakt worden, waardoor je dus toch een PKI bezit.

Het uitdelen op de domain computers is ook allemaal geen probleem. Waar ik tegenaan loop is de Thin clients. Deze gebruiken Windows CE en zijn dus geen lid van het domein. Hiervoor zou ik dus in de ADCS voor elke thin client een certificaat moeten maken, dat schiet uiteraard niet op

[ Voor 13% gewijzigd door Anoniem: 282355 op 11-10-2012 12:29 ]

[marc181982]

Het opzetten van een pki is niet perse nodig als je EAP-MSCHAPv2 gebruikt. Je hebt twee opties : publiek certificaat welke je alleen installeerd op de NPS server die meteen word vertrouwd door de clients omdat deze in je trusted root staat. De tweede optie : genereer dmv selfssl een certificaat, importeer deze op de NPS server, exporteer publieke key en installeer deze op de clients

Houd ook rekening met het vernieuwen van een self signed certificaat vooral als je selfssl tool gebruikt.

[ Voor 13% gewijzigd door marc181982 op 11-10-2012 17:47 ]

[alt-92]

Zit je nog steeds met het punt dat je een cert op de thin client moet installeren, en heb je een extra laag complexiteit geintroduceerd door een niet-geautomatiseerde selfssl implementatie.

Doe dan ADCS.

[witchdoc]

Equator schreef op donderdag 11 oktober 2012 @ 11:14:

MSCHAPv2 gebruikt de credentials van de gebruiker, niet die van de computer.

Het is perfect mogelijk om machine (computer) authenticatie doen met een peap/eap-mschapv2 setup.. zoalng dat apparaat maar een domein apparaat is.
Anders ga je inderdaad met certificaten aan de user kant moeten werken. Ook niet moeilijk om het te doen werken, maar een hele kunst om het perfect te doen.