locked
ISA 2006 FBA mit PW-Change für Standalone-Webserver ohne Domäne RRS feed

  • Frage

  • Hi

    Frage, kann ich am ISA 2006 FBA für die Authentifizierung an einem Standalone Webserver (in der DMZ) mit lokalen Konten nutzen und den Benutzern gleichzeitig die Funktion zum Wechseln des lokalen Passworts anbieten?

    Ich hab das derzeit in eine Testumgebung so aufgebaut:

    ISA 2006 STD als Edge Firewall intern Member im AD, DMZ
    Webserver in der DMZ mit Windows 2008 R2 STD, IIS 7.5 und einer einzelnen Website, erlaubt sind von Extern ausschliesslich SSL-Verbindungen.
    Die Webseite besteht aus einem einzelnen html File und enthält lediglich eine URL als Link.

    Auf dem Webserver habe ich lokale Konten mit Passwörtern angelegt, welche sich auf den Webserver über HTTPS verbinden können (Funktioniert ohne FBA).
    Nun habe ich auf dem Listener als Authentifizierung FBA eingestell und als Authentifizierung (mangels Alternativen) Windows (Active Directory) gewählt.
    In der Webpublishing Regel habe ich unter Authentifizierungsdelegierung "Standardauthentifizierung" eingestellt. Zudem habe ich sichergestellt, dass ausschliesslich SSL-Traffic erlaubt ist.

    Der Zugriff funktioniert, das FBA-Formular erscheint und ich kann mich erfolgreich am Webserver anmelden.
    Wenn ich nun vor der Anmeldung die Option " <label for="chpwd">Ich möchte mein Kennwort nach der Anmeldung ändern</label> " aktiviere, gelange ich auch problemlos auf das enstprechende Formular und kann das bisherige und und das neue Passwort eingeben. Wenn ich dann aber auf "Kennwort ändern" klicken bekomme ich die folgende Fehlermeldung:

    "Die eingegebenen Anmeldeinformationen sind nicht gültig. Überprüfen Sie, ob das als altes Kennwort eingegebene Kennwort gültig ist, und wiederholen Sie den Vorgang."

    Natürlich ist das alte Passwort korrekt :-)

    Nun stellt sich mir die Frage, geht das grundsätzlich nicht mit einem Standalone Webserver oder habe ich irgendwas vegessen resp. falsch gemacht?

    Ziel des Ganzen ist, dass sich Kunden künftig via ISA am lokalen Webserver anmelden und von dort auf eine lokal installierte Software zugreifen können.

    Danke und Gruss
    Roger Hungerbühler

    Freitag, 29. Oktober 2010 18:51

Antworten

  • hi roger,

    die pw-change-option kommuniziert afaik mit ldaps mit deinem ad im hintergrund und gibt die passwort-änderung dort hin weiter. somit dürfte dein vorhaben leider nicht funken!

     


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    • Als Antwort vorgeschlagen Marc.Grote Samstag, 30. Oktober 2010 03:34
    • Als Antwort markiert Andrei Talmaciu Dienstag, 2. November 2010 11:37
    Freitag, 29. Oktober 2010 19:56
  • Hi,

    ich habe nie diese Anforderung gehabt, aber alles was ich bisher zu dem Thema gelesen habe ist das die Change Password Functionality nur gegen ein Active Directory laufen kann und nicht gegen eine lokale SAM! Ich denke auch, das ist fest coded in der Cookieauth.dll. Wenn ich mir den Inhalt der PWDCHANGE Forms im Editor angucke, kann man auch nur die aufgerufene DLL sehen!
    Hier steht auch nur AD/RADIUS/und/ADAM (AD-LDS).


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    • Als Antwort vorgeschlagen Marc.Grote Samstag, 30. Oktober 2010 03:34
    • Als Antwort markiert Andrei Talmaciu Dienstag, 2. November 2010 11:37
    Freitag, 29. Oktober 2010 20:07
  • Hi,

    leider nein, es wuerde mit RADIUS gehen, wenn der RADIUS Server gegen ein Active Directory laeuft, weil Du LDAPS brauchst. EIn Single Webserver hat aber nur die SAM und kein AD und somit auch kein LDAP, resoektive LDAPS


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    • Als Antwort vorgeschlagen Marc.Grote Samstag, 30. Oktober 2010 03:35
    • Als Antwort markiert Andrei Talmaciu Dienstag, 2. November 2010 11:37
    Samstag, 30. Oktober 2010 03:34

Alle Antworten

  • hi roger,

    die pw-change-option kommuniziert afaik mit ldaps mit deinem ad im hintergrund und gibt die passwort-änderung dort hin weiter. somit dürfte dein vorhaben leider nicht funken!

     


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    • Als Antwort vorgeschlagen Marc.Grote Samstag, 30. Oktober 2010 03:34
    • Als Antwort markiert Andrei Talmaciu Dienstag, 2. November 2010 11:37
    Freitag, 29. Oktober 2010 19:56
  • Hi,

    ich habe nie diese Anforderung gehabt, aber alles was ich bisher zu dem Thema gelesen habe ist das die Change Password Functionality nur gegen ein Active Directory laufen kann und nicht gegen eine lokale SAM! Ich denke auch, das ist fest coded in der Cookieauth.dll. Wenn ich mir den Inhalt der PWDCHANGE Forms im Editor angucke, kann man auch nur die aufgerufene DLL sehen!
    Hier steht auch nur AD/RADIUS/und/ADAM (AD-LDS).


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    • Als Antwort vorgeschlagen Marc.Grote Samstag, 30. Oktober 2010 03:34
    • Als Antwort markiert Andrei Talmaciu Dienstag, 2. November 2010 11:37
    Freitag, 29. Oktober 2010 20:07
  • Hallo Jens und Marc

    Danke für eure Antworten, das hatte ich mir schon fast gedacht, heisst das dann, wenn ich auf dem Webserver einen Radiusserver installiere, dann würde es funktionieren?

    Gruss
    Roger

    Samstag, 30. Oktober 2010 01:30
  • Hi,

    leider nein, es wuerde mit RADIUS gehen, wenn der RADIUS Server gegen ein Active Directory laeuft, weil Du LDAPS brauchst. EIn Single Webserver hat aber nur die SAM und kein AD und somit auch kein LDAP, resoektive LDAPS


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    • Als Antwort vorgeschlagen Marc.Grote Samstag, 30. Oktober 2010 03:35
    • Als Antwort markiert Andrei Talmaciu Dienstag, 2. November 2010 11:37
    Samstag, 30. Oktober 2010 03:34
  • moinsen,

    genau und der pw-change läuft über ldaps richtung ad. radius würde die authentifizierung richtung irgendeinen verzeichnisdienst relayen, aber nicht den pw-change!


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Samstag, 30. Oktober 2010 09:08
  • Hi

    Ist es dann evtl. möglich, dass ich die User Accounts im AD erfasse und pflege, den ISA mit FBA gegen das AD authentifizieren lasse und den Webserver trotzdem als Standalone in der DMZ stehen habe? Der ISA ist ja bereits AD-Mitglied.

    Die Anforderung ist, dass die Nutzer sich vor dem Zugriff auf die Website zwingend authentifizieren müssen, aber auf keinen Fall auf die Domänen Resourcen Zugriff erhalten dürfen. Die Nutzer müssen aber auch zwingen ihre regelmässig ablaufenden Kennwörtern selber auf einfachste Weise ändern können.

    Gruss
    Roger

     

    Samstag, 30. Oktober 2010 12:33
  • Hi,

    das verstehe ich jetzt nicht. Klar kannst Du den ISA gegen das AD authentifizieren lassen, aber wenn der Webserver Standalone in der DMZ ist hat er doch keinen AD Kontakt! Was soll das bringen?
    Du muesstest dann ja die lokalen USer auf dem Webserver mit dem AD syncen


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Samstag, 30. Oktober 2010 12:46
  • die user-acc pflege und änderung der passwörter ginge. dann stellt sich mir nur die frage was ist mit domänen-ressourcen gemeint - das user-acc. wäre ja schon eine ressource gelle?

    und dein webserver steht nicht als member in der domain, so könnten diese authentifizierten user auch dort nicht zugreifen, da sie ja auf dem host keine berechtigungen hätten.

    impersonation hilft dir hier auch nicht, weil sie ja ihre passes ändern können sollen.

    somit wäre ein weg: webserver in die domain inkl. berechtigungsvergabe für domainuser was die zugriffe auf denselben angeht, user-pflege über ad und pw-change mit fba auf tmg.


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Samstag, 30. Oktober 2010 12:48
  • Hi,

    ich muss zugeben, das mir die Anforderung noch nicht ganz klar ist. Du möchtest, das beim Zugriff auf die Webseite eine Athentifizierung erfolgt. Die erfolgreich authentifizierten Benutzer (wo werden die gepflegt ?) gehören aber nicht zu deinem AD und dürfen auch dort nicht zugreifen.

    Wenn du eine lokale SAM Datenbank mit Benutzern füllst, was spricht dagegen einen Domänencontroller mit einer eigenen Domäne in die DMZ zu stellen ? Wenn du dann dort die Benutzer anlegst, funktionieren alle Standardfunktionen wieder.

    Viele Grüße
    Carsten

    Samstag, 30. Oktober 2010 19:05
  • Hi

    Ich hab da wohl für etwas Verwirrung gesorgt, die Idee mit dem AD kam nur deshalb auf, weil der ISA bereits Domänen-Mitglied ist.
    Es ist aber nicht gewünscht, dass die User des Webservers auf Ressourcen im AD Zugriff erhalten. Natürlich ist mir klar, dass eine AD-Authentifizierung dem wiederspricht, es hätte in diesem Fall dafür gesorgt werden müssen, dass neben der Authentifizierung kein Weiterer Zugriff auf die restliche resourcen möglich ist.

    Nochmal zum Setup:

    Der Webserver (Windows 2008 R2) steht als eigenständiger IIS 7.5 Server in der DMZ (ohne AD).
    Auf dem Wesberver läuft eine WEB-Applikation (inkl. SQL-Server), welche den Benutzern Zugriff auf Ihre Daten ermöglicht.
    Die Benutzer-Accounts werden auf dem Webserver in Form von lokalen Windows-Accounts gepflegt.

    Verlangt wird, dass sich alle Benutzer zwingend am Webserver authentifizieren müssen, bevor Sie Zugriff auf die Applikation erhalten.
    Die dafür verwendeten Passwörter müssen u.A. regelmässig ablaufen, wobei der Benutzer zwingend das abgelaufene Passwort selber ändern müssen kann.

    Und genau hier liegt das Problem, ab IIS 7 ist IISADMPWD nicht mehr enthalten und auch nicht mehr supportet.
    Deshalb suchen wir nach einer Alternative.

    Ein zusätzlicher DC für eine eigene Domain in der DMZ kommt aus Kostengründen (zus. Hardware und Lizenzen) derzeit nicht in Frage.

    Gruss
    Roger

    Montag, 1. November 2010 10:31
  • moin roger,

    fühle mich nicht mehr verwirrt als wie sonst auch.

    ;-)

    zu deinem setup: wenn die pre-authentication inkl. pw-change von isa/tmg eine alternative sein soll, dann muss der webserver mitglied der domain sein, gegen welche authentifiziert wird (siehe postings von uns weiter oben).

    eine andere möglichkeit sehe ich mit isa/tmg-boardmitteln zumindest nicht.


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Montag, 1. November 2010 10:35
  • Hi Jens

    Das habe ich auch so verstanden :-)
    Ich werde mich mal bei den IIS-Spezialisten umschauen, ob da einer was bauen kann.

    Gruss
    Roger

    Montag, 1. November 2010 14:37
  • Hi,

    wegen des IISADMPWD gibt es aber einenWuerkaround:
    http://www.eggheadcafe.com/software/aspnet/35218548/iis7-and-iisadmpwd.aspx

     


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Montag, 1. November 2010 16:10
  • Hi

    Die Anleitung für IISADMPWD unter IIS 7 kenne ich schon, leider komm ich damit aber nicht weiter, in Ermangelung eines Exchangeservers, steht der AppPool "MSExchangeOWAAppPool" auch nicht zur Verfügung.

    Alle anderen hab ich durchprobiert, es funktioniert aber nichts davon. In einer anderen Anleitung stand, man müsse die DLL im Verzeichnis IISADMPWD regsitrieren, das scheitert aber daran, dass sich diese unter Windows 2008 R2 nicht regsitrieren lässt.

    Ausserdem hat IISADMPWD einen enstcheidenden nachteil, der Passwortwechsel klappt offenbar nur, wenn das alte PW noch nicht abgelaufen ist.

    Gruss
    Roger

    Mittwoch, 3. November 2010 11:48