2
IIS und seine verzwickten authentifizierungsmethoden - standartauthentifizierung
standardauthentifizierung vs. integrierte windowsauthentifizierung
hallo zusammen,
folgendes problem auf einem w2k dc:
man kann ein verzeichniss ja sehr schön über webfreigabe zum iis hinzufügen.
ist dies erfolgt (inklusive der ntfs acl´s blablabla), muss im iis nur noch die entsprechende authentifizierungsart eingestellt werden.
4 möglichkeiten:
anonym | standardauthentifizierung | digest auth... | integrierte windows auth...
wenn ich jetzt nur anonym einstelle, wird das verzeichniss nach aufrufen im ie6 geblockt weil die ntfs berechtigungen das anzeigen der dateien für "jeder" verwehrt...eine benutzerabfrage erfolgt nicht...gut gemacht iis.
wenn ich jetzt standardauthentifizierung zusätzlich anklicke, den ie6 dann wieder anwerfe, will der browser nun eine authetifizierung mittels benutzername und passwort...geb ich diese daten (anhand der vergebenen ntfs berechtigung auf das freigegebene verzeichniss) nun im ie ein, hab ich natürlich zugriff auf die gewünschten dateien....gut gemacht iis.
die beiden anderen authentifizierungen kommen nicht in frage (ist so gewollt und muss so bleiben)
das ganze funktioniert schnell und reibungslos übers INTERNET als domänenfremder benutzer
wenn man nun aber in der firma ist und das ganze wie ein intranet betreiben will (aber immer noch mit ner url nach draussen)
dann meldet man sich natürlich an der domäne an...öffnet den ie...browst zum freigegebenen o.g. verzeichniss...und nix geht, weil der iis den user plötzlich nicht kennt. obwohl der ja selbst grad angemeldet ist und somit netzwerkzugriff erteilt wurde.
mann muss dann im iis die integrierte windowsauthentifizierung mit zu hilfe nehmen ... erst dann (und mit zäher wartezeit verbunden) wird die resource freigegeben und kann angezeigt werden.
warum kennt die standartauthentifizierung keinen user innerhelb der domäne aber sehr wohl ausserhalb der domäne.
ist doch paradox ????
bitte helfen, ich kann nicht mehr.
folgendes problem auf einem w2k dc:
man kann ein verzeichniss ja sehr schön über webfreigabe zum iis hinzufügen.
ist dies erfolgt (inklusive der ntfs acl´s blablabla), muss im iis nur noch die entsprechende authentifizierungsart eingestellt werden.
4 möglichkeiten:
anonym | standardauthentifizierung | digest auth... | integrierte windows auth...
wenn ich jetzt nur anonym einstelle, wird das verzeichniss nach aufrufen im ie6 geblockt weil die ntfs berechtigungen das anzeigen der dateien für "jeder" verwehrt...eine benutzerabfrage erfolgt nicht...gut gemacht iis.
wenn ich jetzt standardauthentifizierung zusätzlich anklicke, den ie6 dann wieder anwerfe, will der browser nun eine authetifizierung mittels benutzername und passwort...geb ich diese daten (anhand der vergebenen ntfs berechtigung auf das freigegebene verzeichniss) nun im ie ein, hab ich natürlich zugriff auf die gewünschten dateien....gut gemacht iis.
die beiden anderen authentifizierungen kommen nicht in frage (ist so gewollt und muss so bleiben)
das ganze funktioniert schnell und reibungslos übers INTERNET als domänenfremder benutzer
wenn man nun aber in der firma ist und das ganze wie ein intranet betreiben will (aber immer noch mit ner url nach draussen)
dann meldet man sich natürlich an der domäne an...öffnet den ie...browst zum freigegebenen o.g. verzeichniss...und nix geht, weil der iis den user plötzlich nicht kennt. obwohl der ja selbst grad angemeldet ist und somit netzwerkzugriff erteilt wurde.
mann muss dann im iis die integrierte windowsauthentifizierung mit zu hilfe nehmen ... erst dann (und mit zäher wartezeit verbunden) wird die resource freigegeben und kann angezeigt werden.
warum kennt die standartauthentifizierung keinen user innerhelb der domäne aber sehr wohl ausserhalb der domäne.
ist doch paradox ????
bitte helfen, ich kann nicht mehr.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 13589
Url: https://administrator.de/contentid/13589
Printed on: April 20, 2024 at 02:04 o'clock
2 Comments
Latest comment
Meiner Auffassung nach ist alles bei Ihnen richtig eingestellt.
Bis auf die NTFS Berechtigungen.
Die müssen auf Jeder -> Lesen etc. (Je nach dem..) eingestellt
werden. Dann müßte es funktionieren.
Bei mir funktionierte der cgi/php Zähler über Dyn-DNS z.B. nicht.
Das muhatte ich vergessen genau dieses Vertzeichnis zusätzlich
für alle zum Schreiben freizugeben.
Aber so richtig in die Tiefe dieser Materie konnte ich bisher
auch nicht vordringen.
mit freundlichen Grüßen
Dr. Axel Bangert
Bis auf die NTFS Berechtigungen.
Die müssen auf Jeder -> Lesen etc. (Je nach dem..) eingestellt
werden. Dann müßte es funktionieren.
Bei mir funktionierte der cgi/php Zähler über Dyn-DNS z.B. nicht.
Das muhatte ich vergessen genau dieses Vertzeichnis zusätzlich
für alle zum Schreiben freizugeben.
Aber so richtig in die Tiefe dieser Materie konnte ich bisher
auch nicht vordringen.
mit freundlichen Grüßen
Dr. Axel Bangert
Jetzt muss ich doch nocheinmal antworten. Unter dem IIS 6 mit php Erweiterungsmodul, passiert, anders als bei asp.net, folgendes.
Wenn man ein virtuelles Verzeichnis mit allen Rechten erstellt und für anonymen Zugriff freigiebt, dann erteilt der Sicherheitsmanager keine Schreibrechte für php bei Zugriff aus dem Internet.
Wenn man zusätzlich Freigabe und Webfreigabe mit allen Rechten erteilt und genau der Datei, in die geschrieben wird , nur Windowsauthentifizierung erteilt.
Kann bei Internetzugriff sporadisch in diese Datei geschreiben werden.
Allerdings völlig instabil.
Die stabile Lösung zur Erteilung von php Schreibrechten ohne Schreibrechte zu vergeben,
ist die, den Webordner ohne Erstellung eines virtuellen Verzeichnisses in einen darüberliegenden Ordner zu verpacken der garkeine Freigabe besitzt.
Dann muss man dem so verpackten Webordner selbst die Servererweiterungen hinzufügen und ihm nur eine einfache Freigabe erteilen ohne jede Schreib oder Ausführungsrechte.
Nur dann kann ich bei mir sowohl lokal als auch remote über php Schreiben.
Mir ist dieses Verghalten völlig unerklärlich ich kann mir nur vorstellen, dass die PHPISAPI.dll unter dem IIS 6 irgendwelche besonderen Sicherheitsbugs hat, die womöglich sogar sehr gefährlich sein könnten.
Kann mir da jemand etwas Genaueres dazu mitteilen?
mit freundlichen Grüßen
Dr. Axel Bangert
Wenn man ein virtuelles Verzeichnis mit allen Rechten erstellt und für anonymen Zugriff freigiebt, dann erteilt der Sicherheitsmanager keine Schreibrechte für php bei Zugriff aus dem Internet.
Wenn man zusätzlich Freigabe und Webfreigabe mit allen Rechten erteilt und genau der Datei, in die geschrieben wird , nur Windowsauthentifizierung erteilt.
Kann bei Internetzugriff sporadisch in diese Datei geschreiben werden.
Allerdings völlig instabil.
Die stabile Lösung zur Erteilung von php Schreibrechten ohne Schreibrechte zu vergeben,
ist die, den Webordner ohne Erstellung eines virtuellen Verzeichnisses in einen darüberliegenden Ordner zu verpacken der garkeine Freigabe besitzt.
Dann muss man dem so verpackten Webordner selbst die Servererweiterungen hinzufügen und ihm nur eine einfache Freigabe erteilen ohne jede Schreib oder Ausführungsrechte.
Nur dann kann ich bei mir sowohl lokal als auch remote über php Schreiben.
Mir ist dieses Verghalten völlig unerklärlich ich kann mir nur vorstellen, dass die PHPISAPI.dll unter dem IIS 6 irgendwelche besonderen Sicherheitsbugs hat, die womöglich sogar sehr gefährlich sein könnten.
Kann mir da jemand etwas Genaueres dazu mitteilen?
mit freundlichen Grüßen
Dr. Axel Bangert
