nicht angemeldet
Integrierte Windows-Authentifizierung durch Formular ermöglichen
Hallo alle,
ich habe gerade eine etwas knifflige Aufgabe bekommen. Externen Mitarbeitern soll ermöglicht werden auf das Intranet zuzugreifen (z.B. um ihren Mail-Account zu erreichen). Die Anmeldung wird über die Integrierte Windows-Authentifizierung realisiert. Problematisch daran ist, dass einige Mitarbeiter aus dem Netz einer anderen Firma auf das Intranet zugreifen und der Anmeldedialog in diesem Netz gesperrt wird.
Gibt es eine Möglichkeit die Authentifizierung statt über den Dialog über ein Formular zu realisieren? Wie wird die Anmeldeinformation überhaupt gespeichert? Ist das eine Session? Leider finde ich zwar viele Informationen zum Thema Authentifizierung und Impersonation etc. aber keine zur Verbindung mit einem Formular.
Vielen Dank für die Hilfe,
small-step
-
...werde ich einen falschen Themenbereich wählen, dann hab ich wenigstens das Motzposting als Antwort :-)
Ich weiß, ich weiß. M$ und ASP.Net sind keine gern gesehenen Gäste hier. Aber ich hab keine andere Wahl.
Kennt jemand wenigstens ein gutes Forum das sich mit ASP.Net beschäftigt? Ich finde irgendwie nur Foren von verschüchterten Spinnern zu diesem Thema.
Gruß,
small-step -
Moin!
Die Anmeldung wird über die Integrierte Windows-Authentifizierung realisiert.
Dein Suchwort dazu ist NTLM.
Problematisch daran ist, dass einige Mitarbeiter aus dem Netz einer anderen Firma auf das Intranet zugreifen und der Anmeldedialog in diesem Netz gesperrt wird.
Naja, für problematisch halte ich noch ganz andere Sachen. Die Windows-Anmeldung für ein Extranet zu verwenden ist beispielsweise eine Schwachsinnsidee, weil diese in der Regel für Intranets benutzt wird. Welcher Idiot gibt dir seine eigenen Intranetanmeldedaten einer ganz anderen Firma, damit er auch bei dir ins Extranet kommen kann? Welcher Admin ist so blöd, diese Anmeldedaten überhaupt durch den Proxy durchzulassen? Welcher Browser läßt sich überhaupt dazu hinreißen, diese Daten freiwillig in die Welt hinauszusenden?
Mal abgesehen davon, dass von SSL z.B. überhaupt noch keine Rede war - spielen Sicherheitsaspekte keine Rolle?
Gibt es eine Möglichkeit die Authentifizierung statt über den Dialog über ein Formular zu realisieren?
Natürlich besteht die Möglichkeit, _eine_ Authentifizierung per Formular zu programmieren. Ein Ersatz für das unmögliche Einloggen per NTLM ist das aber nicht. NTLM ist eine Variation der HTTP-Authentifizierung - und auch die ist nicht formular-kompatibel.
Wie wird die Anmeldeinformation überhaupt gespeichert?
Siehe HTTP-Authentifizierung.
Ist das eine Session?
Nein.
Leider finde ich zwar viele Informationen zum Thema Authentifizierung und Impersonation etc. aber keine zur Verbindung mit einem Formular.
Was daran liegen dürfte, dass es da keine Verbindung gibt.
- Sven Rautenberg
--
My sssignature, my preciousssss!-
Hallo Sven,
Problematisch daran ist, dass einige Mitarbeiter aus dem Netz einer anderen Firma auf das Intranet zugreifen und der Anmeldedialog in diesem Netz gesperrt wird.
Naja, für problematisch halte ich noch ganz andere Sachen. Die Windows-Anmeldung für ein Extranet zu verwenden ist beispielsweise eine Schwachsinnsidee, weil diese in der Regel für Intranets benutzt wird. Welcher Idiot gibt dir seine eigenen Intranetanmeldedaten einer ganz anderen Firma, damit er auch bei dir ins Extranet kommen kann? Welcher Admin ist so blöd, diese Anmeldedaten überhaupt durch den Proxy durchzulassen? Welcher Browser läßt sich überhaupt dazu hinreißen, diese Daten freiwillig in die Welt hinauszusenden?
Vielleicht habe ich mich falsch oder unverständlich ausgedrückt. Oder Ich verstehe nicht was Du mir sagen möchtest.
Wir haben ein Intranet das, wie der Name schon sagt, eigentlich nur für das Intranet gedacht ist. Dahinter verbirgt sich Outlook Web Access etc. Weil es für die Mitarbeiter die z.B. von daheim aus arbeiten oder die meiste Zeit bei Kunden sind auch interessant ist die E-Mails zu lesen müssen sie auf Web Access zugreifen können. Sie melden sich also nicht mit fremden Anmeldedaten an, sondern mit ihren eigenen.
Zum Thema Browser wäre ich nicht so unvorsichtig. Mir ist schon klar dass Du auf den IE anspielst. Ich mag ihn ehrlich gesagt auch nicht. Aber Firefox ist ja zum Glück auch gerne bereit diese Aufgabe zu erledigen ...
Mal abgesehen davon, dass von SSL z.B. überhaupt noch keine Rede war - spielen Sicherheitsaspekte keine Rolle?
Natürlich spielen sie eine Rolle. Vielen Dank für den Hinweis auf SSL, aber das ist sowieso keine Frage.
Natürlich besteht die Möglichkeit, _eine_ Authentifizierung per Formular zu programmieren. Ein Ersatz für das unmögliche Einloggen per NTLM ist das aber nicht. NTLM ist eine Variation der HTTP-Authentifizierung - und auch die ist nicht formular-kompatibel.
Nicht ganz richtig. Mittlerweile habe ich http://support.microsoft.com/kb/306158/de#XSLTH3136121124120121120120 gefunden und kann mich über ein Formular mit einer Impersonation am Server anmelden. Das Problem hat sich allerdings nur gering verkleinert. Scheinbar ist die Impersonation per Code nur für das kurzfristige Ausführen von Code mit den Rechten einer bestimmten Person gedacht. Sobald die Seite verlassen wird ist die Berechtigung dahin.
Danke trotzdem für die Antwort. Vielleicht fällt Dir ja noch etwas ein wenn Du Dich wieder etwas beruhigt hast :)
Gruß,
small-step-
Moin!
Naja, für problematisch halte ich noch ganz andere Sachen. Die Windows-Anmeldung für ein Extranet zu verwenden ist beispielsweise eine Schwachsinnsidee, weil diese in der Regel für Intranets benutzt wird. Welcher Idiot gibt dir seine eigenen Intranetanmeldedaten einer ganz anderen Firma, damit er auch bei dir ins Extranet kommen kann? Welcher Admin ist so blöd, diese Anmeldedaten überhaupt durch den Proxy durchzulassen? Welcher Browser läßt sich überhaupt dazu hinreißen, diese Daten freiwillig in die Welt hinauszusenden?
Vielleicht habe ich mich falsch oder unverständlich ausgedrückt. Oder Ich verstehe nicht was Du mir sagen möchtest.Wir haben ein Intranet das, wie der Name schon sagt, eigentlich nur für das Intranet gedacht ist. Dahinter verbirgt sich Outlook Web Access etc. Weil es für die Mitarbeiter die z.B. von daheim aus arbeiten oder die meiste Zeit bei Kunden sind auch interessant ist die E-Mails zu lesen müssen sie auf Web Access zugreifen können. Sie melden sich also nicht mit fremden Anmeldedaten an, sondern mit ihren eigenen.
NTLM ist ja dafür gedacht, dass man in Intranetumgebungen Single-Sign-On realisieren kann. Einmal unter Windows angemeldet, und auch mit dem Browser kommt man ohne weitere Passwortabfrage überall rein und wird als der richtige Benutzer erkannt.
Das Problem, was ich sehe, ist nur: Das ist für Intranets gedacht. Wenn ein externer Mitarbeiter in _seinem_ Intranet seine Windows-Anmeldedaten eingibt, dann kann er die nicht gleichzeitig nutzen, um sich bei _deinem_ Intranet (bzw. eben Extranet) anzumelden.
Außerdem wäre es fatal, wenn ein NTLM-fähiger Browser jedem X-beliebigen Webserver Username und Passwort der Windowsanmeldung mitteilen würde, nur weil der Benutzer einen "böseren" Internet-Webserver besucht. Deswegen dürfte der IE NTLM-Anmeldung auf die Intranetzone beschränken - vermute ich mal.
Benutze einfach die klassische HTTP-Authentifizierung (z.B. als Fallback), die sollte funktionieren. Wer extern ist, muß sich dann eben einmal extra anmelden, wer lokal im Intranet arbeitet, braucht das nicht.
Alternativ kann der externe Mitarbeiter natürlich auch einen VPN-Tunnel in dein Intranet eröffnen und wird damit dann lokaler Benutzer. Dann wären auch etliche Sicherheitsfragen einfach gelöst.
Natürlich besteht die Möglichkeit, _eine_ Authentifizierung per Formular zu programmieren. Ein Ersatz für das unmögliche Einloggen per NTLM ist das aber nicht. NTLM ist eine Variation der HTTP-Authentifizierung - und auch die ist nicht formular-kompatibel.
Nicht ganz richtig. Mittlerweile habe ich http://support.microsoft.com/kb/306158/de#XSLTH3136121124120121120120 gefunden und kann mich über ein Formular mit einer Impersonation am Server anmelden. Das Problem hat sich allerdings nur gering verkleinert. Scheinbar ist die Impersonation per Code nur für das kurzfristige Ausführen von Code mit den Rechten einer bestimmten Person gedacht. Sobald die Seite verlassen wird ist die Berechtigung dahin.Naja, wenn du sowas wie einen Authentifizierungsproxy bastelst, also Formulardaten in Anmeldedaten umsetzt, hast du ja trotzdem das ganze Geraffel des Sessionhandlings zu leisten - und mußt zusätzlich noch das Adress-Rewriting realisieren, denn ich glaube kaum, dass die existierende Applikation sich von der Tatsache, dass die Anmeldedaten jetzt von einem Impersonation-Skript kommen, beeindrucken läßt. :)
Danke trotzdem für die Antwort. Vielleicht fällt Dir ja noch etwas ein wenn Du Dich wieder etwas beruhigt hast :)
Ich bin ganz ruhig - ich hab auch nichts GEGEN den IE gesagt, das mußt du mißverstanden haben.
- Sven Rautenberg
--
My sssignature, my preciousssss!-
Hallo Sven,
Das Problem, was ich sehe, ist nur: Das ist für Intranets gedacht. Wenn ein externer Mitarbeiter in _seinem_ Intranet seine Windows-Anmeldedaten eingibt, dann kann er die nicht gleichzeitig nutzen, um sich bei _deinem_ Intranet (bzw. eben Extranet) anzumelden.
Meines Wissens dürfte das gehen. Du kannst dich ja trotz Domain-Anmeldung z.B. als anderer Nutzer auf einer Freigabe eines anderen Rechners anmelden.
Benutze einfach die klassische HTTP-Authentifizierung (z.B. als Fallback), die sollte funktionieren. Wer extern ist, muß sich dann eben einmal extra anmelden, wer lokal im Intranet arbeitet, braucht das nicht.
Ich weiß nicht ob Outlook Web Access die HTTP-Authentifizierung annimmt. Ich hatte es mal mehr oder minder motiviert versucht und hab nach einem Misserfolg relativ schnell wieder aufgegeben. Müsste ich mir wohl mal genauer ansehen.
Alternativ kann der externe Mitarbeiter natürlich auch einen VPN-Tunnel in dein Intranet eröffnen und wird damit dann lokaler Benutzer. Dann wären auch etliche Sicherheitsfragen einfach gelöst.
Auch eine nette Idee. Ich weiß nur nicht, ob man das den Nutzern zutrauen kann. Muss ich nachher mal mit dem Admin klären.
Danke für die Antwort!
small-step
-
-
-