NamedPipe + Zugriffsrechte + CreateProcessAsUser

29/03/2013 - 00:16 von Robert Hartmann | Report spam
Hallo zusammen,

Ich habe wunderbare Hilfen neben der MSDN-Library zu den
Windowszugriffsrechten gefunden und gelesen [1],[2] und [3]
... aber wohl nicht ganz begriffen.



Folgendes Szenario:
Verschiedene Computer im lokalen Netzwerk (IP-Vergabe per DHCP)
Verschiedene Betriebssysteme
Linux-Varianten, MacOS-Varianten
Windows-Varianten: (einzelne NT4, Mehrheit XP, einige Win7 und Win8)


zwei fremdprogrammierte Anwendungen
(entfernte Service-Anwendung im LAN, lokale Nutzer-Anwendung)

meine Baustelle Windowswelt:
Proxy-Anwendung service-seitig und nutzer-seitig.

Bildlich:

ServiceAnwendung <=socket localhost=> ServerProxy

<==NamedPipe==>

ClientAnwendung <=socket localhost=> ClientProxy


ServerProxy und ClientProxy kommunizieren nun über eine NamedPipe, die
Nachrichten der beiden Endanwendungen werden prinzipiell auch durchgereicht.


Algorithmus:
ServerProxy listen
ClientProxy connect
ServerProxy send who
ClientProxy send SID
ClientProxy listen
ServerProxy ???????? startet ServiceAnwendung (bisher manuell)
ServiceAnwendung wartet
ServerProxy send ok
ClientProxy startet ClientAnwendung

ClientAnwendung beendet => ClientProxy beendet
=> ServerProxy beendet ServiceAnwendung und wartet auf neue Anfragen



1.Problem: Nutzungsbedingung der NamedPipe
a)Mit der NamedPipe sollen sich nur die Nutzer von ausgewàhlten
Workgroups oder NT-Domainen verbinden können mit Lese und Schreibzugriff.
b)LocaleNutzer auf Clientseite dürfen, wenn sie kein DomainAccount sind,
mit der Pipe kommunizieren, wenn es auf der Serverseite zufàllig einen
gleichen lokalen Account gibt.
c) Können auch nicht Windows-Betriebssysteme an Windows NamedPipes
"angeschlossen" werden?

(Ich vermute 1.b làsst sich nicht umsetzen und 1c wird nicht möglich sein.)


2.Problem: Die ServiceAnwendung auf dem Server muss im
Nutzerkontext insbesondere auch im Sicherheitskontext der
ClientAnwendung laufen, wichtig für z.B. Dateizugriff und
das einbinden von Netzwerklaufwerken etc, gleichzeitig
darf der Server den "Login-Bildschirm" nicht verlassen.




Mein ClientProxy darf den Nutzer nicht nach Username, Domain und
Passwort fragen, denn er ist ja schon angemeldet; somit kann der
Proxy nur SIDs austauschen ...

Aber mit SID kann ich kein LogonUser machen oder habe ich was übersehen?


ImpersonateNamedPipeClient veràndert den Sichheitskontext der falschen
Seite.

ImpersonateLoggedOnUser kann ich nicht verwenden, denn der Nutzer ist
auf dem Server nicht eingelogt

ImpersonateSelf könnte hilfreich sein aber wie setze ich dann
praktisch den Wechsel zum Userkontext um?





Besten Gruß und eine frohes Osterfest,
Robert


[1]
http://www.codeproject.com/Articles...and-binary

[2]
http://www.codeproject.com/Articles...del-Part-1
http://www.codeproject.com/Articles...del-Part-2

[3]
WINDOWS OS SECURITY

http://www.tenouk.com/ModuleH.html
http://www.tenouk.com/ModuleH1.html
http://www.tenouk.com/ModuleH2.html
http://www.tenouk.com/ModuleI.html
http://www.tenouk.com/ModuleI1.html
http://www.tenouk.com/ModuleI2.html
http://www.tenouk.com/ModuleI3.html
http://www.tenouk.com/ModuleJ.html
http://www.tenouk.com/ModuleJ1.html
http://www.tenouk.com/ModuleK.html
http://www.tenouk.com/ModuleK1.html
http://www.tenouk.com/ModuleL.html
http://www.tenouk.com/ModuleL1.html
 

Lesen sie die antworten

#1 Schmidt
30/03/2013 - 00:33 | Warnen spam
Am 29.03.2013 00:16, schrieb Robert Hartmann:

ImpersonateLoggedOnUser kann ich nicht verwenden, denn der
Nutzer ist auf dem Server nicht eingelogt



Mit dem Problem habe ich bei meinem (socketbasierten)
Service auch zu kàmpfen gehabt.
Also ohne (Pipe-)Proxies, per direkter Socket-Kommunikation...

Die über Sockets einlaufenden "Client-Jobs" enden letztlich
in einem (beliebigen) Thread aus einem serverseitigen
Worker-Threadpool.

Der Server-Listener stellt in der (keep-alive basierten)
"ClientSocket-Connect-Phase" einmalig eine Assoziation
mit dem serverseitig diese Client-Connection repràsentierenden
Socket-Handle her (über eine "Connection-Pool-MemberKlasse) -
und performt dann auf Serverseite in dieser mit dem SocketHandle
assoziierten Connection-Klasse einmalig einen 'LogonUser'-API-Call
(nach ein wenig Diffie-Hellman-Ping-Pong kurz nach dem Connect).

Habe also keine andere Möglichkeit gefunden, als den Client
über einen User-Dialog nochmalig sein Passwort- und den Domain-
Namen angeben zu lassen. Den aktuellen UserName bekommt man
ja per API geliefert, den aktuellen Domain-Name für einen
gegebenen clientseitigen Logon kriegt man clientseitig auch
noch raus (um den Dialog vorzubesetzen) - was bleibt, ist halt
das Passwort...

Wenn es möglich ist, auf Clientseite über eine User-SID -
oder auf anderen "offiziellen Wegen" das Passwort "automatisiert"
herauszubekommen, dann würde ich das ebenfalls gern wissen, aber
das ist wohl nicht so ganz im Sinne des Erfinders... ;-)

Und für die Serverseite habe ich einfach nix anderes gefunden,
was als Alternative zum LogonUser-Call herhalten hàtte können.

Naja - ich beschreib das noch kurz zu Ende, was serverseitig
passiert - aber in den sauren Apfel der clientseitig nötigen
"Passwort-Doppeleingabe" wirst Du (IMO) nicht umhin kommen.
(Es sei denn, Du ersetzt den zentralen Client-Logon-Dialog mit
was Eigenem - was ja auch irgendwo geht - unter XP noch per
GINA - und seit Vista über "Windows Credential Providers").

Also die serverseitige Connection-Klasse bleibt solange die
Socket-Connection besteht, am Leben - und hàlt intern dann
das einmalig per LogonUser ermittelte Logon-hToken.

Neu einlaufende Job-Pakete in diesen serverseitigen Connection-
Klassen, kleben dann an den jeweiligen Job immer das aktuelle
hToken, bevor der Job in den Worker-Threadpool übergeben wird.

Und da solch ein WorkerThread nicht "weiss", welchen Job von
welchem Client er als nàchstes bekommt, wird von ihm für jeden
dieser einlaufenden RPCs eine Impersonation um den Job-Call gelegt.

ImpersonateLoggedOnUser(Job.Description.hToken)

//perform the RPC

RevertToSelf

Das funktioniert in guter Performance (unterhalb 1msec -
lange nicht mehr gemessen) für jeden Job explizit.


ImpersonateSelf könnte hilfreich sein aber wie setze ich dann
praktisch den Wechsel zum Userkontext um?



ImpersonateSelf scheint mir ungeignet in Deinem Szenario,
da Du ja schriebst, dass Du auf Serverseite noch überhaupt
gar keine (auf spezielle Client-Accounts gemappte) Prozesse
oder Threads am Laufen hast.

Wie gesagt, anders als über LogonUser(Ex) hab ich das jedenfalls
nicht hinbekommen serverseitig - und diese Calls erfordern nunmal
eine Passwort-Angabe.

Olaf

Ähnliche fragen