Grenzen der Microsoft Active Directory Certificate Services

Autor Uwe GradeneggerVeröffentlicht am Kategorien Active Directory, Hochverfügbarkeit, Online Certificate Status Protocol (OCSP), Registrierungsdienst für Netzwerkgeräte (NDES), Security, Windows Betriebssystem, Zertifikatregistrierungs-Webdienste, Zertifizierungsstelle, Zertifizierungsstellen-Cluster, Zertifizierungsstellen-Datenbank, Zertifizierungsstellen-Webregistrierung (CAWE)

Die Active Directory Certificate Services bestehen (wenn auch unter anderem Namen) in ihren Grundzügen seit Windows NT 4.0. Die heutzutage verwendete auf Active Directory besierende Architektur wurde mit Windows 2000 Server eingeführt. Die AD CS sind sehr gut in das Windows-Ökosystem integriert und erfreuen sich weiterhin weltweit großer Beliebtheit in Unternehmen und Behörden jeglicher Größenordnung.

Gerne wird auf die vielen Möglichkeiten hingewiesen, welche die Active Directory Certificate Services bieten. Selten wird allerdings darauf verwiesen, was mit ihnen nicht möglich ist. Das Produkt stößt nämlich mittlerweile an vielen Stellen auch an seine Grenzen.

Welche das sind, soll nachfolgend näher ausgeführt werden, um besser entscheiden zu können, ob die AD CS für geplante Vorhaben die richtige Lösung sein können.

Allgemein

Das Produkt ist nicht quelloffen, die (Weiter-)Entwicklung findet somit hinter verschlossenen Türen statt und ist nach außen nicht transparent. Die Produktdokumentation ist teils veraltet, unvollständig und verteilt über viele verschiedene Medien (u.A. auch Bücher, nur noch über Archive verfügbare Artikel, sowie einzelne Blogs).

Stand heute (2022) findet keine bekannte aktive Weiterentwicklung des Produktes durch Microsoft mehr statt (im jüngst erschienenen Windows Server 2022 Release wurde an AD CS genau gar nichts geändert. Sicherheitsupdates werden nur halbherzig eingepflegt). Teilweise werden nicht einmal seit Jahren bekannte Bugs behoben.

Dadurch sind mittlerweile viele Einschränkungen und notwendige Workarounds notwendig, die Zukunftssicherheit ist somit zumindest fragwürdig.

Es ist aktuell von Microsoft auch kein Ersatz- oder Folgeprodukt als Cloud-Service in Microsoft Azure verfügbar oder angekündigt.

Aktuell ist auch keine bekannte Planung für den Umgang mit dem Thema Post-Quantum Kryptographie (composite/hybride Zertifikate) in Verbindung mit den AD CS bekannt, die Kryptoagilität ist eingeschränkt aufgrund der Abhängigkeit zu den Crypto-Bibliotheken im Windows-Betriebssystem. Moderne Algorithmen wie EdDSA (insbesondere für IoT Anwendungsfälle interessant, hier sind andere bereits weiter) sind mit AD CS nicht verwendbar.

Der Microsoft-nahe Autor Roger A. Grimes schreibt in seinem Buch "Cryptography Apocalypse", dass Microsoft die AD CS zumindest erfolgreich mit (experimentellen) quantenresistenten Algorithmen getestet hat, sodass diese genutzt (d.h. vermutlich, in eine neue Version des Produktes integriert) werden könnten sobald es erforderlich ist (und der Standardisierungsprozess abgeschlossen ist).

Zertifizierungsstelle

Design

Aus Sicht der PKI-Technologie ist es problemlos möglich, mehrere Zertifizierungsstellen auf dem gleichen Server zu betreiben. Hersteller wie Nexus oder PrimeKey machen dies bereits erfolgreich vor, das gleiche gilt für Open Source Projekte wie OpenSSL oder OpenXPKI.

Aufgrund der Bindung an die Kerberos-Identität des Zertifizierungsstellen-Servers ist es bei den Active Directory Certificate Services allerdings erforderlich, pro logischer Zertifizierungsstelle eine komplette Windows Server Instanz zu betreiben.

Ebenso ist mindestens eine Zertifizierungsstelle pro Active Directory Gesamtstruktur (Forest) erforderlich (Anm. um dieses Problem zu adressieren gibt es Drittanbieter-Lösungen).

In Folge gilt das gleiche auch für verschiedene Kombinationen aus Hashverfahren (z.B. SHA-1 für Legacy Anwendungen parallel zu einer Hierarchie, welche moderne Algorithmen verwendet) und Schlüssel-Arten (RSA, ECC).

In großen Unternehmen ist es üblich, dass Zertifizierungsstellen pro Einsatzzweck aufgeteilt und eingeschränkt werden, und ebenso dass es mehrere Active Directory Umgebungen sowie Zertifizierungsstellen-Hierarchien gibt, was zwangsläufig zu einer unnötig großen Anzahl von Zertifizierungsstellen-Servern führt, die alle verwaltet, gehärtet, aktualisiert, gepflegt und letztendlich auch bezahlt werden müssen.

Nicht nur, aber insbesondere bei Offline-Zertifizierungsstellen ist dies sehr ärgerlich, da auch für diese je ein eigener Server benötigt wird, und diese Server trotz des geringen Zertifikatvolumens aufgrund des fehlenden zentralen Management einen besonders hohen relativen Arbeitsaufwand erzeugen.

Aber auch die Konfiguration von Online-Zertifizierungsstellen kann (wo sinnvoll) nur mit viel Aufwand zentralisiert vorgenommen werden (beispielsweise mit PowerShell Desired State Configuration (DSC). Es gibt zwar entsprechende Projekte, die die benötigte Funktionalität bislang aber nur in Teilen abbilden).

Auch ein Generationenwechsel zwischen mehreren Hierarchien ist der gleichen Einschränkung unterworfen und erzeugt während dem Übergang eine unnötig große Anzahl an Servern.

Der Betrieb von Windows-Servern sollte eigentlich nicht zur hauptsächlichen Beschäftigung von PKI-Betreibern gehören. Der durch die nicht mehr zeitgemäße Architektur erzeugte Overhead (Betriebssystem, Managementkomponenten, Antivirus, Scripts) steigt sehr schnell enorm und erzeugt neben einer hohen Systemlast auch entsprechende Kosten und einen vermeidbaren negativen ökologischen Fußabdruck.

Die verwendete "Key Storage Provider" Schnittstelle ist vom Design nicht für die Verwendung mit Netzwerk-Appliances ausgelegt. Verwendet man beispielsweise ein Netzwerk-Hardware Security Modul (HSM) und die Verbindung zu diesem wird kurz unterbrochen, ist der Zertifizierungsstellen-Dienst nicht mehr in der Lage, den privaten Schlüssel der Zertifizierungsstelle zu verwenden, Zertifikatanträge schlagen entsprechend fehl und Sperrlisten können nicht mehr ausgestellt werden, bis der Zertifizierungsstellen-Dienst neu gestartet wird.

Trennung von Zertifizierungsstelle (CA) und Registrierungsstelle (RA)

Es ist keine saubere Trennung von Zertifizierungsstelle und Registrierungsstelle gegeben:

  • Die Zertifikatbeantragung über RPC/DCOM ist nur direkt gegen die Zertifizierungsstellle möglich, damit muss eine Online-Zertifizierungsstelle allen Clients im Netzwerk gegenüber exponiert werden, was ein erhöhtes Sicherheitsrisiko darstellen kann.
  • Die Entscheidung, ob ein Zertifikat ausgestellt werden soll oder nicht wird direkt auf der Zertifizierungsstelle getroffen, nicht auf einer vorgeschalteten Registration Authority.
  • Der Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES) wird gerne als Registration Authority bezeichnet, erfüllt die Kriterien an eine solche allerdings nicht. Er kann Zertifikatanforderungen nicht in ausreichender Weise überprüfen und vorfiltern. NDES ist eher eine Protokollumwandlung als eine echte RA. Solche Zertifikatanforderungen könnten allerdings über ein selbst entwickeltes Policy Modul wie TameMyCerts auf Seite der Zertifizierungsstelle (überwiegend) abgefangen werden.
  • Gleiches gilt für die Zertifizierungsstellen- Webregistrierung (CAWE).
  • Die Zertifikatregistrierungs-Webdienste (CEP und CES) erfüllen die Kriterien an eine Registration Authority ebenfalls nicht, da Zertifikatanforderungen ungeprüft weitergegeben werden und erst vom Policy-Modul der Zertifizierungsstelle, d.h. direkt von dieser, bewertet werden, d.h. hierbei handelt es sich ebenfalls eher um eine Protokollumwandlung als eine richtige Registration Authority.

Es gibt keine Unterstützung für die Implementierung einer echten Hochverfügbarkeit (siehe Abschnitt Zertifizierungsstellen-Datenbank). Damit ist das Produkt eigentlich nicht "Enterprise-tauglich".

Installationsroutine

Die hart kodierten Standardeinstellungen während der Installation bzw. Rollen-Konfiguration…

  • …erfordern Enterprise Administrator Berechtigungen für die Installation der Zertifizierungsstelle (siehe hier auch Abschnitt zum Thema Zertifikatvorlagen). Im Fall der Zertifizierungsstelle kann die Berechtigung delegiert werden, für NDES gibt es einen inoffiziellen Workaround, im Fall von CEP/CES besteht aber keine Chance, daher ist der Einsatz in sicherheitsbewusstem Unternehmens-Umfeld unter Umständen nur eingeschränkt oder überhaupt nicht möglich.
  • …erlauben jeder installierten Zertifizierungsstelle die Ausstellung von Anmeldezertifikaten für das Active Directory durch Eintragung des Zertifizierungsstellen-Zertifikats in das NTAuthCertificates Objekt. Dies kann zwar im Nachhinein geändert werden, widerspricht aber dem Secure by Design, Secure by Default Prinzip.
  • …binden die Standard-Zertifikatvorlagen zur Ausstellung direkt nach der Installation, sofern während der Installation nicht explizit unterbunden, so dass große Gefahr besteht, dass direkt nach der Installlation ungewollte/unverwaltete Zertifikate ausgestellt werden (zu diesem Zeitpunkt hat noch keine Konfiguration beispielsweise von CDP/AIA und kein Funktionstest stattgefunden).
  • …gibt die Windows-Firewall in der Standardeinstellung auch für die Remote-Administrations-Schnittstellen der Zertifizierungsstelle frei, was die Angriffsoberfläche unnötig erhöht.

Active Directory Integration und Zerifikatvorlagen

Die Zertifikatvorlagen sind im Active Directory gespeichert. In großen Umgebungen müssen diese oft per manuellem Antrag von einem anderen Team erzeugt werden, was Automatisierung verhindert und Abläufe verlangsamt.

Es gibt keine offizielle Methode, um die Erstellung und Bearbeitung von Zertifikatvorlagen zu scripten, d.h. zu automatisieren. Auch wenn es inoffizielle Wege, sogar von (ehemaligen) Microsoft-Mitarbeitern selbst gibt, stellt sich Microsoft auf den Standpunkt, dass dieses Vorgehen nicht getestet wurde und entsprechend keine Produktunterstützung erfahren kann.

Es können keine individuellen AIA/CDP Adressen über Einstellungen der Zertifikatvorlagen definiert werden. Die Konfiguration gilt immer global für alle ausgestellten Zertifikate einer Zertifizierungsstelle, obwohl dies technisch auf die jeweiligen Zertifikatypen heruntergebrochen werden könnte. Wird hier eine Unterscheidung benötigt, muss eine weitere Zertifizierungsstelle etabliert werden (siehe Abschnitt "Design").

Nicht in das Active Directory integrierte ("Standalone") Zertifizierungsstellen besitzen überhaupt keine Möglichkeit, Zertifikatprofile analog zu den im Active Directory gespeicherten Zertifikatvorlagen zu definieren.

LDAP-Sperrlisten können maximal 10 MB groß sein (aufgrund einer Limitierung in Active Directory).

Die Administration der Zertifizierungsstellen ist an die Active Directory Konten der jeweiligen Gesamtstruktur gebunden. In großen Unternehmens-Umgebungen, welche über mehrere Active Directory Gesamtstrukturen verfügen (und sei es nur, weil es auch noch eine Test- und Staging-Umgebung gibt) sind die Administratoren der PKI also gezwungen, mehrere Benutzerkonten für verschiedene Umgebungen zu verwenden (sofern keine Vertrauensstellung zwischen den Umgebungen eingerichtet ist) und die Zertifizierungsstellen sind nicht zentral (d.h. über mehrere Active Directory Gesamtstrukturgrenzen hinweg) verwaltbar (wenn – wie meist üblich – keine Vertrauensstellung eingerichtet ist).

Für die Authentisierung und Zertifikatbeantragung über eine Vertrauensstellung hinweg muss diese gegenseitig sein.

Da die Zertifizierungsstellen-Server Mitglied des Active Directory sind, können diese auch auf vielfältige Weise (Gruppenrichtlinien, Anmeldung von unberechtigten Konten mit Administrator-Rechten, kompromittierte Dienstkonten) durch dieses kompromittiert werden.

Gleiches gilt für Sperrlistenveröffentlichung und Beantragung der OCSP-Antwortsignaturzertifikate. Diese werden mit den Active Directory Mechanismen authentifiziert, sodass die (oft mit dem Internet verbundenen) sicherheitskritischen Sperrlisten/OCSP-Server sich in der Regel in der gleichen Active Directory Gesamtstruktur befinden wie die Zertifizierungsstellen und oft auch mit dem gleichen Konten administriert werden. Somit ist die Gefahr erhöht, dass eine Kompromittierung eines Sperrlisten/OCSP-Servers auf die Zertifizierungsstellen übergreift.

Außerdem muss für den OCSP-Responder (möchte man die automatische Beantragung und Erneuerung des OCSP-Antwortsignaturzertifikats einsetzen) in jeder Active Directory Gesamtstruktur eine eigene (sinnvollerweise hochverfügbare) Instanz des Onlineresponders implementiert werden.

Die Zertifikatbeantragung per RPC/DCOM mit und ohne AutoEnrollment bricht die Identifikation des Antragstellers auf seine Kerberos-Identität (dessen Windows-Anmeldung) herunter. Da diese in der Regel wiederum nur durch Eingabe von Benutzername und Kennwort erfolgt, ist die Identifikation des Antragstellers eines Zertifikats durch die Zertifizierungsstelle letztendlich nicht stärker, als dass Kenntnis einer Benutzername/Passwort-Kombination überprüft wurde.

Zertifizierungsstellen-Datenbank

Die Anzahl von ausstellbaren Subject Alternative Names ist beschränkt: Zertifikaterweiterungen können in Summe maximal 4 KB groß sein (aufgrund Limitierung der Zertifizierungsstellen-Datenbank)

Die Zertifizierungsstellen-Datenbank kann maximal 2.147.483.647 Zertifikate verwalten (32-Bit bzw. 4 Byte Integer mit Vorzeichen, Limitierung des Datenbankschemas). Effektiv wird die Zertifizierungsstellen-Datenbank mit zunehmender Größe allerdings immer träger bei Abfragen, sodass sie sich (wenn überhaupt) kaum für mehr als einige wenige Millionen Zertifikate eignet.

In Hinsicht auf den Datenschutz ist anzumerken, dass es auch kein automatisches Housekeeping für abgelaufene Zertifikate gibt (um den Anforderung an die Löschung personenbezogener Daten bei Wegfall des Zweckes der Erhebung) gerecht zu werden. Ein solches Vorhaben ist nur per Script umsetzbar.

Die Zertifizierungsstellen-Datenbank (Microsoft JET Blue Engine) ist monolithisch pro Server implementiert, sie kann nicht über mehrere Zertifizierungsstellen konsolidiert werden und muss direkt auf den jeweiligen Zertifizierungsstellen-Servern betrieben werden.

Die Zertifizierungsstellen-Datenbank erlaubt Datenbankabfragen nur mit den bereitgestellten proprietären Schnittstellen und das auch nur in begrenztem Umfang, diese skalieren bei großen Datenmengen allerdings nicht gut und erfordern Workarounds, um sinnvoll verwendet werden zu können. Zu viele gleichzeitig laufende Abfragen gegen die Zertifizierungsstellen-Datenbank können sogar die Zertifikat- und Sperrlistenausstellung blockieren.

Sie erlaubt nicht, nach leeren Feldern (z.B. einem leeren Common Name) zu suchen. Die einzige Möglichkeit ist hier, alle Datensätze auszulesen und beispielsweise mit der Windows PowerShell nach solchen Einträgen zu suchen. Mit zunehmender Größe der Datenbank werden solche Exporte aber immer langsamer und Zeitaufwändiger, sodass sie mit Bordmitteln teils gar nicht mehr realisiert werden können.

Nicht definierte Relative Distiguished Names (RDNs), sofern solche erlaubt sind und verwendet werden, werden nicht in der Zertifizierungsstellen-Datenbank indexiert.

Sie speichert/indexiert auch keine in Subject Alternative Names enthaltenen Identitäten, diese sind nur durch Auslesen der Zertifizierungsstellen-Datenbank und programmatisches Auswerten der dadurch erhaltenen Zertifikats-Rohdaten möglich. Gleiches gilt für die im Mai 2022 hinzugefügte neue proprietäre Zertifikaterweiterung, welche angeblich die Sicherheit steigern soll, aber in offline-Zertifikatvorlagen unerkannt durchgereicht wird.

Die Zertifizierungsstellen-Datenbank erlaubt keine erweiterten Datenbankabfragen wie es z.B. bei einem relationalen Datenbanksystem wie einem SQL-Server der Fall wäre.

Die Zertifizierungsstellen-Datenbank erlaubt keine Speicherung oder Verknüpfung von Metainformationen (z.B. eine E-Mail Addresse des Zertifikatinhabers oder für eine Abrechnung der Leistung erforderlichen Daten) bei manueller Zertifikatbeantragung oder generell die Erweiterung des Datenbankschemas.

Die Zertifizierungsstellen-Datenbank erlaubt keine Datenbankreplikation für ein echtes Clustering (in der vorhandenen Cluster-Implementierung kann und darf immer nur ein Cluster-Knoten über das Dateisystem auf die Datenbank-Dateien zugreifen, andernfalls kommt es sehr schnell zu Datenkorruption, welche der angestrebten Hochverfügbarkeit diametral im Wege steht).

Zertifizierungsstellen-Dienst

Änderungen an der Konfiguration einer Zertifizierungsstelle erfordern einen Neustart des Dienstes mit entsprechender Unterbrechung der Verfügbarkeit (vgl. auch Thema Clustering).

Policy Modul

Das mitgelieferte Windows Default Policy-Modul erlaubt keine Definition von Regeln für manuelle Zertifikatanforderungen. Dadurch entstehen sehr häufig Fehler bei Zertifikataussstellungen (vergessene Attribute, Syntaxfehler werden nicht erkannt, mehrere CN sind möglich, Falschausstellungen mit sicherheitsrelevanten Auswirkungen etc…).

Der Funktionsumfang des Policy Moduls der Zertifizierungsstelle ist nicht direkt erweiterbar. Immerhin existieren Codebeispiele um eigene Policy Module zu entwickeln.

Mit TameMyCerts liegt mittlerweile ein Policy Modul unter einer Open Source Lizenz vor, welches den Funktionsumfang des Windows Default Policy Moduls deutlich erweitert und dabei die vom originalen Modul bereitgestellte Basisfunktionalität beibehält.

Schnittstellen

Die Active Directory Certificate Services bieten Stand heute keine Unterstützung für folgende Schnittstellen:

Somit bleibt als einzig vernünftig nutzbare Schnittstelle zur Zertifikatbeantragung in den meisten Fällen lediglich RPC/DCOM übrig – eine proprietäre Schnittstelle, die vor über 20 Jahren für On-Premise Infrastrukturen entworfen wurde und nicht annähernd für eine Cloud-native Welt optimiert ist. Die Schnittstelle ist zudem auf Active Directory Authentisierungsverfahren beschränkt und zwingt die Zertifizierungsstellen in das Active Directory Ökosystem.

Die vorhandenen Schnittstellen zur Protokollumwandlung leiden auch unter nicht wenigen Einschränkungen.

Registrierungsdienst für Netzwerkgeräte (NDES)

Die als Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES) bekannte Implementierung des Simple Certificate Enrollment Protocol (SCEP) leidet unter folgenden Einschränkungen:

  • Es ist nicht möglich, Richtlinien für die Zertifikatbeantragung (z.B. erlaubte Zertifikatinhalte) zu definieren (allerdings ist eine API für die eigene Implementierung eines Policy Moduls vorhanden, für die allerdings keine Codebeispiele oder Stubs von Microsoft verfügbar sind).
  • Pro Kombination aus Zertifizierungsstelle, Zertifikatvorlage und (NDES-)Passwortrichtlinie ist die Installation einer eigenständigen Windows-Server Instanz notwendig. In größeren Umgebungen wird also – ebenso wie bei Zertifizierungsstellen – die Anzahl der zu betreibenden Server unnötigerweise wachsen. Sehr irritierend ist, dass Microsoft mit Intune sich und seinen Kunden ebenfalls dieser Einschränkung unterwirft.
  • NDES ist im Allgemeinen nicht sinnvoll für Hochverfügbarkeit konfigurierbar, da kein Replikationsmechanismus für die ausgegebenen Einmalkennwörter existiert.
  • NDES ist in Hinsicht auf die Schnittstellen für die verwendeten Registration Authority Zertifikate noch in der Cryptographic Service Provider (CSP) Welt unterwegs, für diese werden deshalb auch zwangsläufig keine elliptischen Kurven unterstützt.
  • NDES erfordert unnötigerweise, dass die Installation mit Enterprise Administrator Rechten erfolgt. In sicherheitsbewussten Unternehmens-Umgebungen wird diese Berechtigung (zu Recht) nicht herausgegeben, entsprechend kann die Rolle nicht (oder nur über einen Workaround, welcher allerdings offiziell die Produktunterstützung verwirkt) eingesetzt werden.
  • Die für den Betrieb erforderlichen Registration Authority Zertifikate werden in der von Microsoft bereitgestellten Produktdokumentation überhaupt nicht eingesetzt.

Zertifikatregistrierungs-Webdienste (CEP/CES)

Die Zertifikatregistrierungs-Webdienste (CEP/CES) leiden unter folgenden Einschränkungen:

  • Sie unterstützen aufgrund eines bis heute nicht behobenen Bug keine Version 4 Zertifikatvorlagen.
  • CES erfordert während der Installation hart kodiert und entsprechend nicht delegierbar, dass der Benutzer Mitglied von "Enterprise Administrators" ist, was ein No-Go für sicherheitsbewusste Unternehmensumgebungen ist.

Zertifizierungsstellen-Webregistrierung (CAWE)

Ein brauchbarer webbasierter User Self Service ist ebenfalls nicht vorhanden. Die Zertifizierungsstellen-Webregistrierung (Certificate Authority Web Enrollment, CAWE) leidet unter folgenden Einschränkungen:

  • Sie ist hoffnungslos veraltet und wird seit numehr fast 20 Jahren nicht mehr aktiv weiterentwickelt.
  • Sie unterstützt keine Version 3 (oder neuer) Vorlagen.
  • Sie unterstützt keine Definition von Richtlinien für den Zertifikatinhalt (kann jedoch auch mit dem TameMyCerts Policy Modul mitigiert werden).
  • Eine Installation direkt auf der Zertifizierungsstelle ist aus Sicherheitsgründen nicht empfohlen, eine Installation auf einen separaten Server erfordert die Einrichtung von Kerberos Delegierung, was die Gefähr durch Kerberoasting drastisch erhöhen kann.

Validation Authority

Der Onlineresponder (OCSP) greift wiederum auf Sperrlisten zurück und nicht direkt die Zertifizierungsstellen-Datenbank. Es gibt allerdings Workarounds, die weiteren Pflegeaufwand nach sich ziehen.

Es ist keine Unterstützung für Server-Based Certificate Validation Protocol (SCVP) vorhanden.

Zertifikatmanagement

Von Microsoft wird zwar noch das Produkt FIM/MIM Certificate Management vertrieben, welches allerdings noch in der Cryptographic Service Provider (CSP) Welt zu Hause ist und gemäß aktuellem Kenntnisstandes keine neuen Funktionen mehr erhalten wird. Die Neu-Adoption von FIM/MIM CM ist in 2021 also eine Einbahnstraße.

Fazit

Das Gute ist, dass die AD CS einen verhältnismäßig einfachen Einstieg in das Themengebiet PKI ermöglichen und die meisten Anbieter von PKI-Software es ermöglichen, später bestehende Microsoft Zertifizierungsstellen in ihre Lösungen umzuziehen, wenn die gebotene Funktionalität nicht mehr ausreicht.

Aus meiner Sicht sind die glanzvollen Tage der AD CS allerdings angezählt, sodass ein möglicher Einsatz des Produktes in Hinsicht auf seine Zukunftsfähigkeit – insbesondere in größeren Umgebungen – kritisch betrachtet werden sollte.

Weiterführende Links:

Externe Quellen

de_DEDeutsch
en_USEnglish de_DEDeutsch