OPSI 3.4: PAM authentication failed for user ....

[rkloust]

Hallo,

auf der Suche nach einer nach einer Softwareverteilung bin ich auf OPSI gestoßen. Über den Download der VMware-Maschine habe ich nun nach mehreren Tagen der Nacharbeit endlich den Opsi-Server funktionstüchtig. Das Installationsskript 1stboot.py scheint nicht wirklich fehlerfrei zu laufen (Stichwort: unvollständige Zertifikatserstellung, Nichtanlegen der Datei /var/lib/1stboot/md5checksums, ..). Die weiteren Fehler erspare ich mir jetzt, da nun folgendes Problem besteht:

Aktionen, z.B. hwinvent -siehe Installationshandbuch Kapitel 10.1-, die auf einem Clienten mit den Client-Name pxeclient-001domain.tld ausgeführt werden sollen, enden immer in der Meldung: PAM authentication failed for user 'pxeclient-001.local' : ('User not known to the underlying authentication module', 10).

Kurzbeschreibung der Umgebung:
Die Testumgebung ist auf einem VMware-Server 2.0.1 Build 156745 realisiert und durch eine m0n0wall-Firewall vom restlichen Netzwerk abgeschottet. Die Firewall übernimmt die DNS- und DHCP-Dienste. Für PXE-Boot sind in der Firewall sowohl Next-Server als auch Filename entsprechend gespflegt und zeigen auf den Opsi-Server. Der DHCP-Dient des Opsi-Servers ist abgeschaltet.

Die PXE-Konfiguration wird fehlerfrei in /tftpboot/linux/pxeconfig.cfg innerhalb der Onetime-Pipe 01-MAC-ADRESSE-DES-SYSTEMS abgelegt. Der blaue Bildschirm mit dem Schriftzug Open PC ServerIntegration erscheint und irgendwann auch der Produktname, z.B. [hwinvent].

Statt der Ausführung von hwinvent erscheint die im Betreff angegebene Fehlermeldung.

Wo liegt der Fehler ?

Gruß
Ronald

[rkloust]

Hallo,

bin ich der Einzige, der eine virtuelle Maschine als Grundlage für die Einführung von Opsi verwendet?
Die Fehler tauchen bei jeder Installation der VMware-Maschine auf und sind damit systematisch!

Viele Grüße
Ronald Kloust

[wolfbardo]

Hallo Roland Kloust,

Client-Name pxeclient-001domain.tld ausgeführt werden sollen, enden immer in der Meldung: PAM authentication failed for user 'pxeclient-001.local' : ('User not known to the underlying authentication module', 10).

Namensauflösungsproblem??.

Code: Alles auswählen

pxeclient-001domain.tld

oder

Code: Alles auswählen

pxeclient-001.local 

???

Gruss
Bardo Wolf

[rkloust]

Hallo Roland Kloust,

Client-Name pxeclient-001domain.tld ausgeführt werden sollen, enden immer in der Meldung: PAM authentication failed for user 'pxeclient-001.local' : ('User not known to the underlying authentication module', 10).

Namensauflösungsproblem??.

Code: Alles auswählen

pxeclient-001domain.tld

oder

Code: Alles auswählen

pxeclient-001.local 

???

Gruss
Bardo Wolf

Hallo Herr Wolf,

da hat der Fehlerteufel doch glatt einen Punkt verschluckt.

Es muss natürlich heißen: pxeclient-001.domain.tld, wobei ich mittlerweile glaube, dass die Authentifizierung des Users pcpatch fehlschlägt, was aber noch nicht verifiziert werden konnte.

Gruß
Ronald Kloust

[rkloust]

Sorry, Herr Wolf,
da war ich gerade nicht ganz momentan.

Der User wird mit pxeclient-001.local gemeldet wobei der Hostname des zu prüfenden Rechners mit pxeclient-001.domain.tld festgelegt wurde.

[thomas.besser]

bin ich der Einzige, der eine virtuelle Maschine als Grundlage für die Einführung von Opsi verwendet?

Nein, auch ich bin gerade dabei. Hab mir allerdings das VMWare-Image nach Qemu/KVM konvertiert.

Die Fehler tauchen bei jeder Installation der VMware-Maschine auf und sind damit systematisch!

Kann keinen systematischen Fehler bestätigen. Ich habe keinerlei Fehler des OPSI-Servers gehabt.

Gruß
Thomas Besser

[d.oertel]

Hi,

Wir haben gestern eine überarbeitete opsi3.4 VM hochgeladen:
http://download.uib.de/opsi3.4/opsi3.4-servervm.zip
Damit evtl. den Server noch mal aufbauen und schauen ob das Problem bleibt.

gruss
d.oertel

[rkloust]

Hi,

das neue Image hab ich runtergeladen und im VMware Server bereitgestellt.

Abarbeitung der Installationsanleitung bis einschl. Punkt 5.3 fehlerfrei!
Da der DHCP-Server des OPSI-Servers NICHT genutzt wird hab' ich die Datei /etc/opsi/backendManager.d/30_vars.conf angepasst, so dass die Attributdefinition self.clientManagingBackend = BACKEND_FILE31 lautet. Der nachfolgende Restart des opsiconfd schlägt fehl.

Das JPEG kann ich scheinbar nicht hochladen.
Werde jetzt die Generierung eines neuen Zeritifikats ausprobieren und dann weitere Hinweise ins Forum stellen.

Gruß
Ronald

[rkloust]

Hi,

nach der Erstellung einer eigenen CA, der Generierung eines CA-Keys und eines Server-Zertifikats für meine Maschine opsidepot.domain.tld, die beide in EINER Datei zusammengefasst wurde startet der opsiconf nun fehlerfrei.

Das sollte eigentlich durch das Python-Skript /usr/local/bin/1stboot.py erledigt werden. Scheint aber nicht wirklich zu funktionieren, da der CA-Key offensichtlich in der Datei abgelegt ist, aber nicht das zu generierende Server-Zertifikat.

Als nächstes wurden die minimalen Opsi-Produkte einwandfrei geladen und installiert. Weitere Ergebnisse folgen.

Gruß
R. Kloust

p.s. Alle Werkzeug zur CA-Schlüssel- und Zertifikatserstellung des Servers sind installiert und somit vorhanden. Also liegt's auch nicht an fehlender Software.

[rkloust]

Hi,

die Lösung ist gefunden.
In der Datei /var/lib/1stboot/execOnChange steht die Bauanleitung für die Zertifikate unter dem Punkt [req].

Lösung:
Es kommt darauf an, das beim Ausfüllen der Zertifikatsinformationen entweder alle Abfragen - also auch die mit [Optional] gekennzeichneten Felder - mit gültige Einträgen beantwortet werden, oder das zumindest in die optionalen Felder ein Punkt eingetragen wird.

Grund:
OpenSSL erwartet, dass in der Eingabedatei für ein leeres Feld ein "." (Punkt) steht.

Nun ja, jetzt ist zumindest klar warum opsiconfd nicht starten konnte; wegen des fehlenden Serverzertifikats, wie bereits analysiert. Eine eigene CA ist mit den neuen Erkenntnissen nun nicht erforderlich.

NACHTRAG:
... und der Hinweis von Bardo Wolf hat mich letzlich auf meinen Fehler der Monowall-Konfiguration geführt. In den allgemeinen EInstellungen war nur der Standard-Domainname "local" eingetragen. Hierauf greift auch der DHCP-Server der Monowall zu. Deshalb gab er beim PXE-Boot wohl auch diese Domain zurück; kombiniert mit dem vorgegebenen Hostname kommt dann pxeclient-001.local heraus, während der OPSI-Server als Hostname pxeclient-001.domain.tld erwartete. Seit der Umstellung des Domainnamens auf domain.tld funktioniert's fehlerfrei.

Meine Erkenntnis: Eine Softwareverteilung kann am Anfang beliebig kompliziert werden, man darf sich nur nicht entmutigen lassen.

Gruß
Ronald

p.s.
Für Neueinsteiger wäre zumindest eine kurze Erläuterung in der Installationsanleitung oder die Erweiterung der Antworten auf Seite 16 des gleichen Dokuments hilfreich.