NamedPipe + Zugriffsrechte + CreateProcessAsUser

[Robert Hartmann]

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/1670/Converting-SIDs-between-strings-and-binary

[2]
http://www.codeproject.com/Articles/10042/The-Windows-Access-Control-Model-Part-1
http://www.codeproject.com/Articles/10200/The-Windows-Access-Control-Model-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

[Schmidt]

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

[Robert Hartmann]

Hallo Olaf,

Danke für Deine Hilfestellung.


Am 30.03.2013 00:33, schrieb Schmidt:[...]
> Und für die Serverseite habe ich einfach nix anderes gefunden,
> was als Alternative zum LogonUser-Call herhalten hätte können.

[...]

> Wie gesagt, anders als über LogonUser(Ex) hab ich das jedenfalls

> nicht hinbekommen serverseitig - und diese Calls erfordern nunmal
> eine Passwort-Angabe.

Nach diesem Paper [1] müsste das serverseitige starten eines Prozesses
im Sicherheitskontext des Clients *ohne* Passwort-Abfrage bei Verwendung
von NamedPipes, wie in meinem Fall, so funktionieren:

Server stellt die Pipe zur Verfügung.
Client verbindet sich, nach dem ersten Datensenden des Clients
zum Server soll server-seitig funktionieren:


ImpersonateNamedPipeClient
falls erfolgreich
OpenThreadToken
DuplicateTokenEx
CreateProcessAsUser
sonst Fehler

Vielleicht ist für Deine socket-basierte Anwendung folgendes interessant:
Unter neueren Windows Varianten gibt es auch die Authentifikation
mittels SID, siehe AuthzInitializeContextFromSid [2].

Auch LsaLogonUser braucht wohl kein Passwort [3 und 4].

Gruß Robert

[1] http://www.blakewatts.com/namedpipepaper.html

[2]
http://msdn.microsoft.com/en-us/library/windows/desktop/aa376309%28v=vs.85%29.aspx

[3]
http://msdn.microsoft.com/en-us/library/windows/desktop/aa378292%28v=vs.85%29.aspx

[4] Interessant auch "Exploring S4U [...] in Windows"
http://msdn.microsoft.com/de-de/magazine/cc188757%28en-us%29.aspx#S2

[Schmidt]

Am 31.03.2013 23:18, schrieb Robert Hartmann:

> Danke fï¿œr Deine Hilfestellung.

Danke auch fï¿œr Deine Links - mein Posting war mehr gedacht als
"Bestï¿œtigender Success-Report einer u.U. in Betracht zu ziehenden,
sicher funktionierenden Fallback-Lï¿œsung" - oder so ï¿œhnlich... ;-)

Ich schau mir Deine "socket-bezogenen" Links demnï¿œchst mal an,
da scheinen ï¿œber die letzten Jahre tatsï¿œchlich ein paar mehr
Alternativen hinzugekommen zu sein...

Wï¿œre trotzdem schï¿œn (falls Du irgendwas anderes als den offensichtlich
funktionierenden LogonUser(Ex)-Call am Ende zum Laufen bekommst, z.B.
den Ansatz ï¿œber ImpersonateNamedPipeClient), wenn Du die nï¿œtigen
Schritte bzw. "Parameter-Tricks" dann hier reintun wï¿œrdest.

Das Thema gehï¿œrt ja nicht unbedingt zu den mit konkreten Beispielen
"in Hï¿œlle und Fï¿œlle" besetzten.

Immer gut, wenn man mal irgendwo ein konkretes, "ich hab's so -
und so - und so, auf dem und dem Zielsystem zum Laufen bekommen"
irgendwo nachlesen kann.


Olaf