Die Umgebung für das Identitätsdepot muss entsprechend konfiguriert werden. Der Server muss beispielsweise mit einer Methode (einem Dienst oder einer bestimmten Datei) konfiguriert werden, mit der die Baumnamen im Identitätsdepot in Serververweisadressen aufgelöst werden können. In diesem Abschnitt erfahren Sie, wie Sie Ihre Umgebung auf die Installation des Identitätsdepots vorbereiten.
Sie können einen Windows-Server, dessen Name einen Punkt enthält, in einen Verzeichnisbaum aufnehmen. Beispiel: O=netiq.com oder C=u.s.a. Wenn der Name eines Containers im Baum einen Punkt („.“) enthält, müssen Sie jedoch ein Escape-Zeichen verwenden. Beachten Sie die folgenden Überlegungen:
Ein Servername darf nicht mit einem Punkt beginnen. Beispiel: .netiq.
Stellen Sie dem Punkt im Containernamen einen umgekehrten Schrägstrich („\“) voran. Beispiel:
O=novell\.com
Alternativ:
C=a\.b\.c
Wenn Sie Admin-Namen und Admin-Kontexte, die einen Punkt enthalten, für Dienstprogramme wie iMonitor, iManager, DHost iConsole, DSRepair, Backup, DSMerge, DSLogin oder ldapconfig eingeben, verwenden Sie jeweils ein Escape-Zeichen. Wenn Sie sich beispielsweise bei iMonitor anmelden und der Organisationsname im Baum netiq.com lautet, geben Sie entsprechend 'admin.netiq\.com' oder admin.netiq\.com ein.
Vor dem Installieren der Identitätsdepot-Infrastruktur muss der Server eine Methode (ein Dienst oder eine bestimmte Datei) aufweisen, mit der die Baumnamen im Identitätsdepot in Serververweisadressen aufgelöst werden können. NetIQ empfiehlt die Auflösung der Baumnamen mit SLP-Diensten (Service Location Protocol). Bei älteren Versionen von eDirectory wurde OpenSLP während der Installation mitinstalliert. Ab eDirectory 8.8 ist OpenSLP jedoch nicht mehr in der Installation enthalten. Sie müssen einen SLP-Dienst separat installieren oder eine hosts.nds-Datei verwenden. Wenn Sie einen SLP-Dienst nutzen, müssen die Verzeichnisagenten für den Dienst (SLPDAs) stabil sein.
Dieser Abschnitt enthält die folgenden Informationen:
Die Datei hosts.nds enthält eine statische Suchtabelle, in denen die Identitätsdepot-Anwendungen die Identitätsdepot-Partitionen und -Server suchen. Hiermit können Sie SLP-Multicast-Verzögerungen vermeiden, wenn kein SLP-DA im Netzwerk vorhanden ist. Geben Sie die folgenden Informationen für jeden Baum oder Server jeweils in einer eigenen Zeile in der Datei hosts.nds ein:
Servername oder Baumname: Die Baumnamen müssen mit einem Punkt (.) enden.
Internetadresse: Dies kann ein DNS-Name oder eine IP-Adresse sein. Verwenden Sie nicht localhost.
Serverport: Optional; hängen Sie die Port-Nummer bei Bedarf mit einem Doppelpunkt (:) an die Internetadresse an.
Für den lokalen Server müssen Sie nur dann einen Eintrag in die Datei vornehmen, wenn der Server einen nicht standardmäßigen NCP-Port überwacht.
So konfigurieren Sie eine hosts.nds-Datei:
Erstellen Sie eine neue hosts.nds-Datei, oder öffnen Sie eine bereits vorhandene Datei.
Fügen Sie die folgenden Informationen hinzu:
partition_name.tree_name. host_name/ip-addr:port server_name dns-addr/ip-addr:port
Beispiel:
# This is an example of a hosts.nds file: # Tree name Internet address/DNS Resolvable Name CORPORATE. myserver.mycompany.com novell.CORPORATE. 1.2.3.4:524 # Server name Internet address CORPSERVER myserver.mycompany.com:524
(Optional) Wenn Sie sich später entscheiden, den Baumnamen mit SLP aufzulösen und die Verfügbarkeit des Identitätsdepots im Netzwerk sicherzustellen, ergänzen Sie die Datei hosts.nds mit dem folgenden Text:
/usr/bin/slptool findattrs services:ndap.novell///(svcname-ws==[treename or *])"
Soll beispielsweise nach Diensten gesucht werden, deren Attribut svcname-ws mit dem Wert SAMPLE_TREE übereinstimmt, geben Sie den folgenden Befehl ein:
/usr/bin/slptool findattrs services:ndap.novell///(svcname-ws==SAMPLE_TREE)"
HINWEIS:Führen Sie diesen Vorgang aus, sobald SLP und das Identitätsdepot installiert wurden.
Wenn ein Dienst mit dem Wert SAMPLE_TREE für das Attribut svcname-ws registriert ist, erhalten Sie die Ausgabe service:ndap.novell:///SAMPLE_TREE (Beispiel). Ansonsten erfolgt keine Ausgabe.
OpenSLP ist eine Open-Source-Implementierung des Standards IETF Service Location Protocol Version 2.0 (dokumentiert in IETF Request-For-Comments (RFC) 2608).
Die Schnittstelle des OpenSLP-Quellcodes ist eine Implementierung eines weiteren IETF-Standards für den programmtechnischen Zugriff auf die SLP-Funktionen (dokumentiert in RFC 2614).
In diesen Dokumenten wird die Funktionsweise von SLP umfassend erläutert. Lesen Sie daher die Dokumente, und machen Sie sich mit den Funktionen vertraut. Die Dokumente sind relativ komplex, sind jedoch für die richtige Konfiguration von SLP in einem Intranet unerlässlich.
Weitere Informationen zum OpenSLP-Projekt finden Sie auf den Websites von OpenSLP und SourceForge. Auf der OpenSLP-Website finden Sie mehrere Dokumente mit nützlichen Tipps für die Konfiguration. Zum Zeitpunkt der Veröffentlichung dieses Dokuments ist der Großteil der Dokumente auf der Website noch unvollständig.
Dieser Abschnitt umfasst die folgenden Diskussionen über die Verwendung von SLP und das Verhältnis zum Identitätsdepot:
Die NetIQ-Version von SLP nimmt es nicht so genau mit dem SLP-Standard, damit eine robustere Umgebung für die Dienstbekanntgabe erstellt werden kann; dies geht allerdings zu Lasten der Skalierbarkeit.
Soll die Skalierbarkeit für ein Dienstbekanntgabe-Netzwerk erhöht werden, können Sie beispielsweise die Anzahl der Pakete begrenzen, die über ein Teilnetz per Rundsendung oder Multicast verteilt werden. In der SLP-Spezifikation werden hierzu die Verzeichnisagentenabfragen durch die Service- und Benutzeragenten eingeschränkt. Hierbei wird der zuerst ermittelte Verzeichnisagent, der für den gewünschten Bereich zuständig ist, für alle nachfolgenden Abfragen eines Service-Agenten (und damit auch der lokalen Benutzeragenten) zu diesem Bereich herangezogen.
Die NetIQ SLP-Implementierung durchsucht alle bekannten Verzeichnisagenten nach Abfrageinformationen. Eine Laufzeit von 300 Millisekunden gilt dabei als zu lang; somit können 10 Server in etwa 3 bis 5 Sekunden durchsucht werden. Dies ist nicht erforderlich, wenn SLP ordnungsgemäß im Netzwerk konfiguriert ist. (OpenSLP geht davon aus, dass das Netzwerk ordnungsgemäß für den SLP-Verkehr konfiguriert ist.) Die Zeitüberschreitungswerte für Antworten sind bei OpenSLP höher als beim SLP-Dienstanbieter von NetIQ, und die Anzahl der Verzeichnisagenten ist auf den zuerst antwortenden Agenten beschränkt, unabhängig davon, ob die Angaben dieses Agenten richtig und vollständig sind oder nicht.
Benutzeragenten (UA) treten physisch als statische oder dynamische Bibliothek auf, die mit einer Anwendung verknüpft ist. Die Anwendung kann dabei die SLP-Dienste abfragen. Der Benutzeragent bildet eine programmtechnische Schnittstelle, über die die Clients die Dienste abfragen und die Dienste sich selbst bekanntgeben. Ein Benutzeragent stellt eine Verbindung zu einem Verzeichnisagenten her und fragt registrierte Dienste einer bestimmten Dienstklasse in einem bestimmten Bereich ab.
Die Benutzeragenten ermitteln die Adresse des Verzeichnisagenten, an den die Abfragen gesendet werden sollen, mithilfe eines bestimmten Algorithmus. Sobald sie die Adresse eines Verzeichnisagenten (DA) für einen bestimmten Bereich erhalten, nutzen sie diese Adresse so lange für den entsprechenden Bereich, bis der Verzeichnisagent nicht mehr antwortet; anschließend ermitteln sie eine andere DA-Adresse für den Bereich. Die Benutzeragenten suchen wie folgt die Adresse eines Verzeichnisagenten für einen bestimmten Bereich:
Der Agent prüft, ob die Socket-Zugriffsnummer der aktuellen Anforderung mit einem DA für den angegebenen Bereich verbunden ist. Bei einer mehrteiligen Anforderung ist ggf. bereits eine Cache-Verbindung in der Anforderung vorhanden.
Der Agent prüft, ob sich im lokalen Cache der bekannten DAs ein DA befindet, der mit dem angegebenen Bereich übereinstimmt.
Der Agent sucht beim lokalen Service-Agenten (SA) nach einem DA mit dem angegebenen Bereich (und fügt neue Adressen zum Cache hinzu).
Der Agent fragt DHCP nach im Netzwerk konfigurierten DA-Adressen ab, die mit dem angegebenen Bereich übereinstimmen (und fügt neue Adressen zum Cache hinzu).
Der Agent sendet eine DA-Ermittlungsanforderung per Multicast über einen bereits bekannten Port (und fügt neue Adressen zum Cache hinzu).
Soweit nicht anders angegeben, gilt der Bereich „Standard“. Wenn also weder statisch in der SLP-Konfigurationsdatei noch in der Abfrage ein Bereich definiert ist, wird der Wert „Standard“ für den Bereich verwendet. Beachten Sie außerdem, dass das Identitätsdepot unter keinen Umständen einen Bereich in den Registrierungen angibt. Ist ein statisch konfigurierter Bereich vorhanden, so wird dieser Bereich als Standardbereich für alle lokalen UA-Anforderungen und SA-Registrierungen übernommen, wenn anderweitig kein Bereich angegeben ist.
Service-Agenten treten physisch als separater Prozess auf dem Hostcomputer auf. Die Datei slpd.exe wird auf dem lokalen Computer als Dienst ausgeführt. Die Benutzeragenten senden Nachrichten an die Loopback-Adresse eines bekannten Ports und fragen so den lokalen Service-Agenten ab.
Der Service-Agent stellt permanenten Speicher und Wartungspunkte für lokale Dienste bereit, die sich bei SLP registriert haben. Der Service-Agent pflegt im Wesentlichen eine speicherinterne Datenbank der registrierten lokalen Dienste. Ein Dienst kann sich dabei nur dann bei SLP registrieren, wenn ein lokaler SA vorhanden ist. Die Clients können Dienste durchaus nur mit einer UA-Bibliothek ermitteln. Für die Registrierung ist jedoch ein SA erforderlich, hauptsächlich weil der SA regelmäßig prüfen muss, ob die registrierten Dienste vorhanden sind, damit die Registrierung bei überwachenden Agenten aufrechterhalten werden kann.
Um die Verzeichnisagenten und ihre jeweils unterstützte Bereichsliste zu suchen und im Cache zu speichern, sendet ein Service-Agent wie folgt eine DA-Ermittlungsanforderung direkt an potenzielle DA-Adressen:
Der Agent prüft alle statisch konfigurierten DA-Adressen (und fügt neue DAs zum Cache des SA mit den bekannten DAs hinzu).
Der Agent fordert eine Liste der DAs und ihrer Bereiche von DHCP an (und fügt neue DAs zum Cache des SA mit den bekannten DA hinzu).
Der Agent sendet eine DA-Ermittlungsanforderung per Multicast über einen bereits bekannten Port (und fügt neue DAs zum Cache des SA mit den bekannten DA hinzu).
Der Agent empfängt DA-Bekanntgabepakete, die die DAs in regelmäßigen Abständen per Rundsendung übermitteln (und fügt neue DAs zum Cache des SA mit den bekannten DA hinzu).
Dies ist wichtig, weil ein Benutzeragent stets zuerst den lokalen Service-Agenten abfragt: Die Antwort des lokalen Service-Agenten bestimmt, ob der Benutzeragent zur nächsten Ermittlungsphase übergeht oder nicht (in diesem Fall DHCP; siehe Schritt 3 und Schritt 4 in Benutzeragenten).
Der Verzeichnisagent stellt einen langfristig permanenten Cache für bekannt gegebene Dienste bereit und fungiert als Zugriffspunkt für die Suche nach Diensten durch die Benutzeragenten. Der DA überwacht die SAs, ob neue Dienste bekannt gegeben werden, und speichert diese Benachrichtigungen im Cache. In kurzer Zeit wird der Cache eines DA voller oder vollständiger. Mithilfe eines Ablaufalgorithmus werden die Einträge im Cache der Verzeichnisagenten außer Kraft gesetzt. Beim Starten liest der Verzeichnisagent den Cache aus dem permanenten Speicher aus (in der Regel eine Festplatte), und anschließend werden die Einträge gemäß dem Algorithmus außer Kraft gesetzt. Wenn ein neuer DA gestartet wird oder der Cache gelöscht wurde, erkennt der DA diesen Zustand, und er sendet eine besondere Benachrichtigung an alle empfangenden SAs, ihre lokalen Datenbanken zu übermitteln, sodass der DA den Cache rasch aufbauen kann.
Falls keine Verzeichnisagenten vorhanden sind, sendet der UA eine allgemeine Multicast-Abfrage, auf die die SAs antworten können. So entsteht eine Liste der angeforderten Dienste, ähnlich wie beim Aufbauen des Cache durch die DAs. Die durch diese Abfrage zurückgegebene Diensteliste ist unvollständig und stärker lokal konzentriert als die Liste eines DA, insbesondere wenn eine Multicast-Filterung erfolgt. Diese Filterung wird von zahlreichen Netzwerkadministratoren vorgenommen, damit die Rundsendungen und Multicasts ausschließlich auf das lokale Teilnetz beschränkt werden.
Fazit: Alles hängt von dem Verzeichnisagent ab, den ein Benutzeragent für einen bestimmten Bereich auffindet.
Die folgenden Parameter in der Datei %systemroot%/slp.conf steuern die Ermittlung der Verzeichnisagenten:
net.slp.useScopes = comma-delimited scope list net.slp.DAAddresses = comma-delimited address list net.slp.passiveDADetection = <"true" or "false"> net.slp.activeDADetection = <"true" or "false"> net.slp.DAActiveDiscoveryInterval = <0, 1, or a number of seconds>
Gibt die Bereiche an, in denen der SA die Bekanntgabe vornimmt, außerdem die Bereiche, die abgefragt werden sollen, wenn kein bestimmter Bereich in der Registrierung oder Abfrage des Dienstes oder der Client-Anwendung festgelegt ist. Da das Identitätsdepot Bekanntgaben und Abfragen stets im Standardbereich vornimmt, wird diese Liste zur Standardbereichsliste für alle Registrierungen und Abfragen des Identitätsdepots.
Enthält eine durch Komma getrennte Liste mit dezimalen IP-Adressen der DAs (mit Punkten), die Vorrang vor allen anderen Adressen erhalten sollen. Falls diese Liste der konfigurierten DAs den Bereich einer Registrierung oder Abfrage nicht unterstützt, senden die SAs und UAs ein Multicast für die DA-Ermittlung, sofern diese Art der Ermittlung nicht deaktiviert ist.
Weist standardmäßig den Wert Wahr auf. Wenn die Verzeichnisagenten entsprechend konfiguriert sind, übermitteln sie ihre Existenz in regelmäßigen Abständen per Rundsendung im Teilnetz über einen bekannten Port. Diese Pakete werden als DAAdvert-Pakete bezeichnet. Ist diese Option auf „Falsch“ eingestellt, ignoriert der SA alle rundgesendeten DAAdvert-Pakete.
Weist standardmäßig den Wert Wahr auf. Damit kann der SA in regelmäßigen Abständen per Rundsendung eine Anforderung an alle DAs übermitteln, mit einem zielgerichteten DAAdvert-Paket zu antworten. Ein zielgerichtetes Paket wird nicht rundgesendet, sondern direkt als Antwort auf diese Anforderungen an den SA gesendet. Ist diese Option auf „Falsch“ eingestellt, übermittelt der SA keine DA-Ermittlungsanforderung in regelmäßigen Abständen per Rundsendung.
Parameter mit drei möglichen Zuständen. Der Standardwert lautet 1. Dieser Wert bedeutet, dass der SA nur bei der Initialisierung eine einzige DA-Ermittlungsanforderung senden soll. Wenn Sie diese Option auf 0 einstellen, hat dies dieselbe Wirkung, als wenn Sie die Option activeDADetection auf „Falsch“ einstellen. Jeder andere Wert bezeichnet den Zeitraum (in Sekunden) zwischen den Ermittlungsrundsendungen.
Mithilfe dieser Optionen können Sie die Nutzung der Netzwerkbandbreite für die Dienstbekanntgabe ausgewogen gestalten. Die Standardeinstellungen sind so gewählt, dass die Skalierbarkeit in einem durchschnittlichen Netzwerk optimiert wird.
eDirectory, die zugrunde liegende Infrastruktur des Identitätsdepots, ist eher eine E/A-intensive als eine prozessorintensive Anwendung. Zwei Faktoren steigern die Leistung des Identitätsdepots: ein größerer Cache-Speicher und schnellere Prozessoren. Um optimale Ergebnisse zu erzielen, sollten Sie so viele Teile des DIB-Satzes (Directory Information Base, Verzeichnisinformationsdatenbank), wie es die Hardware erlaubt, im Cache-Speicher ablegen.
eDirectory lässt sich schon auf einem einzelnen Prozessor gut skalieren; unter Umständen sollten Sie jedoch den Einsatz mehrerer Prozessoren erwägen. Eine höhere Prozessoranzahl erhöht die Leistung in Bereichen wie die Benutzeranmeldung. Auch die Verwendung mehrerer aktiver Threads auf mehreren Prozessoren trägt zur Leistungssteigerung bei.
Die nachfolgende Tabelle zeigt allgemeine Anhaltspunkte für die Servereinstellungen, die auf der erwarteten Anzahl der Objekte in eDirectory beruhen.
|
Objekte |
Arbeitsspeicher |
Festplatte |
|---|---|---|
|
100.000 |
384 MB |
144 MB |
|
1 Millionen |
4 GB |
1,5 GB |
|
10 Millionen |
2+ GB |
15 GB |
Eine Basis-Installation von eDirectory mit dem Standardschema erfordert zum Beispiel ungefähr 74 MB Festplattenpeicher pro 50.000 Benutzer. Wenn Sie jedoch einen neuen Satz von Attributen hinzufügen oder alle vorhandenen Attribute komplett ausfüllen, steigt die Objektgröße. Dies wirkt sich auf den erforderlichen Festplattenspeicher, Prozessor und Arbeitsspeicher aus. Die Anforderungen an die Prozessoren sind zudem abhängig von den verfügbaren zusätzlichen Diensten auf dem Computer und der Anzahl der Beglaubigungen und Lese- und Schreibvorgänge, die der Computer verarbeitet. Prozesse wie die Verschlüsselung und die Indizierung können prozessorintensiv sein.
Das Identitätsdepot unterstützt sowohl IPv4-Adressen als auch IPv6-Adressen. Beim Installieren des Identitätsdepots können Sie IPv6-Adressen aktivieren. Wenn Sie eine frühere Version aufrüsten, müssen Sie die IPv6-Adressen manuell aktivieren.
Das Identitätsdepot unterstützt außerdem die IPv6-Übergangsmethoden Dual-IP-Stack, Tunneling und Pure. Es werden lediglich die globalen IP-Adressen unterstützt. Beispiel:
[::]
[::1]
[2015::12]
[2015::12]:524
IPv6-Adressen müssen in eckigen Klammern [ ] angegeben werden. Soll der Hostname statt der IP‑Adresse verwendet werden, müssen Sie den Namen in der Datei C:\Windows\System32\drivers\etc\hosts angeben und mit der IPv6-Adresse verknüpfen.
Sollen IPv6-Adressen auf einem Windows-Server verwendet werden, müssen Sie während der Installation das Kontrollkästchen IPv6 aktivieren unter IPv6-Einstellungen aktivieren. Mit dieser Option werden das NCP-, das HTTP- und das HTTPS-Protokoll für die IPv6-Adressen aktiviert. Wenn Sie die IPv6-Adressen nicht während des Installationsvorgangs aktivieren und sich erst später für die Nutzung dieser Adressen entscheiden, müssen Sie das Setup-Programm erneut ausführen. Weitere Informationen finden Sie in Abschnitt 7.3, Installieren des Identitätsdepots.
Unter dem folgenden Link können Sie auf iMonitor über IPv6-Adressen zugreifen:http://[2015::3]:8028/nds.
Beim Installieren des Identitätsdepots müssen Sie die Ports angeben, die der LDAP-Server überwachen soll, sodass LDAP-Anforderungen verarbeitet werden können. Im Rahmen der standardmäßigen Konfiguration werden die Port-Nummern für Klartext und SSL/TLS auf 389 bzw. 636 festgelegt.
Für eine einfache LDAP-Bindung ist lediglich ein DN und ein Passwort erforderlich. Das Passwort liegt in Klartext vor. Wenn Sie Port 389 verwenden, ist das gesamte Paket in Klartext verfügbar. Da der Port 389 die Verwendung von Klartext zulässt, verarbeitet der LDAP-Server die Lese- und Schreibanforderungen an das Verzeichnis über diesen Port. Diese Offenheit eignet sich für vertrauenswürdige Umgebungen, in denen kein Spoofing auftritt und die Benutzer nicht unbefugt Pakete abfangen. Standardmäßig ist diese Option bei der Installation deaktiviert.
Die Verbindung über Port 636 ist verschlüsselt. Die Verschlüsselung wird von TLS (früher SSL) verwaltet. Bei einer Verbindung mit Port 636 wird automatisch ein Handshake instanziiert. Falls ein Fehler beim Handshake auftritt, wird die Verbindung abgelehnt.
HINWEIS:Im Installationsprogramm wird Port 636 standardmäßig für die TLS/SSL-Kommunikation ausgewählt. Diese Standardauswahl kann auf Ihrem LDAP-Server ein Problem darstellen. Wenn ein Dienst, der bereits vor der Installation von eDirectory auf dem Hostserver geladen war, den Port 636 nutzt, müssen Sie einen anderen Port angeben. Bei Installationen vor eDirectory 8.7 wurde dieser Konflikt als schwerwiegender Fehler behandelt, und nldap wurde entladen. Ab eDirectory 8.7.3 wird nldap durch das Installationsprogramm geladen, in die Datei dstrace.log wird eine Fehlermeldung eingetragen, und das Programm wird ohne den sicheren Port ausgeführt.
Während des Installationsvorgangs können Sie das Identitätsdepot so konfigurieren, dass Passwörter und andere Daten in Klartext nicht zulässig sind. Die Option TLS für einfache Bindung mit Passwort erforderlich hält die Benutzer davon ab, erkennbare Passwörter zu senden. Wenn Sie diese Einstellung nicht auswählen, ist es für die Benutzer nicht ersichtlich, dass andere Benutzer ihre Passwörter mitlesen können. Diese Option, mit der die Verbindung nicht zugelassen wird, gilt lediglich für den Klartext-Port. Wenn Sie eine sichere Verbindung mit Port 636 herstellen und eine einfache Bindung vorliegt, ist die Verbindung bereits verschlüsselt. Die Passwörter, Datenpakete und Bindungsanforderungen sind nicht einsehbar.
Betrachten Sie die folgenden Szenarien:
Frau Lehmann nutzt einen Client, der ein Passwort anfordert. Sobald Frau Lehmann das Passwort eingibt, stellt der Client eine Verbindung zum Server her. Der LDAP-Server lässt jedoch nicht zu, dass die Verbindung über den Klartext-Port eine Bindung zum Server vornimmt. Alle Benutzer können Frau Lehmanns Passwort einsehen, während sie selbst keine gebundene Verbindung erhält.
Auf dem Server wird Active Directory ausgeführt. Active Directory führt ein LDAP-Programm aus, das auf den Port 636 zugreift. Sie installieren eDirectory. Das Installationsprogramm erkennt, dass der Port 636 bereits verwendet wird, und weist dem NetIQ-LDAP-Server keine Port-Nummer zu. Der LDAP-Server wird geladen und wird scheinbar ausgeführt. Da der LDAP-Server einen bereits geöffneten Port nicht duplizieren und nicht verwenden kann, verarbeitet der LDAP-Server jedoch keine Anforderungen über duplizierte Ports.
Mit dem ICE-Dienstprogramm stellen Sie fest, ob dem NetIQ-LDAP-Server der Port 389 oder 636 zugewiesen ist. Wenn im Feld Herstellerversion nicht NetIQ angegeben ist, müssen Sie den LDAP-Server für eDirectory neu konfigurieren und einen anderen Port auswählen. Weitere Informationen finden Sie unter „Verifying That the LDAP Server is Running“ (Überprüfen, ob der LDAP-Server ausgeführt wird) im NetIQ eDirectory -Administrationshandbuch.
Wenn Active Directory ausgeführt wird und der Klartext-Port 389 geöffnet ist, können Sie den ICE-Befehl für Port 389 ausführen und die Herstellerversion abfragen. Im Bericht wird Microsoft* angezeigt. Anschließend konfigurieren Sie den NetIQ-LDAP-Server neu. Wählen Sie hierzu einen anderen Port aus, sodass der eDirectory-LDAP-Server die LDAP-Anforderungen verarbeiten kann.
iMonitor kann außerdem melden, ob der Port 389 oder 636 bereits geöffnet ist. Wenn der LDAP-Server nicht funktioniert, erhalten Sie mit iMonitor nähere Details. Weitere Informationen finden Sie unter „Verifying That the LDAP Server is Running“ (Überprüfen, ob der LDAP-Server ausgeführt wird) im NetIQ eDirectory -Administrationshandbuch.
NICI muss auf allen Arbeitsstationen installiert werden, auf denen Verwaltungsfunktionen (z. B. iManager) verwendet werden. Weitere Informationen zum Verwenden von NICI mit dem Identitätsdepot finden Sie in Voraussetzungen für die Installation des Identitätsdepots.
Zum Installieren von NICI verwenden Sie die Datei NICI_wx64.msi (standardmäßig im Ordner products\eDirectory\processor_type\windows\processor_type\nici). Sie können die Datei wahlweise als geführten Vorgang (Assistent) oder als automatische Installation ausführen.
Die NMAS-Client-Software (NetIQ Modular Authentication Service) muss auf jeder Client-Arbeitsstation installiert werden, auf der die NMAS-Anmeldemethoden verwendet werden sollen. Die Anmeldemethoden legen Sie beim Installieren des Identitätsdepots fest.
Melden Sie sich mit einem Administratorkonto bei der Client-Arbeitsstation an.
Führen Sie das Programm nmasinstall.exe im Installationsverzeichnis aus (standardmäßig Win:\products\eDirectory\processor_type\nmas\).
Klicken Sie auf NMAS-Client-Komponenten.
(Optional) Wählen Sie die Option für NICI, wenn die NICI-Komponente installiert werden soll.
Klicken Sie auf OK.
Starten Sie nach Abschluss der Installation die Arbeitsstation neu.