aktuellen User bestimmen

[tutter 0]

Leider fiel mir keine beschreibendere Überschrift ein als diese. Ich mache eine SQL Server Verbindung über die Windows Authentifizierung mit PHP sqlsrv_connect. Das funktioniert auch (endlich) jedoch weiß ich gar nicht wer sich angemeldet hat. ich bekomme naturlich raus wer alles auf dem SQL Server angemeldet ist aber ich würde gern wissen wer der Domain User ist der sich gerade über sqlsrv_connect mit PHP angemeldet hat. Dabei geht es mir um den Namen im weiteren Verlauf den ich in einem Cookie anderen Skripten zur Verfügung stellen will.

 

Kann hier vielleicht jemand mir helfen?

 

danke schon mal

[zahni 521]

Ich kann hier nur  allgemein antworten:

 

Bei PHP gehe ich mal von  einer Web-Anwendung aus.

Es ist ein ganz schlechtes Design, wenn ein User  sich über ein Web-Frontend direkt  auf  einen Datenbankserver  anmeldet.

Hier sollte nach Möglichkeit immer mit  technischen Usern gearbeitet werden, deren Konten nicht weiter bekannt sind.

Zum Session-Sharing zwischen anderen Anwendungen gibt es  genügend Lösungen. Man schreibt  die (User).Daten aber nicht ein Cookie.

 

Selbstverständlich ist das auch Abhängig von der konkreten Anwendung. 

[Dukel 436]

Wie meldest du dich an der Webapplikation an?

Ich würde in jedem Fall kein Cookie zur Speicherung von Usernamen für die Authentifizierung nutzen.

[tutter 0]

Einwand zur Kenntnis genommen! Aber die Anforderung ist genau jene das die Nutzer sich eben ohne zusätzliches Login bei der Anwendung anmelden sollen. Um den gegen zu wirken, habe ich versucht die Rechte so extrem wie möglich zu beschneiden, damit nur das nötigste gemacht werden kann! Es geht mir außerdem nur um den User Name aus Komfortgründen damit in diversen Formularen nicht immer der Name eingegeben werden muss.

anmelden tut sich der User nur über seine Windows Authentifizierung sprich er meldet sich in Windows an (an der Domain). Wenn er über ein Windowsauthentifizierungs Login am SQL Server hat kann er die Anwendung nutzen wenn nicht kommt eine Meldung und er kann ein Workflow starten um eine Anmeldung zu erhalten.

 

Diese Applikation läuft intern in einem Netzwerk mit Domain. Damit sollten doch auch Cookies gehen! Somal darin ja nur der Name des Users stehen soll.

bearbeitet 20. August 2014 von tutter

[zahni 521]

Auch wenn die Anwendung sich per Browser-SSO anmeldet, sollt diese Anmeldung nicht  an den SQL-Server durchgereicht  werden.

Nur als Beispiel: SharePoint macht  das  auch nicht.

So etwas kann eine erhebliche Sicherheitslücke öffnen. Speziell wenn die Anwendung auch eine alternative  Anmeldemöglichkeit bietet.

Sie Anwendung selbst kenne ich nicht. Normalerweise kann man aber bei Web-Anwendungen via SSO den Usernamen aus den Servervariablen extrahieren.

Bei ASP (vbscript) wäre dies  Request.ServerVariables("AUTH_USER")

[Dukel 436]

Was für Formulare denn? Ich hoffe es sind keine Anmeldungen für anderen Applikationen.

 

PHP kennt auch den Authentifizierten User:

http://php.net/manual/de/reserved.variables.server.php

echo $_SERVER['PHP_AUTH_USER'];

 

EDIT:

Es spricht prinzipiell nichts dagegen sich an einer DB zu authentifizieren. Dabei kann man direkt an der Quelle Rechte vergeben und muss das nicht in einer Zwischenschicht (auf dem Applikationsserver) machen.

Mit SharePoint gibt es auch die Möglichkeit mit einem User auf externe Datenquellen (u.A. SQL Server) zuzugreifen. Dies wird mit Kerberos Delegation umgesetzt.

bearbeitet 20. August 2014 von Dukel

[zahni 521]

 

Es spricht prinzipiell nichts dagegen sich an einer DB zu authentifizieren. Dabei kann man direkt an der Quelle Rechte vergeben und muss das nicht in einer Zwischenschicht (auf dem Applikationsserver) machen.

Mit SharePoint gibt es auch die Möglichkeit mit einem User auf externe Datenquellen (u.A. SQL Server) zuzugreifen. Dies wird mit Kerberos Delegation umgesetzt.

 

Das sehe ich ein wenig anders. Bei BCS meldet man sich optimaler weise mit einem im Secure Store hinterlegten Konto bei einer externen Datenquelle an.

Die Zugriffsrechte  auf diesen BCS kann man dann  im BCS konfigurieren.

Bei einem Webservice mag das  im Speziellen anders sein. Bei Datenbanken sollte man das aber eher vermeiden.

Direkt durchgereichte Datenbank-Anmeldungen  wurden schon oft zum Hacken von (DB)-Servern verwendet.

[Dukel 436]

Es gibt ja nicht nur BCS (wobei man das mit der Claims Authentifizierung dann so machen muss, da Kerberos Constraint Delegation nicht mehr geht).

 

Ich finde es erhöht die Sicherheit, wenn man das ganze in einem gescheiten Konzept umsetzt. Oft hat ein DB User, welcher viel zu viel Rechte besitzt (z.B. DB Owner) und wenn man (wie auch immer) an diesen User kommt kann man mehr machen als wenn man nur mit den User Daten an die DB kommt und dort ganz wenig Rechte besitzt.

Wenn man einen DB Server hacken kann ist es eh ein prinzipielles Problem. Ich denke nicht, dass das grundsätzlich mit durch gereichten Anmeldungen zu tun hat.

 

Aus dem PHP Umfeld kenne ich das auch, dass man einen DB User hat und dort ist es oft auch so, dass dessen Credentials unverschlüsselt im FileSystem liegen und dort ist es in jedem Fall sicherer wenn nirgends Credentials gespeichert werden.

[tutter 0]

Sorry ich verstehe nicht ganz die Thematik mit dem Passwort. Nehmen wir an ich führe eine Datenbank in welcher die Logindaten hinterlegt sind und der User logt sich ein mit einer HTTP Authentifizierung. Auch hier kann das Passwort abgegriffen werden und der User hat eventuelle Rechte die den SQL Server gefährden. Klar der User kann sich nicht direkt am SQL Server sondern nur an der Datenbank/Tabelle anmelden (über ein Service-Konto) aber mit SQL injection oder php injection kann er dann doch genau den gleichen Schaden anstellen, als wenn er sich direkt am SQL Server anmeldet und dort innerhalb seiner Rechte Schaden anrichtet oder sehe ich hier was falsch? 

 

@Dukel habe deinen Tipp mal umgesetzt aber er bringt mir die Fehlermeldung : Undefined index: PHP_AUTH_USER . Wenn ich das richtig gelesen habe funktioniert doch echo $_SERVER['PHP_AUTH_USER']; nur unter HTTP Authentifizierung oder?

[Dukel 436]

Du kannst deine eigene Identität per SQL Statement abfragen:

http://blog.sqlconcepts.co.nz/2011/07/who-am-i.html

 

Was passiert, wenn der User in den Formularen einen anderen User einträgt? Wieso Authentifizierst du dich nicht mit der Webapplikation und nutzt diese Authentifizierung?

[tutter 0]

deswegen ja die Thematik mit der User Identifikation. Problematisch wäre es aber bei der Anwendung auch nicht, da hierauf keinerlei wert gelegt wird (ja richtig gelesen! solche Anforderungen soll es geben :D  ) aber wie schon geschrieben es ist leider Pflicht das es eine Authentifizierung sein soll die ohne zusätzliche Passworteingabe stattfindet am besten eben AD. Naja und das tut es ja auch :wink2:

[Dukel 436]

Du kannst dich auch Passwortlos an PHP anmelden.

http://php.net/manual/de/book.kadm5.php

 

Dann bekommst du auch deine Servervariable gefüllt und musst nicht mit Cookies pfuschen.

[tutter 0]

puh das müsste ich mir erst mal ganz genau anschauen, vor allem infrastrukturtechnisch wäre das hier ein Großprojekt wahrscheinlich!

declare @1 nvarchar(50);
set @1 = cast((select [Function] = CONVERT(sql_variant, ORIGINAL_LOGIN())) as nvarchar(50));


select substring(@1,7,50) as Benutzername;

werde jetzt erstmal das nutzen je nach Domainnamenlänge muss der Substring angepasst werden aber ansonsten sollte es passen

bearbeitet 20. August 2014 von tutter

[Dukel 436]

Mein Tipp: Lass dir das ganze von einem Softwarehaus Programmieren.

[tutter 0]

warum ist der source so schlecht?