Problembehandlung

Welches Problem ist aufgetreten?

Der NIS-Datenmigrations-Assistent oder das NIS-Befehlszeilenprogramm werden erfolgreich ausgeführt, aber es werden keine Zuordnungen zu Server für NIS hinzugefügt.

Ursache:  Die Option Nicht migrieren (nur protokollieren) war ausgewählt.

Lösung:  Da die Migration nicht mehr rückgängig gemacht werden kann, wird standardmäßig die Option Nicht migrieren (nur protokollieren) verwendet. Sie können die Standardeinstellung beim Ausführen des Assistenten außer Kraft setzen, indem Sie auf der Seite Migrationskonflikte verwalten des NIS-Datenmigrations-Assistenten Überschreiben oder Beibehalten auswählen. Wenn Sie stattdessen das Befehlszeilenprogramm (Nis2ad.exe) verwenden und die Standardeinstellung außer Kraft setzen möchten, geben Sie auf der Befehlszeile die Option -m an.

Es treten Migrationskonflikte auf, obwohl die Testmigration mit der Option "Nicht migrieren (nur protokollieren)" erfolgreich ausgeführt wurde.

Ursache:  Wenn in den zu migrierenden NIS-Zuordnungen (Network Information Service, Netzwerkinformationsdienst) Konflikte auftreten, wird der Konflikt möglicherweise erst gemeldet, nachdem die Zuordnungen tatsächlich migriert wurden, da in Server für NIS nur Konflikte zwischen NIS-Zuordnungen und Active Directory gemeldet werden.

Lösung:  Lösen Sie die Konflikte in den ursprünglichen NIS-Zuordnungen, und migrieren Sie dann die nicht migrierten NIS-Daten mithilfe der Befehlszeilenoption nis2ad –r yes.

Ein Konflikt tritt auf, wenn mehrere Benutzer mit derselben Benutzer-ID (User Identifier, UID) migrieren möchten.

Ursache:  Der NIS-Datenmigrations-Assistent kann Benutzer mit gleicher UID nicht migrieren. Nur der erste Benutzer wird erfolgreich migriert.

Lösung:  Stellen Sie sicher, dass alle Benutzer über eindeutige UIDs verfügen, bevor Sie NIS-Zuordnungen migrieren.

Der NIS-Datenmigrations-Assistent oder das NIS-Befehlszeilenprogramm melden NIS-Namenskonflikte (Network Information Service, Netzwerkinformationsdienst) mit dem Systemkonto.

Ursache:  Ein Benutzername in NIS ist mit einem reservierten Windows-Kontonamen identisch. Reservierte Kontonamen sind u. a. Netzwerk, System, Benutzer und Computer.

Lösung:  Lösen Sie den Konflikt, indem Sie das UNIX-basierte Konto umbenennen, und migrieren Sie anschließend den Eintrag mithilfe der Befehlszeilenoption nis2ad –r yes erneut.

Das Dienstprogramm "ypmatch" kann auf einem HP-UX-Computer nicht ausgeführt werden.

Ursache:  Eine Zuordnung enthält Schlüssel in gemischter Groß-/Kleinschreibung. Das Betriebssystem HP-UX konvertiert alle Schlüssel in Kleinbuchstaben, bevor die NIS-Anforderung gesendet wird. Hierbei handelt es sich um ein Problem des Betriebssystems HP-UX, das außerhalb der Kontrolle von Server für NIS liegt.

Lösung:  Konvertieren Sie Schlüssel in Kleinbuchstaben, bevor Sie sie migrieren.

Die erste Anforderung an Server für NIS war nicht erfolgreich.

Ursache:  Wenn eine sehr große Anzahl von Objekten in Server für NIS migriert wurde, kann es relativ lange dauern, bis Server für NIS den Zuordnungscache erstellt hat.

Lösung:  Warten Sie eine Zeitspanne von 30 Minuten oder länger, und stellen Sie dann die Anforderung erneut. Bei nachfolgenden Anforderungen tritt das Problem möglicherweise nicht auf.

Objekte, die in nicht dem Standard entsprechende Container migriert wurden, werden in Active Directory-Benutzer und -Computer nicht angezeigt.

Ursache:  Standardmäßig werden nicht dem Standard entsprechende Container in Active Directory-Benutzer und -Computer nicht angezeigt.

Lösung:  Klicken Sie im Menü Ansicht auf Erweiterte Funktionen.

Das Dienstprogramm "ypcat" zeigt manchmal falsche Kennwortinformationen an, aber "ypmatch" stellt die richtigen Informationen bereit.

Ursache:  Nachdem Daten in Active Directory geändert wurden, wurde der Zuordnungscache noch nicht mit Server für NIS-Daten aktualisiert. Das Dienstprogramm ypcat bezieht seine Informationen aus diesem Cache, während das Dienstprogramm ypmatch Informationen direkt aus Active Directory verwendet.

Lösung:  Verkleinern Sie das Aktualisierungsintervall für Aktualisierungen des Zuordnungscache, oder wählen Sie die Option, dass die Aktualisierungen sofort nach Durchführung von Änderungen in Active Directory in den Cache übernommen werden. Weitere Informationen finden Sie unter Ändern der Häufigkeit von Zuordnungsupdates und Sofortiges Propagieren geänderter Zuordnungen.

Benutzer mit neuen bei der NIS-Migration erstellten Windows-Konten können sich weder bei Windows noch bei NIS-Clientcomputern anmelden.

Ursache:  Der Migrations-Assistent deaktiviert die neuen Konten, um eine falsche Verwendung zu verhindern.

Lösung:  Nach Abschluss der Migration sollten Sie die neuen Konten erst dann aktivieren, wenn die Benutzer sie verwenden möchten. Aus Sicherheitsgründen wird empfohlen, das Kennwort bei allen neu erstellten Windows-Benutzerkonten auf temporäre Werte zu ändern. Benachrichtigen Sie die Benutzer, dass es sich nur um vorläufige Kennwörter handelt, und weisen Sie sie an, ihre Windows-Kennwörter so bald wie möglich zu ändern. Informieren Sie die Benutzer, wie häufig Änderungen vorgenommen werden (siehe Senden periodischer Zuordnungsupdates an untergeordnete NIS-Server), damit sie wissen, wann sie mit einer Aktualisierung der UNIX-Kennwörter rechnen können.

Ein in Active Directory deaktiviertes Benutzerkonto wird nicht auch auf UNIX-Hosts deaktiviert.

Ursache:  Windows- und UNIX-Konten müssen separat deaktiviert werden, da hierfür jeweils eine völlig andere Vorgehensweise erforderlich ist. Die Methode zum Deaktivieren von UNIX-Konten hängt von der Systemversion und den Einstellungen des Administrators ab.

Lösung:  Nachdem Sie mit Active Directory-Benutzer und -Computer ein Konto deaktiviert haben, müssen Sie auch das entsprechende UNIX-Konto auf dem üblichen Weg deaktivieren oder sperren. Sie können hierzu beispielsweise das Kennwort in einen dem Benutzer nicht bekannten Wert ändern, dem Kennwort des Benutzers in der Datei passwd ein Sonderzeichen hinzufügen oder die Anmelde-Shell des Kontos ändern. Sie können auch alle drei Methoden kombiniert verwenden.

Ein neu migrierter Benutzer wird von einem UNIX-Client nicht authentifiziert.

Ursache:  Mögliche Konfigurationsfehler auf dem Clientcomputer.

Lösung:  Führen Sie zur Problembehandlung die im Folgenden für das jeweilige Clientbetriebssystem angegebenen Schritte aus.

Auf einem Clientcomputer unter dem Betriebssystem Solaris:

  • Stellen Sie sicher, dass der Windows-basierte Computer, auf dem Server für NIS ausgeführt wird, der Datei /etc/hosts auf dem Solaris-Client hinzugefügt wurde. Führen Sie anschließend auf dem Client den Befehl ypwhich aus, und überprüfen Sie, ob der richtige Windows-basierte Computer angezeigt wird.

  • Stellen Sie sicher, dass die Datei /etc/nsswitch.conf einen Eintrag enthält, der dem folgenden ähnelt:

    passwd:   files [NOTFOUND=continue] nis

  • Stellen Sie sicher, dass der Benutzer in der lokalen Datei passwd nicht aufgelistet wird.

  • Fügen Sie am Ende der Datei /etc/passwd auf dem Clientcomputer Folgendes hinzu:

    +::::::

  • Stellen Sie sicher, dass auch alle ggf. vorhandenen Schattendateien in Server für NIS migriert werden.

  • Stellen Sie sicher, dass der Befehl ypcat password kein X im Kennwortfeld des Benutzers anzeigt.

  • Stellen Sie sicher, dass die Datei /var/yp/securenets so konfiguriert ist, dass eine Authentifizierung vom Clientcomputer aus zulässig ist.

Auf einem Clientcomputer unter dem Betriebssystem Linux:

  • Stellen Sie sicher, dass der Windows-Server mit Server für NIS der Datei /etc/hosts auf dem Clientcomputer hinzugefügt wurde und dass der Befehl ypwhich auf dem Clientcomputer den Namen des Windows-basierten Computers richtig anzeigt.

  • Stellen Sie sicher, dass der Eintrag USENIS in der Datei /etc/sysconfig/authconfig auf USENIS=yes festgelegt ist.

  • Stellen Sie sicher, dass die Datei nsswitch.conf ordnungsgemäß konfiguriert ist.

Inhaltsverzeichnis