nicht angemeldet
Windows-Benutzer ermitteln?
Guten Tag ;o)
Ich arbeite zur Zeit an einer kleinen MySQL-PHP-Lösung zum Tracken von Problemen und da stellt sich mir die folgende Frage:
Ist es möglich, an einem Browser per JavaScript, PHP oder Perl den angemeldeten Windows-Benuter zu ermitteln, also nicht den evtl. auf einem Webserver eingeloggten Benutzer, sondern den am Betriebssystem (Windows-Domäne, Workgroup, etc) ???
Wer könnte mir hier einen Tipp geben?
Danke-Gruß,
Sven
-
Hi,
Ist es möglich, an einem Browser per JavaScript, PHP oder Perl den angemeldeten Windows-Benuter zu ermitteln,
mit etwas serverseitigem eine clientseitige Begebenheit zu ermitteln, ist grundsätzlich nicht möglich. JavaScript hingegen hat nicht mal innerhalb des Browsers volle Bewegungsfreiheit, geschweige denn außerhalb desselben.
also nicht den evtl. auf einem Webserver eingeloggten Benutzer, sondern den am Betriebssystem (Windows-Domäne, Workgroup, etc) ???
Woher willst Du eigentlich wissen, dass es so etwas wie eine "Windows-Domäne" oder einen "Windows-Benutzer" überhaupt gibt? Auf einem nicht-Windows-Betriebssystem, welche man mehr und mehr findet, dürftest Du ziemlich erfolgfrei sein. Aber auch unter Windows müsstest Du schon eine nicht unerhebliche Sicherheitslücke ausnutzen, falls es so eine gibt.
Nein, diese Information geht Dich als Bereitsteller einer Internet-Site nichts an.
Cheatah
-
Woher willst Du eigentlich wissen, dass es so etwas wie eine "Windows-Domäne" oder einen "Windows-Benutzer" überhaupt gibt? Auf einem nicht-Windows-Betriebssystem, welche man mehr und mehr findet, dürftest Du ziemlich erfolgfrei sein. Aber auch unter Windows müsstest Du schon eine nicht unerhebliche Sicherheitslücke ausnutzen, falls es so eine gibt.
Das weiss ich, weil es eine _firmeninterne_ Anwendung werden soll *grins*
Nein, diese Information geht Dich als Bereitsteller einer Internet-Site nichts an.
Siehe oben, ich möchte meinen Mitarbeitern ersparen, dass diese jedes Mal von Hand Ihre User-ID eingeben sollen, also quasi als Service. Für das Tracking der Daten benötige ich Ihre User-ID, weil über diese später eine Notifaction-Mail gesendet wird. Also in diesem - zugegebenen - sehr speziellen Fall geht mich diese User-ID aus der Windows-Domäne sehr wohl etwas an.
PS: Nicht immer negativ denken ;o)
Gruß,
Sven
-
Hi,
Nein, diese Information geht Dich als Bereitsteller einer Internet-Site nichts an.
Siehe oben,weder HTTP noch HTML/JavaScript/etc. kennen einen Unterschied zwischen Inter- und Intranet. Nach allen Regeln der Kunst _bist_ Du der Bereitsteller einer Internet-Site.
In einem Intranet hast Du lediglich deutlich mehr Kontrollmöglichkeiten den Client betreffend, sowie mehr Kenntnisse über den Benutzerkreis. Beispielsweise ist irgendwo im Netzwerk konfiguriert, wer von welcher IP aus agiert - dieses Wissen kannst Du nutzen. HTTP- oder JavaScript-Mechanismen sind für das Internet konzipiert und helfen Dir daher nicht.
PS: Nicht immer negativ denken ;o)
Ich denke nicht negativ, sondern realistisch :-) weil ich die Grenzen der Technik kenne. Ich weiß, wann man sinnvollerweise zu hoffen aufhören und sich statt dessen nach Alternativen umgucken sollte.
Cheatah
-
Hi Sven,
Das weiss ich, weil es eine _firmeninterne_ Anwendung werden soll *grins*
Diese Information gehört _zwingend_ in Deine Fragestellung.
_Mit_ ihr wird die Antwort natürlich anders ausfallen.Siehe oben, ich möchte meinen Mitarbeitern ersparen, dass diese jedes
Mal von Hand Ihre User-ID eingeben sollen, also quasi als Service.
Für das Tracking der Daten benötige ich Ihre User-ID, weil über diese
später eine Notifaction-Mail gesendet wird. Also in diesem - zugegebenen- sehr speziellen Fall geht mich diese User-ID aus der Windows-Domäne
sehr wohl etwas an.
Okay, dann lautet die Antwort nicht "das geht nicht, weil serverseitige
Logik clientseitige Informationen nicht kennt und JavaScript aufgrund
seines Sicherhsitskonzepts nicht auf solche Informationen zugreifen kann",
sondern "verwende eine in Deine Installation verfügbare _andere_, ggf.
proprietäre Technologie wie ActiveX, um unter Umgebung der ansonsten
geltenden Sicherheitskonzepte die gewünschten Informationen zu erhalten".Die Frage ist natürlich, ob in diesem Falle HTTP überhaupt noch das
Protokoll Deiner Wahl sein sollte.Viele Grüße
Michael-
Hallo Michael,
Die Frage ist natürlich, ob in diesem Falle HTTP überhaupt noch das
Protokoll Deiner Wahl sein sollte.das ist zwar richtig, allerdings hat HTTP m.E. in diesem Bereich unbestreitbare Vorteile, und zwar dann, wenn man mehrere System Management-Disziplinen wie Reporting, Problem Management, Change Management, Konfigurationsmanagement usw. untereinander bzw. mit allgemeinen Informationen wie z.B. einem Telefonverzeichnis verknüpfen möchte. Gerade im Hinblick auf die Ausbaufähigkeit sehe ich dort kaum Grenzen.
Allerdings muß man bei dem Ganzen wohl _eine_ zusätzliche Authentifizierung in Kauf nehmen.
Nun habe ich eine Frage die Serverspezialisten: Wäre es grundsätzlich praktikabel, (auf Unix-Systemen) per Cronjob einen Teil der vorhandenen Benutzerinformationen aus der /etc/shadow in die entsprechende .htpasswd zu übertragen, um den Benutzern eine zusätzliche Passwortänderung zu ersparen, oder siehst Du da Probleme?Schönen Gruß aus Bilk
Rainer
-
Hi Rainer,
Wäre es grundsätzlich praktikabel, (auf Unix-Systemen)
per Cronjob einen Teil der vorhandenen
Benutzerinformationen aus der /etc/shadow in die
entsprechende .htpasswd zu übertragen, um den
Benutzern eine zusätzliche Passwortänderung zu
ersparen, oder siehst Du da Probleme?Ich formuliere es mal so: _Wenn_ offensichtlich die
Benutzer shell-Zugang haben und ihr Passwort ändern
dürfen _und_ gleichzeitig ein semantischer Spiegel
dieser Passworte in Form einer .htpasswd existiert,
wieso möchtest Du dann nicht beide Änderungen als
Transaktion durchführen?
Du kannst doch das Kommando /bin/passwd durch ein
shell-Skript ersetzen, welches diese beiden Opera-
tionen bündelt - dann merken Deine UNIX-Benutzer
nicht mal etwas davon.Bei der crontab-Lösung hättest Du immer das Problem,
daß jemand sein Shell-Passwort ändert und sich dann
ärgert, daß auf der HTTP-Schiene solange das alte
Passwort gilt, bis der cron-Job gelaufen ist. Das
wäre nicht wirklich vertrauensbildend und benutzer-
freundlich.Viele Grüße
Michael
-
- sehr speziellen Fall geht mich diese User-ID aus der Windows-Domäne
-
-
-
Hallo,
also mit JavaScript nicht aber mit JScript, ActiveX und dem IE.
Über WScript.Network kannst Du den User abfragen.var oNet = new ActiveXObject("WScript.Network");
var user = oNet.UserName;Der Server, der diese Seite bereitstellt, sollte als "Vertrauenswürdige Seite" aufgeführt werden, damit kein Abfragefenster aufgeht. Aber wie gesagt, IE, JScript, ActiveX...
britta
-
Hallo,
mit ASP + IIS würde es schon gehen...
hier mal ein ASP-Script, das alle servervariablen und deren Inhalt auflistet:
<%
response.write cstr(time) & "<br><br>"
for each alles in request.servervariables
response.write alles & ": " & request.servervariables(alles) & "<br>"next
%>LOGON_USER ist normalerweise leer, wenn aber beim Intranetserver eine bestimmte Art der Authentifizierung eingestellt ist enthält dieser den Anmeldenamen des momentan am Windows-System angemeldeten Users...
Ansonsten kannst du mit PHP die IP des Clients auslesen und dann innerhalb einer Textdatei oder DB vergleichen und hast deine Daten...
Nachteil:1. Daten müssen erstmal gesammelt werden...
2. was ist wenn ein anderer Mensch am Rechner sitzt?Odium