[Certificate services] LDAP authenticatie over SSL

[Kokkers]

(Onduidelijk of dit topic in 'Windows Operated Systems' of in 'Systeem- en Netwerkbeheer' kan)

Achtergrond:
De wens bestaat hier om centraal de toegang tot onze linux clients te kunnen beheren. De wildgroei van losse accounts en bijkomende onoverzichtelijkheid zijn hiervoor goede argumenten.
Authenticatie via LDAP zou hier bij uitstek geschikt voor moeten zijn.

Om niet nog meer servers te hoeven beheren is er gekozen om Microsoft Active Directory (toekomstige office omgeving) in te zetten als LDAP server. Met de schema extenties van 'MS services for Unix' zou AD minstens zo geschikt moeten zijn als bijvoorbeeld OpenLDAP. Na wat hobby'en kan ik inmiddels vanaf een linuxbak een query doen naar de LDAP tree. Via pluggable authentication modules (PAM) routeer ik de authenticatie voor SSH bijvoorbeeld naar de LDAP server. Na enig configuratiewerk van ldap.conf kan ik vervolgens met SSH inloggen op de linuxmachine m.b.v. mijn AD account.
Met behulp van de grouprequired parameter in de LDAP client kun je zo bijvoorbeeld iedereen in de AD lid van een bepaalde groep in laten loggen via SSH.

In verschillende tutorials wordt er gewaarschuwd dat LDAP verkeer als plain text over het netwerk gaat hetgeen een netwerksniffer inderdaad snel bevestigd. Een beveiligde verbinding via TLS/SSL zou voldoende veiligheid moeten bieden.

Als een domaincontroller uitgerust wordt met 'Certificate services' accepteert deze beveiligde LDAP query's op poort 636.
Hierna kan het automatisch aangemaakt 'self-signed' servercertificaat geexporteerd worden naar de client en mits de certificaat informatie volledig is kan er een beveiligde verbinding opgezet worden, LDAP over TLS / SSL.

Probleem:

LDAP authenticatie naar een enkele DC is een vervelend single point of failure, als de DC tijdelijk niet bereikbaar is kun je op geen enkele client meer inloggen (afgezien van lokaal noodaccount). Er is in de LDAP client fallback mogelijk naar een andere LDAP server, een tweede domaincontroller bijvoorbeeld. Echter van deze DC moet vervolgens ook een certificaat aanwezig zijn.

Een voorbeeld overzicht:



Linuxclient heeft als LDAP servers DC_1 en DC_2
SSL/TLS ingeschakeld

DC_1 is standalone root CA
DC_2 is sub-ordinate CA van DC_1

'Server certificate' export van DC_1 naar linux client
'Server certificate' export van DC_2 naar linux client

Ik lees op verschillende plekken dat het afgeraden wordt om het certificaat van de root CA uit geven naar clients. Het lijkt mij echter een beetje overbodig om een derde machine in het leven te roepen als root CA en vervolgens de 2 DC's subordinate te maken en hiervan de certificaten uit te geven / exporteren.

Wat zou voor mij een gunstige Certificate setup zijn als ik uitga van 2 DC's waar de authenticatie plaats kan vinden?

Daarnaast vraag ik me af wat voor mij de meerwaarde zou zijn van een Enterprise root CA

Na wat speelwerk en installatie en de-installatie van Certificate services was mijn testomgeving een zooitje. Na een quick reinstall wil ik het nu graag goed doen.

Tips, opmerkingen en advies van mensen die kijk hebben op de genoemde situatie zijn meer dan welkom!

[ Voor 3% gewijzigd door Kokkers op 07-06-2006 16:09 ]

[Kokkers]

Nog maar een subtiel schopje, niemand een idee?

[BlaTieBla]

Als je puur en alleen die certificate services gebruikt voor het verstrekken voor de door jouw geschetste situatie zie ik niet in waarom je subordinate CA zou moeten gebruiken. Netjes is het niet, maar het werkt wel gewoon.

Neem 1 van de DC's en richt dien in als Enterprise CA. Auto-enroll (via een GPO) de server certificaten voor de DC's zodat ze SSL kunnen 'bedrijven'.
Exporteer het CA certificaat en importeer dat op de linux machine. Doordat het root certificaat vertrouwd wordt, zullen ook de uitgegeven certificaten van de DC's vertrouwd worden. Voordeel hiervan is dat je niet ieder jaar je linux doos moet voorzien van de nieuwe DC's certificaten. Je linux applicatie moet wel daarmee overweg kunnen. Een beetje PKI enabled applicatie kan dat zonder problemen.

Met een enterprise CA en auto-enroll worden de DC certificaten netjes automatisch ieder jaar vervangen dus daar heb je in principe geen omkijken naar.

[ Voor 5% gewijzigd door BlaTieBla op 11-04-2006 17:53 ]

[elevator]

Windows Operating Systems >> Systeem- en Netwerkbeheer

[Verwijderd]

Is certificate services clusterbaar? Zo ja, dan kan je een high availability cluster maken.
Je zou ook kunnen kijken naar een eDirectory oplossing op een Windows of Linux omgeving (of native Netware draaien uiteraard ). Ik weet niet of AD hetzelfde ondersteund namelijk. Je kan eDirectory in dit geval licentieloos gebruiken omdat je er niet via een Novell client of FTP op authenticeert, maar je gebruikt alleen de eDirectory credentials, er wordt geen permanente verbinding mee gelegd). Novell propageert het gebruik van eDirectory ook op deze manier. Ook netware is in dit geval gratis te gebruiken op een oneindig aantal servers(licentiemodel van Netware 6.5 en hoger).

eDirectory is standaard LDAP enabled, zowel secure als unsecure. Je kan via round robin meerdere IP's aan dezelfde hostname hangen, en één certificaat maken wat je aan beide LDAP server objecten koppelt, óf je maakt een cluster en geeft het master resource IP op als LDAP server.
Daarnaast kan je een LDAP proxy gebruiker definiëren, waardoor de veiligheid nog hoger wordt. Alleen met de credentials die deze gebruiker meegeeft kan er een search uitgevoerd worden binnen je eDirectory. Wij maken zelf ook op deze manier gebruik van Linux authenticatie naar eDirectory met PAM.

[BlaTieBla]

Certificate server clusterbaar is niet echt nodig. De services worden alleen gebruikt bij het uitgeven of intrekken van certificaten of voor het creeeren van de CRL. Die CRL wordt standaard gepubliceerd in de AD (is dus al redundant bij meerdere DC's)

Als in dit geval de certificate server eruit ligt, dan is er niets aan de hand. De linux doos kan gewoon bij de DC's komen voor de LDAP queries. Downtime van een dag moet geen problemen opleveren.

[ Voor 11% gewijzigd door BlaTieBla op 11-04-2006 19:27 ]

[JackBol]

ias installeren en de ssh tegen radius authenticeren, vervolgens de ias loadbalancen kan ook...

[Kokkers]

Ik wilde dit varkentje echt gaan wassen m.b.v. LDAP dus Radius is geen optie.
In een andere situatie gebruiken we hier wel radius i.s.m. IAS en dit werkt overigens prima.

De oplossing en vooral de uitleg van BlaTieBla heeft voor mij het kwartje laten vallen.
Jullie reakties worden erg op prijs gesteld!

Ik heb een van de DC's uitgerust als Enterprise root CA.
Group policy van de OU Domain controllers aangepast en Autoenrollment settings uitgebreid.

Na een herstart van beide DC's worden er automatisch servercertificaten uitgedeeld aan beide DC's . Met het servercertificaat op basis van het 'Domain controller authentication' template worden op de betreffende DC SSL connecties op poort 636 toegestaan.
Na uitgifte van de servercertificaten aan de DC's kan de ROOT CA weer uitgeschakeld worden. Deze is pas weer nodig als de servercertificaten verlopen en kan dan ingeschakeld worden.

Vervolgens heb ik het Root CA certificaat gexporteerd naar de linuxclient en met wat speelwerk kan ik nu naar beide DC's query's doen via TLS/SSL.

Helaas ben ik er nog net niet en zit ik nog met een vraagje:

Mijn rootCA heeft als FQDN CN=rootca, DC=testdomain DC=nl
Mijn AD domain heeft als DNS suffix testdomain.local

Het probleem is nu dat een certificaat automatisch via de AD ge-issued wordt aan:
DC1.TESTDOMAIN.LOCAL

Van 'buitenaf' is de DC bekend als DC1.TESTDOMAIN.NL
Als ik vanaf de linuxbak een TLS/SSL query doe naar DC1.TESTDOMAIN.NL
Krijg ik een "TLS: unable to get CN from peer certificate" terug.
(linux commandline: ldapsearch -x -H ldaps://dc1.testdomain.nl)

Niet zo gek want het servercertificaat is via de AD automatisch uitgegeven aan DC1.TESTDOMAIN.LOCAL

Logischerwijs kan en wil ik geen .LOCAL extentie gebruiken om vanaf mijn linuxmachines de AD te raadplegen.

Zit er niets anders op dan mijn AD domein te hernoemen van .LOCAL naar .NL?

[ Voor 10% gewijzigd door Kokkers op 13-04-2006 15:46 ]

[BlaTieBla]

hmmmm... da's een leuke.
Er is wel een weg omheen, maar daar is user input voor nodig. Het certificaat wordt aangevraagt op basis van de interne (AD) naam van de machine.
Als je ook webenrollment heb geinstalleerd bij de Enterprise CA, dan kan je een certificaat met de hand aanvragen (via http://SERVERNAAM/certsrv). Nu kan je wel de naam gebruiken die je wilt. Nadeel is dat via die weg er geen automated renewal plaats vindt.

Je kan ook via de MMC (certificate snapin voor de local computer) een certificaat aanvragen voor je server, maar ik weet niet of je daar nog de mogelijkheid heb om de common name te wijzigen. Als ik het goed heb, is dat een wizard die niet al te veel vragen stelt.