PDA

View Full Version : Zugriff auf Windows Server über QNTC



Seiten : 1 [2] 3

Fuerchau
21-09-16, 09:36
Da wird es schon schwierig, ohne Fehlermeldung, die Ursache zu ermitteln.
Was die Kennworte angeht, so hängt dies von der Kennwortstufe auf der AS/400 ab.
Bei Stufe 0 (max. 10 Großbuchstaben) prüft die die AS/400 das Kennwort:
Anmeldung alles in Großbuchstaben, schlägt diese fehl, Anmeldung in Kleinbuchstaben.
Wie man sieht, ist meine obige Aussage nicht falsch gewesen.
Die Anmeldung auf der AS/400 ist egal, da eben alles in Großbuchstaben umgewandelt wird.
Nun meldet sich die AS/400 aber am NT-Server an und der kennt sowas halt nicht.
Daher ist es wichtig, auf dem NT-Server entweder alles in Klein- oder alles in Großbuchstaben zu erfassen. Bei MixedCase schlägt die Anmeldung eben fehl.

Bei Kennwortstufe ab 1 ist sowieso dann alles MixedCase.

Meine generelle Vermutung für die Verzeichnisanzeige liegt ggf. an der Berechtigung des Verzichnisses auf dem NT-Server selber. Die Anmeldung klappt zwar, aber die Berechtigung an der Freigabe scheint entzogen.

mahones
21-09-16, 09:56
Ja, wir haben Kennwortstufe 0 - und das Profil ist auf "allen" Systemen identisch angelegt.
Was die Berechtigungen angeht, haben wir auch noch einmal den neuen Benutzer mit Vollzugriff ausgestattet. Über den direkten Aufruf aus Windows heraus (\\xxx.xxx.xxx.xxx\Freigabe) funktioniert ja alles.

Die Fehlermeldung ist eigentlich genau dieselbe wie bereits oben abgebildet (mit angepassten Vokabeln):

Nachrichten-ID . . . . : CPDB053 Bewertung . . . . . . : 30
Nachrichtenart . . . . : Diagnose
Sendedatum . . . . . . : 21.09.16 Sendezeit . . . . . . : 08:33:09

Nachricht . . . : Fehler beim Austausch von Sicherheitsinformationen für
Benutzer *BENUTZER* auf Netzwerk-Server xxx.xxx.xxx.xxx.
Ursache . . . . : Beim Authentifizieren von Benutzer *BENUTZER* für
Netzwerk-Server xxx.xxx.xxx.xxx hat das IBM i NetClient-Dateisystem QNTC einen
Fehler festgestellt.
Fehlerbeseitigung: Folgendes sicherstellen:
- Der Benutzer ist auf Netzwerk-Server xxx.xxx.xxx.xxx definiert.
- Das IBM i-Benutzerkennwort stimmt mit dem Benutzerkennwort für den
Netzwerk-Server überein.
- Netzwerk-Server xxx.xxx.xxx.xxx ist für digital signierte Datenübertragung
aktiviert.
Technische Beschreibung . . . . . . . : Beim Austausch von
Sicherheitsinformationen zwischen dem QNTC-Dateisystem und einem
Netzwerk-Server wurde ein Fehler festgestellt. Die Fehlerklasse war 1, der
Fehlercode war 5.
Mögliche Werte für Fehlerklasse und Fehlercode:
Klasse 0 - QNTC-spezifischer Sicherheitsfehler.
1 - QNTC verlangt digitale Unterzeichnung.
Klasse 1 - Betriebssystemfehler des Netzwerk-Servers.
1 - Keine gültige Funktion.
2 - Datei nicht gefunden.
3 - Verzeichnis nicht gültig.
4 - Zu viele geöffnete Dateien.
5 - Zugriff verweigert.
Klasse 2 - Durch Netzwerk-Server generierter Fehler.
1 - Nichtspezifischer Fehlercode.
2 - Falsches Kennwort.
3 - Verzeichnis nicht gültig.
4 - Zugriff verweigert.
7 - Keine gültige Einheit.
Klasse 3 - NWS-Hardwarefehler.
31 - Allgemeiner Hardwarefehler.
39 - Kein Speicherplatz in Dateisystem.


Also theoretisch ist alles richtig, aber die Praxis weiß davon nichts...

Fuerchau
21-09-16, 12:37
Nur noch mal ne blöde Frage:
Ist der User auch tatsächlich ein loaler User auf dem Server und kein Domain-User?
Die AS/400 schafft da nämlich keine Domain-Anmeldung. Das war allerdings schon immer so.

Die Aussage "bisher klappte das, seit dann und dann nicht, aber wir haben nichst geändert" ist immer schwer zu verstehen, zumal ja Windows mit seinen updates manchmal ganz schön dazwischen haut.
Prüfe mal ob nicht doch ein Autoupdate (Sicherheitslücke behoben) stattgefunden hat.
Ich meine irgendwo mal gelesen zu haben, dass die alte NT-Authentifizierung entfallen soll. Dann klappt das so gar nicht mehr.

Sicherere wäre sowieso der umgedrehte Weg. Ihr stellt die Daten in einer AS/400-Freigabe zur Verfügung und die wird dann aktiv abgeholt (Stichwort: Information ist Holschuld).

mahones
21-09-16, 13:30
Ne, keine blöde Frage - zumindest hat das funktioniert.
Wir haben einen Benutzer direkt auf dem Windows-Server angelegt und berechtigt, und es hat mit WRKLNK funktioniert!
...ja, das wurde vorher schon (sogar in FETT) angemerkt, aber wir haben das tatsächlich vernachlässigt, weil es ja eben bisher auch ohne lokale Benutzer funktionierte.

Nun überlegen wir, die benötigten Benutzer nochmal lokal auf dem Server einzurichten.
Anscheinend gilt hier nicht "never change a running system" - sondern hier muss man mal was ändern...ok, es läuft ja auch aktuell nicht so richtig.

Danke dir für die Hartnäckigkeit, was die Benutzer anging!

Fuerchau
21-09-16, 18:30
Ich kann mir auch nicht vorstellen, dass es mit Domain-Usern jemals funktioniert hat.
Welche Restriktionen da nicht aktiviert waren, dass es mit Domain-Usern klappte weiß ich auch nicht.
Aber z.B. seit Windows Server 2008 kann man mit der Aufgabenplanung (Task-Scheduler) auch Domain-User unbeaufsichtigt (mit Kennwort) einrichten.
Dies funktioniert sogar, allerdings unter folgenden Einschränkungen:
- Das Logon-Script des Users wird nicht ausgeführt
- Es ist nur Zugriff auf lokale Ressorcen (Pfade, Dateien, ...) erlaubt sofern man berechtigt ist
- Auf Netzwerkressourcen ist kein Zugriff möglich, ein "net use" für Laufwerkszuordnungen schlägt fehl
- Somit sind auch keine UNC-Pfade möglich, da im Batch ja keiner zum Anmelden da ist
Die volle Funktionalität erhält man aber, wenn der User im angemeldeten Zustand auf dem Server verbleibt (also nur Sitzung getrennt), was aber einer beaufsichtigen Ausführung entspricht.

Da sucht man sich manchmal dumm und dämlich, nur weil Windows an einer Stelle was unsinniges erlaubt. Aber das ist ja wie mit der Einbahnstrasse in die Sackgasse...

andreas.lundschien
27-09-16, 08:46
Moin aus dem hohen Norden,
wir haben das gleiche Problem, von einem Tag auf den anderen hat es nicht mehr funktioniert. Nur noch 2 Benutzer können mit QNTC arbeiten. Andere Benutzer die auch auf der Iseries allobj und auf der Windowsseite Administrationsrechte haben können nicht mehr damit arbeiten. Die 2 Benutzer, bei denen es noch funktioniert haben schon sehr lange ihr Kennwort nicht geändert und meine Vermutung ist, dass mit einem Windowsupdate da etwas verändert wurde, dass der automatische Passwortaustausch bei jüngeren Passwörtern nicht mehr funktioniert. Kann das jemand bestätigen? Hat jemand einen Unterstützungsvertrag mit der IBM und kann da mal nachfragen ob die eine Idee haben? Wir haben V6R1 und auf der Windowsseite 2012 R2 im Einsatz.

andreas.lundschien
27-09-16, 09:15
Sorry, hatte die 2. Seite nicht gelesen,
nur zur Info, die 2 User mit denen es noch funktioniert sind Domänenuser und nicht Lokal angelegt.

Fuerchau
27-09-16, 12:17
Also *ALLOBJ auf der AS/400 bringt für QNTC überhaupt nichts, da Berechtigungen nicht gerouted werden.
Wenn Microsoft da was ändert muss das kein Feature sondern kann auch eine Fehlerkorrektur sein.
Meine ganz persönliche Erfahrung bzgl. QNTC ist eben, dass es mit lokalen Usern noch nie Probleme gab (eben seit NT), da bei Domaine-Usern doch sehr viele Prüfungen und Richtlinien in der Domäne eine Rolle spielen. Wenn es bisher geklappt hat, heißt das leider nichts.

Klappen denn lokale User?

andreas.lundschien
27-09-16, 12:43
Haben wir nicht versucht, noch klappt es ja mit den Domänenusern. Melde mich sobald das aktuell wird.

Fuerchau
27-09-16, 14:12
Achso, ich dachte, du hast dich dem Problem angeschlossen.