Zugriff auf Windows Server über QNTC

[Fuerchau]

Die AS/400 hat sowas nicht (soweit ich weiß).
Bist du sicher, dass der User auf dem Windowsrechner rein lokaler User ist ?
Ggf. verlangt der Server nämlich eine Netzwerkanmeldung á la "Netzwerk/User". Diese Art der Anmeldung funktioniert nicht.

Kannst du dich denn lokal an dem Server direkt anmelden ?
Wie siehts aus mit Groß/Kleinschreibung ?
Ist das Kennwort max. 10-Stellig in Großbuchstaben ?

[dd3tj]

Nach dem ich mein Passwort auf AS400 und in Windows erneut verändert habe funktioniert es wieder.

Danke
Gruß
DD3TJ
Thibaut Foucart

[mahones]

Hallo,

ich bin mal so frei und buddel diesen Thread wieder aus, denn wir haben so ungefähr das gleiche Problem.
Zum technischen Hintergrund: wir haben V7R1 im Einsatz, auf dem Server ist Windows 2012 R2.
Unsere IBMi ist hier im Netzwerk, und der Windows-Server steht in einer anderen Domäne.

Wir laden auch über ein Programm mit CPYTOSTMF [...] TOSTMF('/QNTC/...') eine Datei auf diesen Server. Bis vor kurzem hat das auch einwandfrei funktioniert.
Da es nicht täglich genutzt wird, kann ich also nicht genau sagen, bis wann, aber seit gestern, wo die Mitarbeiter wieder das Programm aufriefen, funktioniert es nicht mehr.
Auch ein manuelles WRKLNK '/QNTC/<SERVER-IP>' funktioniert nur eingeschränkt.
Ich kann zwar in das Verzeichnis des Servers rein, aber mir wird nichts angezeigt - keine weiteren Verzeichnisse und auch keine Dateien. Im Joblog erscheint aber genau dieselbe Fehlermeldung wie schon oben geschrieben.

Wir haben eine weitere IBMi, die im selben Netzwerk ist, wie der Windows-Server - auch hier erreiche ich mit WRKLNK nur das Verzeichnis und bekomme im Joblog die Fehlermeldung.

Wir haben (vor allem nicht alle Benutzer!) keine Kennwörter verändert oder sonstige Konfigurationsänderungen vorgenommen.

Wie können wir diesem Problem nun auf die Schliche kommen?

Interessant fand ich die Frage von dir, Fuerchau, bzgl. des Kennworts "Ist das Kennwort max. 10-Stellig in Großbuchstaben ?"
=> auf der IBMi gibt es doch nur (zumindest bei unserer Passwortstufe) Kleinbuchstaben - und auch auf dem Server ist zumindest mein Kennwort kleingeschrieben. (Ich hatte mal das Problem, dass ich einen Mix in der Domäne verwendet habe, und dadurch wurde ich immer wieder bei der AS/400 rausgeschmissen - daher meine ich, dass das mit den Kleinbuchstaben notwendig ist.)

[hel400]

Genau so ist es. Kennwort Windowsseitig in Kleinbuchstaben und AS400-seitig ohne Shifttaste eingeben, das ist am problemlosesten.

Mahones, so wie Du das Problem beschreibst, hat es tatsächlich mit der Authentifizierung zu tun, genau so verhält sich das Ganze dann (man kann sich zwar scheinbar verbinden, es wird im QNTC dann aber nichts angezeigt).

Evtl. nochmals sicherstellen, dass auf beiden Systemen die PWs übereinstimmen und alles in Kleinbuchstaben ist?

[mahones]

Danke für die schnelle Antwort / Bestätigung!
Wir haben nun noch einmal für einen Benutzer alles neu angelegt:
- IBMi-Benutzer / PW
- Domänenbenutzer (in der fremden Domäne, identisches PW wie IBMi)
- Berechtigung auf dem Fileserver

...hat nix gebracht; es kommt immer noch die gleiche Fehlermeldung - auch nach einem Versuch mit den Großbuchstaben

[Fuerchau]

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]

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]

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]

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]

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]

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]

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.