Search results matching tags 'Security' and 'Windows Server 2008 R2'

Network Access Protection part 3, 802.1x enforcement

Martijn Bellaard — Tue, 06 Mar 2012 18:15:03 GMT

Een tweede NAP enforcement is op basis van 802.1x. (http://en.wikipedia.org/wiki/IEEE_802.1X). Op het moment dat de een werkplek (supplicant) online komt, krijgt hij van de switch (authenticator) het verzoek voor zijn health status (authentication). Via het radius protocol wordt dit verzoek door gezet naar de NPS (authentication) server. Deze bepaalt de health status van de werkplek. Op basis van deze health status bepaalt de NPS server op welke VLAN de werkplek moet komen. Deze informatie geeft hij dan weer door aan de switch. De switch activeert dan de poort voor het juist VLAN.

Om 802.1x enforcement in te richten heb je dus een switch nodig die 802.1x ondersteunt. Op deze switch definieer je je tweede VLAN. Een productie VLAN waar de werkplek geplaatst wordt als hij healthy is en een quarantaine VLAN als hij niet healthy is. Als de werkplek in de quarantaine VLAN terecht komt moet hij wel de mogelijkheid hebben zichzelf healthy te maken. In de praktijk komt dat er meestal op neer dat hij zijn antivirus en Windows moet kunnen updaten. Hiervoor heb je twee opties. De eerste is een update server in het quarantaine VLAN te plaatsen, de tweede is de werkplek toegang te geven tot internet. In beide gevallen kan de werkplek zichzelf gaan updaten

Naast de Wired (bedraad) oplossing is het ook mogelijk 802.1x in te zetten voor een wireless (draadloos) oplossing. In deze blog gaan we uit van een wired oplossing, maar het opzetten van NAP voor wireless is niet veel anders.

Wat heb je nodig

Voordat je begint moet je een paar zaken geregeld hebben voor dat je kunt beginnen. Hier is een overzicht van wat je minimaal nodig hebt:

1 x Windows 2008 R2 NPS server
1x een computer certificaat voor de NPS server. Deze gebruikt de NPS server voor het PEAP protocol.
1x een 802.1x compliant switch dat het radius tunnel attribute ondersteunt. Het hoeft niet per definitie een layer 3 switch te zijn

Step by Step

We starten op de NPS server, in mijn test lab is dat de RRAS01 server. Start op deze server het Network Policy Server console op.

Selecteer NPS (Local)
Kies voor Configure NAP

Kies voor IEEE 802.1X (Wired),
Druk op Next

Je moet nu opgeven welke switches je gaat gebruiken.

Druk op Add, en vul de gegevens in van je Switch

Onthoudt de shared secret goed. Gebruik je een complexe shared secret, wat aan te raden is, copieer hem dan eventueel in password safe. Deze shared secret heb je later nodig op je switch.

Druk op OK en herhaal deze stap voor elke switch die je wilt inzetten.
Druk op Next

Je hoeft geen computer of users op te geven, als je gebruik maakt van 802.1x in combinatie met NAP. Wel bieden de meeste Switch leveranciers een uitbreiding op hun switch aan dat je gebruik kunt maken van authenticatie op basis van groepen of computers. Hiervoor moet je dus (meestal) een extra licentie kopen.

Druk op Next

Controleer of je de juiste certificaat heb geselecteerd en dat het authenticatie protocol PEAP-MS-CHAPv2 is.

Druk op Next

Nu komt het “lastige” gedeelte. We gaan aangeven welke VLAN voor Full Access gebruikt gaat worden en welke voor Restricted Access gebruikt gaat worden.

Onder Full access Network druk op Configure

Je krijgt nu het volgende scherm voor je:

Tunnel-Type moet VLAN zijn, want de scheiding vindt plaats op basis van VLAN’s. Het medium is 802 inclusief Ethernet. De derde setting is die van Tunnel-Pvt-Group-ID. Dit is de VLAN die een werkplek Full Access geeft. Gebruik hier dus de juiste VLAN ID. In het voorbeeld is dat VLAN 777.

Ga naar de tweede tabblad.
Druk op Add
Selecteer als Vendor: Custom
Selecteer Tunnel-Tag

De Tunnel-Tag attribuut wordt door sommige switches gebruikt om settings op de switch te groeperen. Raadpleeg de handleiding van de switch of je deze nodig hebt. Staat er niets over in dan heb je hem waarschijnlijk niet nodig. Door deze op 1 te zetten heb je in ieder geval een juiste default waarde.

Druk op Add
Als waarde gebruik je 1 of de waarde die je moet opgegeven volgens de handleiding van je switch.
Druk 2x op OK

We gaan nu de restricted access network configureren. Dit gaat op dezelfde manier als bij Full Access. Alleen geef je als Tunnel-Pvt-Group-ID een andere VLAN op. Het VLAN waarop een werkplek komt als hij niet voldoet aan de eisen.

In mijn voorbeeld maak ik gebruik van VLAN ID 666.

Druk op Next

We geven nu aan welke Health Validator we willen gebruiken.

Druk op Next en dan op Finish

De NPS server is nu klaar. Je kunt nu je switch gaan configureren. Hoe dat moet zul je moeten opzoeken in de handleiding van je switch. Veel geluk met NAP en IEEE 802.1x

Martijn Bellaard

Inheritance vinkje steeds uit? Rechten ‘kwijt’?–> Het Active Directory AdminSDHolder proces!

Erwin Derksen — Sun, 03 Apr 2011 13:16:00 GMT

Menigeen heeft geen idee wat het is, maar als je je erin verdiept,
dan kan dit een boel ‘vreemde zaken’ verklaren.

Zo werd ik betrokken bij een issue van een klant dat al lange tijd speelde.
Op een of andere manier raakten zij steeds rechten ‘kwijt’ op bepaalde accounts.

Zij hadden op een aantal OU’s rechten uitgedeeld (delegation of control) aan een specifiek account.
In dit geval ging het om een SharePoint serviceaccount dat rechten moest krijgen om foto’s
(thumbnailphoto attribute) en andere gegevens bij te werken voor gebruikersaccounts.

Zo kunnen gebruikers op de MySite zelf hun gegevens bijwerken, terwijl deze dan ook netjes in AD worden aangepast.

Echter, bij een aantal accounts ging dit steeds mis.

Bij een groot aantal gebruikers werd steeds het inherit vinkje uitgeschakeld,
waardoor de aangepaste rechten op een bovenliggende OU niet werden toegepast.
Bovendien werden de rechten gereset, zodat ze ook bij handmatig instellen steeds werden gereset.
Resultaat: Delegation of control werkte niet en dus ging de SharePoint synchronisatie ook steeds mis…

Verantwoordelijk hiervoor bleek het AdminSDHolder proces.

Het AdminSDHolder proces:

Binnen AD bestaan zogenaamde ‘Protected Groups’.
(Zie voor een lijst de bijlage onderaan)
Als een account lid is van een dergelijke groep, dan wordt elk uur het AdminSDHolder proces uitgevoerd.
Dit is een proces dat alle objecten beschermt die lid zijn van een ‘protected group’.
Staat het inherit vinkje dan aan, dan wordt dat door dit proces uitgezet en worden de rechten gereset.
Tevens wordt er een AdminCount waarde van 1 gezet (dit is standaard <NOT SET>) ten teken dat dit object ‘protected’ is.

Voor leden van protected groups geldt dat de rechten van de (lege) AdminSDHolder container worden vergeleken met die van het user object.
Zijn ze verschillend, dan worden de rechten van de AdminSDHolder container toegepast op de user.

Het idee achter het adminSDHolder proces is het beschermen van beheeraccounts. Stel immers dat een admin account lid is van
een OU waarop bijvoorbeeld de helpdesk rechten heeft gekregen om userobjecten aan te passen….
De Helpdesk zou dan dit admin account kunnen aanpassen, om dit soort zaken te voorkomen is er het adminSDHolder proces.

Het adminCount attribute:

Een protected object wordt als volgt weergegeven:

NIET protected : adminCount attribuut heeft geen waarde zoals hier te zien:
(<NOT SET> is de standaardwaarde, maar 0 geeft hetzelfde resultaat.)

WEL protected: adminCount attribuut heeft waarde 1:

Om bovenstaande te kunnen zien moet het ADSI view filter worden aangepast:

Klik CLEAR om de waarde te wijzigen. Hij verandert dan naar <NOT SET>.
Als we dit als test doen en apply geven, dan zien we direct dat de rechten van bovenaf keurig doorerven op dit object.
Echter, na een uur wordt dit dus weer ongedaan gemaakt als een object lid is van een protected group.
De AdminCount waarde wordt dan gereset naar 1 en het vinkje inherit wordt weer uitgeschakeld.
De rechten worden weer gereset naar de waarden die op de AdminSDHolder container van toepassing zijn…

De AdminSDHolder container

De standaard rechten op AdminSDHolder (Let Op: Advanced Features view moet aan staan!)
Deze worden dus elk uur toegepast op ‘protected’ objecten.

Standaard loopt dit dus elk uur (3600 seconden),
het kan ingesteld worden tussen 1 minuut (60s) en 2 uur (7200s) via de registry,
maar dit wordt uitdrukkelijk afgeraden en wel om de volgende redenen:

Het instellen van een kortere interval kan een flinke impact hebben op de performance van AD
De server (2000/2003) of de AD service (2008(r2))moet herstart worden om de wijziging actief te maken
Het wijzigen van dit soort waarden is sowieso niet verstandig vanuit beheerperspectief, het kan troubelshooting in de toekomst complexer maken omdat afgeweken worden van standaard waarden die normaliter geen aanpassing behoeven
De instelling moet per Domain Controller worden gedaan, bij het verplaatsen van de PDC Emulator rol naar een andere DC kan dus een andere interval van toepassing worden, hetgeen verwarrend is.

Is de key niet aanwezig en dus wordt de standardwaarde van 1 uur gebruikt.

LET OP!

Is een gebruiker lid van een protected group (zie bijlage voor de lijst), dan treedt dus dit issue op,
maar ook als hij lid is GEWEEST van een groep, dan blijft het protected kenmerk staan.
Dit wordt dus NIET automatisch teruggezet!

Maar: Welke objecten zijn in mijn AD protected???

Het is handig om een overzicht te hebben van alle protected objecten, ofwel,
objecten waarbij de adminCount waarde op 1 staat.
Van deze objecten worden immers steeds de rechten gereset en het inherit vinkje uitgeschakeld!
Download het gratis programma ADFIND van www.joeware.net en voer het volgende commando in:

Voor het zoeken van protected USERS:

AdFind.exe -b DC=<DOMEIN>,DC=<NAAM> -f "&(objectcategory=person) (samaccountname=*) (admincount=1)" –dn

Met de toevoeging >export.txt exporteer je het resultaat naar een TXT file.

Je kunt dit commando ook gebruiken voor het opvragen van protected GROEPEN:

AdFind.exe -b DC=<DOMEIN>,DC=<NAAM>-f "&(objectcategory=group) (admincount=1)" –dn

Een goed optie is ook het gebruiken van de standaard aanwezige commando's zoals onderstaande voor groepen EN users:

dsquery * -filter "&(|(objectcategory=user)(objectcategory=group))(admincount=1)" -l -attr distinguishedname -limit 0

Mocht je de adminCount waarde van objecten willen resetten, dan kan dat met het script op
DEZE pagina. Dit script zet alle adminCount waarden op 0. Als vervolgens het AdminSDHolder
proces weer draait, dan worden alle accounts die lid zijn van een protected group
automatisch weer protected gemaakt (adminCount waarde wordt weer 1).

Gebleken is dat dit script niet in elke omgeving goed werkt (bij mij werkte het prima), vandaar HIER een alternatief script.

Je kunt eenvoudig controleren of het adminSDHolder proces draait door enige tijd na het
draaien van het vbscript de adfind commando’s te gebruiken.

Blijft over de vraag waarom het bij deze klant om een groot aantal gebruikers ging die als ‘protected’ werden aangemerkt.
Welnu, men had in het verleden ooit de groep ‘Domain Users’ lid gemaakt van ‘Print Operators’.
Print Operators is protected en aangezien protected groups ‘transitive’ zijn, werd ‘Domain Users’ ook protected
en daarmee dus accounts die weer in ‘Domain Users’ zaten. Dit bleef onopgemerkt, totdat
men ging werken met Delegation of control, ofwel, het toekennen van rechten voor het SharePoint
serviceaccount aan een OU. De oplossing was eenvoudg; het verwijderen van ‘Domain Users’
uit “Print Operators’, het resetten van de adminCount waarde op deze groep en vervolgens middels
het genoemde VBScript het resetten van alle accounts.

Het gaat overigens ook mis als gebruikers lid zijn van admin groepen, terwijl
de gedelegeerde rechten wel op hen van toepassing moeten zijn.
In dit geval: Is een account in gebruik als beheeraccount, terwijl
het SharePoint serviceaccount dit account moet kunnen wijzigen, dan kan dat dus niet…
Zou dit dan een goede reden zijn om beheerders een separaat gebruikers- en beheeraccount te geven
(en dus niet je beheeraccounts als standaardaccount gebruiken….)

(Nu kun je natuurlijk vast de default rechten van de adminSDHolder container wijzigen, of het serviceaccount domweg lid maken van
domain admins, maar laat ik verder niet ingaan op de wenselijkheid van dat soort ‘oplossingen’…)

Kortom, je bent nu op de hoogte van het bestaan en de werking van het adminSDHolder proces.
Heb je direct een goede reden om beheer- en dagelijks gebruik te scheiden middels separate accounts…
(voor diegenen die dat al deden: Goed bezig!)

BIJLAGE: Lijst protected groepen.

De volgende groepen zijn standaard ‘protected’

In Windows 2000 voor SP4: (Gebruikt iemand dat nog???)

Enterprise Admins
Schema Admins
Domain Admins
Administrators

Windows Server 2000 SP4 of hoger:

Enterprise Admins
Schema Admins
Domain Admins
Administrators
Account Operators
Server Operators
Print Operators
Backup Operators
Cert Publishers

Voor Windows Server 2008 (R2) extra toegevoegd:

Read Only Domain Controllers

De volgende gebruikers zijn ook standaard protected.

Administrator
Krbtgt (in 2003 geïntroduceerd, in 2008 R2 weer verdwenen.)

NB: Het is (tot op zekere hoogte) mogelijk om te bepalen welke groepen protected zijn.
Kijk HIER voor meer informatie daarover.

Certificaat request maken zonder IIS

Martijn Bellaard — Wed, 06 Jan 2010 11:20:15 GMT

Als ik een TMG implementatie doe en ik moet een SSL website publiceren, dan moet ik beschikken over een prived key van de SSL website. Het komt dan soms voor dat een certificaat opnieuw moet worden aangevraagd. Het aanvragen van een certificaat kan leiden tot wat uitdaging. Vaak wordt zo een certificaat gemaakt op een IIS server. Maar als je geen IIS server tot je beschikking hebt dan is dat lastig. Nu kun je er voor kiezen om IIS op TMG te installeren, maar dit is geen optie.

Het wordt nog lastiger als je een certificaat wilt hebben voor bijvoorbeeld IPSec of code signing. Hiervoor kun je dan gebruik maken van speciale tools, maar deze moet je dan wel net tot je beschikking hebben.

Maar gelukkig is er een andere mogelijkheid. In deze blog behandel ik deze optie voor SSL. Het is ook mogelijk om voor ander zaken een certificaat aan te vragen.

Als eerste log je aan op een Windows 7 werkstation of Windows 2008 (R2) server.
Start een nieuwe MMC op.
Laadt de certificaten snap-in

File è Add/Remove Snap-in
Selecteer Certificates è ADD
OK en Finish

Je kunt deze aanvraag vanuit de gebruiker doen.

Selecteer Personal
Action, All Tasks, Advanced Operations, Create Custom Request
Op het eerste scherm: Next
Selecteer: Proceed without enrollment policy

Nu kun je kiezen uit twee “templates”

(No template) CNG Key
(No template) Legacy Key

CNG key is een “nieuwe” manier voor het opslaan van de sleutels (certificaten). Deze methode heb je alleen op Windows Vista of hoger (http://msdn.microsoft.com/en-us/library/bb931355(VS.85).aspx). We kiezen voor CNG en gaan het opslaan als een PKCS #10 formaat. Hierbij geldt wel dat de CA waar je het certificaat gaat aanvragen dit formaat moet ondersteunen.

Nu komt het “lastige” gedeelte. We moeten nu zelf gaan aangeven waar de key voor dient.

Klik op “Details”
Properties

We gaan nu de properties van het certificaat invullen.

Tabblad General

Friendly name: Een naam voor het certificaat. Maakt niet uit wat.

Tabblad Subject

Subject name

Type: Common Name
Value: De URL van de website

Tabblad Extensions

Key Usage: Digital signature
Extended Key Usage (Application policies): Server Authentication
Basic Constraints: Enable this extension, de rest laten we default

Tabblad Private key

Key Options: Make private key Exportable, we willen hem later kunnen exporteren en importeren op andere server. Je kunt hier ook kiezen voor een grote Key size. Default is 102.

We zijn nu klaar met alles invullen, druk op OK
Next
Sla het nu op als Base 64 bestand.

Nu heb je een request file zoals deze door bijvoorbeeld IIS wordt gemaakt. Hiermee kun je naar je eigen SSL provider gaan en een certificaat request doen. Het bestand dat je terug krijgt importeer je weer op dezelfde computer als waar je het request hebt gemaakt. Nu kun je de private key exporteren en ergens anders importeren.

Martijn Bellaard