ProtectionLevel / ImpersonationLevel-Problem

Hi, ich mal wieder mit meinen Remoting-Problemen...

Ich habe bereits gegoogelt ohne Ende aber trotzdem hat noch nichts zur Lösung geführt 🙁

Zunächstmal habe ich mitlerweile die Netzwerkgrundlage aus dem eigentlichen Programm herausextrahiert, um die Fehler schneller zu finden.
Hat mir bis jetzt einmal geholfen, aber egal - auf zum Problem:

Ich habe die Fehlermeldung
A remote side security requirement was not fulfilled during authentication. Try increasing the ProtectionLevel and/or ImpersonationLevel.

Wenn ich die dortdrin erwähnten Parameter verändere, ändert sich gar nichts.
Dieser Fehler tritt auf, wenn ein entfernter Rechner versucht auf den Client zu verbinden. Lokal geht es nach wie vor.

Hier meine Netzwerkgundlage:
www.krifi-ware.de/ngame/NetworkEngine.zip
(kurze Anmerkung: Der TcpChannel wird auf dem Server in iniTCPChannel erstellt)

Ich hoffe das ihr mir helfen könnt, da ich langsam am verzweifeln bin mit den ganzen *** Netzwerkrechten...

Hier die gesamte Exception (ohne Assemblies):
************** Exception Text **************
System.Security.Authentication.AuthenticationException: A remote side security requirement was not fulfilled during authentication. Try increasing the ProtectionLevel and/or ImpersonationLevel. ---> System.ComponentModel.Win32Exception: The network logon failed
--- End of inner exception stack trace ---

Server stack trace:
at System.Net.Security.NegoState.ProcessAuthentication(LazyAsyncResult lazyResult)
at System.Net.Security.NegotiateStream.AuthenticateAsClient(NetworkCredential credential, String targetName, ProtectionLevel requiredProtectionLevel, TokenImpersonationLevel allowedImpersonationLevel)
at System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.CreateAuthenticatedStream(Stream netStream, String machinePortAndSid)
at System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.CreateSocketHandler(Socket socket, SocketCache socketCache, String machinePortAndSid)
at System.Runtime.Remoting.Channels.SocketCache.CreateSocketHandler(Socket socket, String machineAndPort)
at System.Runtime.Remoting.Channels.RemoteConnection.CreateNewSocket(EndPoint ipEndPoint)
at System.Runtime.Remoting.Channels.RemoteConnection.CreateNewSocket()
at System.Runtime.Remoting.Channels.SocketCache.GetSocket(String machinePortAndSid, Boolean openNew)
at System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.SendRequestWithRetry(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream)
at System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.ProcessMessage(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream, ITransportHeaders& responseHeaders, Stream& responseStream)
at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage msg)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Interface.IServer.test(String msg, IClient cO)
at Client.Form1.btnSend_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

System.ComponentModel.Win32Exception: The network logon failed

Da steht der Fehler glasklar geschrieben!
Der entfernte Server kann sich am Client-Computer nicht anmelden. Dafür kann es folgende Gründe geben:*Client- und Server-Computer gehören zu unterschiedlichen Domänen *Einer der beiden Computer ist in einer Domäne, der andere nicht *Der SSPI-Provider hat Kerberos als Authentifizierungsprotokoll ausgehandelt, aber der Client kann die Identität des Server-Computers nicht überprüfen (z.B. wegen restriktiver Firewall-Einstellungen oder sonstigen Konfigurationsproblemen) *Beide Computer laufen im Arbeitsgruppenmodus (also ohne Domäne), aber Benutzernamen und Passwörter der Benutzer, die von der Remoting-Anwendung verwendet werden, sind auf den beiden Computern nicht 100% identisch angelegt (Bei NTLM muss Benutzername und Passwort genau übereinstimmen und die Benutzer müssen auf allen beteiligten Computern in Lokale Benutzer und Gruppen angelegt sein) *Die Lokale Sicherheitsrichtlinie oder ein Active Directory-Gruppenrichtlinie verweigern bestimmten Benutzern oder Gruppen den Netzwerkzugriff auf den gewünschten Computer *Die Server-Anwendung läuft unter einem Integrierten Sicherheitskonto (z.B. NetworkService oder LocalSystem); Interne Sicherheitskonten kann ein entfernter Computer nicht authentifizieren

Höchstwahrscheinlich trifft eine der obigen Punkte auf Deine Umgebung zu.

Dieser Fehler tritt auf, wenn ein entfernter Rechner versucht auf den Client zu verbinden. Lokal geht es nach wie vor.

Der Remoting-Host greift also zwecks Rückruffunktion auf den Client zu, richtig?

Funktioniert den entfernte Zugriff des Clients auf den Server überhaupt korrekt?

Nein, vielleicht habe ich das nicht ganz richtig Ausgedrückt:

Die Verbindung (registerChannel(...)) geht ohne Probleme.
Dann will der Client auf dem Server etwas ausführen (in dem Projekt-Archiv die Prozedur remServer.test()).

Da tritt dieser Fehler auf dem Client auf.
Andersherum, ob der Server auf dem Client etwas ausführen kann, kann ich ja nicht prüfen, da der Server das clientObject : IClient, MarshalByRefObject noch nicht hat und daher ja nicht weiß wohin er die Antwort schicken soll.

Die Verbindung soll, sofern keine FW etc. im Weg ist, von jedem beliebigem PC - egal welche Domain/welches Netzwerk/welche IP etc., halt übers Internet - zum Server hergestellt werden können.
Mir fehlt im Prinzip "einfach" "nur" sowas wie: securityFunctions = false;
Halt das das Framework nicht dazwischenfunkt, wenn der PC unbekannt ist.

Danke schonmal für deine regelmäßige Hilfe 😉

@rainbird:
Ich hab gerade gemerkt, dass dein Beispiel "Rainbird.Tools.EasyRemoting Projektmappe.zip" genau das gleiche Problem hat wie ich 😉

Hallo Hunv,

ja, mir ist ein problem bekannt, welches in diese Richtung geht, aber das wurde im entsprechenden Snippet-Thread ausführlich diskutiert: Remoting-Helfer

Bei Verwendung von EasyRemoting wird eine Ausnahme geworfen, wenn der Server Objekte eines Client aufrufen soll. Grund dafür ist, dass bei der Konfiguration des Client-Kanals nicht explizit der Port 0 festgelegt ist. Das lässt sich aber mit einer einzigen Zeile Code nachholen, wie im oben beschriebenen Thread gezeigt. Ich habe die Projektmappe zum herunterladen nur noch nicht aktualisiert.

Trotzdem glaube ich nicht, dass es sich um das Selbe Problem handelt, da bei dem bekannten EasyRemoting-Problem folgende Ausnahme geworfen wurde:

Der Remoteproxy hat keinen Channelempfänger, d.h. der Server besitzt keine registrierten Serverchannel oder die Anwendung hat keinen passenden Clientchannel, um mit dem Server zu kommunizieren.

Bitte füge in der Methode SetupClientChannel folgende Zeile hinzu und versuche, ob es dann mit dem Remoting-Helfer funktioniert:

channelSettings["port"] = 0;

Wenn Du dann die selbe Sicherheitsfehlermeldung bekommst, glaube ich wirklich, dass es sich um den selben Fehler handelt.

Das mit dem Port 0 hatte ich bereits eingetragen.
Die IP des Hostes hab ich natürlich ebenfalls angepasst.

Ich hab mal n Screenshot rangehängt, damit dus mir glaubst 😉

Hallo Hunv,

die Authentifizierung funktioniert bei Remoting (TcpCahnnel) außerhalb einer Active Directory-Domäne über das NTLM-Protokoll. Der "NTLM-Sicherheitsdienst" muss auf allen betroffenen Rechnern gestartet sein. Außerdem müssen bestimmte Ports in der Firewall geöffnet werden (Müsstest Du im Microsoft TechNet nachsehen, welche das bei NTLM sind). Über Internet ist das nicht zu empfehlen.

Die Sicherheit ausschalten wäre eine Option (natürlich nur, wenn die Anwendung keine vertraulichen Daten transportiert). Du kannst die Sicherheit der TcpChannels über die Eigenschaft Secure=False komplett ausschalten.

channelSettings["secure"] = false;

Damit es funktioniert, muss die Sicherheit bei Server und Client gleichermaßen abgeschaltet werden.

Mein Remoting-Helfer unterstützt auch einen Modus, der ohne Authentifizierung funktioniert.