4
IIS Windows-Authentifizierung
Hallo zusammen
ich habe irgendwie ein "Verständnisproblem". Ich hoffe ihr könnt mir das Verhalten erklären....
Ich will jetzt euch zu Beginn noch gar nicht groß mit Informationen/Einstellungen zumüllen, da es vielleicht ein ganz simples logisches Problem und/oder Denkfehler ist ist. Falls ihr doch mehr Konfigurationseinstellungen wissen müsst, einfach Bescheid geben.
Doch ganz grob:
- Es gibt einen DC-Server innerhalb der Firma (allerdings noch leider mit einer .local Domänenform. Nennen wir ihn mal abc.local)
- Die Website wird extern gehostet unter der Domain domain.de)
- Für den externen Zugriff vom Internet habe ich auf dem DC eine neue Zone srv.domain.de angelegt, so dass Zugriffe auf Service für außerhalb und innerhalb der Firma transparent sind und beide male srv.domain.de verwendet werden kann (auf dem Hoster wurde srv ebenfalls in den DNS eingetragen. Klappt auch alles soweit)
- Auf dem DC ist auch die Zertifizierungsrolle installiert mit Web-Interface. Diese ist jetzt zwar nicht relevant, aber damit kann es jeder wahrscheinlich einfach nachvollziehen)
Wenn ich nun intern (auf dem DC selbst) https://abc.local/certsrv aufrufe, wird sofort die Website angezeigt (da die Authentifizierung erfolgreich (sein muss) wird auch kein Login-Dialog angezeigt)
Wenn ich jedoch intern (ebenfalls direkt auf dem DC) https://srv.domain.de/certsrv verwende, kommt jedoch ein Anmeldedialog. Auch wenn ich dort die richtigen Credentials eintrage, kommt der Dialog sofort wieder. IIS kann aus irgendeinem Grunde die Anmeldedaten nicht überprüfen.
nslookup abc.local + nslookup srv.domain.de verweisen definitiv beide male auf den DC. Eine Adressauflösungsproblem kann es also nicht sein.
Ich vermute eher, dass mit srv.domain.de IIS nicht die Domain erkennt und die Credentials dagegen prüft. Das ist wahrscheinlich ein gutes Beispiel wieso der Domänenname gleich sein sollte, um gerade solche Probleme zu vermeiden.
Ist das ein unlösbares Problem oder habe ich nur noch etwas vergessen einzustellen?
VG
Michael
ich habe irgendwie ein "Verständnisproblem". Ich hoffe ihr könnt mir das Verhalten erklären....
Ich will jetzt euch zu Beginn noch gar nicht groß mit Informationen/Einstellungen zumüllen, da es vielleicht ein ganz simples logisches Problem und/oder Denkfehler ist ist. Falls ihr doch mehr Konfigurationseinstellungen wissen müsst, einfach Bescheid geben.
Doch ganz grob:
- Es gibt einen DC-Server innerhalb der Firma (allerdings noch leider mit einer .local Domänenform. Nennen wir ihn mal abc.local)
- Die Website wird extern gehostet unter der Domain domain.de)
- Für den externen Zugriff vom Internet habe ich auf dem DC eine neue Zone srv.domain.de angelegt, so dass Zugriffe auf Service für außerhalb und innerhalb der Firma transparent sind und beide male srv.domain.de verwendet werden kann (auf dem Hoster wurde srv ebenfalls in den DNS eingetragen. Klappt auch alles soweit)
- Auf dem DC ist auch die Zertifizierungsrolle installiert mit Web-Interface. Diese ist jetzt zwar nicht relevant, aber damit kann es jeder wahrscheinlich einfach nachvollziehen)
Wenn ich nun intern (auf dem DC selbst) https://abc.local/certsrv aufrufe, wird sofort die Website angezeigt (da die Authentifizierung erfolgreich (sein muss) wird auch kein Login-Dialog angezeigt)
Wenn ich jedoch intern (ebenfalls direkt auf dem DC) https://srv.domain.de/certsrv verwende, kommt jedoch ein Anmeldedialog. Auch wenn ich dort die richtigen Credentials eintrage, kommt der Dialog sofort wieder. IIS kann aus irgendeinem Grunde die Anmeldedaten nicht überprüfen.
nslookup abc.local + nslookup srv.domain.de verweisen definitiv beide male auf den DC. Eine Adressauflösungsproblem kann es also nicht sein.
Ich vermute eher, dass mit srv.domain.de IIS nicht die Domain erkennt und die Credentials dagegen prüft. Das ist wahrscheinlich ein gutes Beispiel wieso der Domänenname gleich sein sollte, um gerade solche Probleme zu vermeiden.
Ist das ein unlösbares Problem oder habe ich nur noch etwas vergessen einzustellen?
VG
Michael
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: 527879
Url: https://administrator.de/contentid/527879
Printed on: April 19, 2024 at 00:04 o'clock
4 Comments
Latest comment
Hi,
Du hast auf dem DC auch eine CA laufen?
Und der Record srv.domain.de verweist auf den DC/CA?
Der Zugriff auf die Website der CA erfolgt über HTTPS?
Meckert er denn nicht ein falsches Zertifikat an, wenn Du dann über srv.domain.de gehst?
Und falls ja, könnte das u.U. das Problem sein?
Und falls er nicht wegen des Zertifkats meckert, dann hast Du also ein neues Zertikat erstellt mit zusätzlich dem srv.domain.de und darüber die Bindung am IIS konfiguriert?
Deine Infos sind da etwas schwammig.
E.
Du hast auf dem DC auch eine CA laufen?
Und der Record srv.domain.de verweist auf den DC/CA?
Der Zugriff auf die Website der CA erfolgt über HTTPS?
Meckert er denn nicht ein falsches Zertifikat an, wenn Du dann über srv.domain.de gehst?
Und falls ja, könnte das u.U. das Problem sein?
Und falls er nicht wegen des Zertifkats meckert, dann hast Du also ein neues Zertikat erstellt mit zusätzlich dem srv.domain.de und darüber die Bindung am IIS konfiguriert?
Deine Infos sind da etwas schwammig.
E.
Richtig. Das Zertifikat ist auf srv.domain.de ausgestellt und findet er auch - von intern wie auch extern
(wenn man den Credential-Dialog abbricht, kommt ja eine 401.2 Fehlermeldung. Aber das Zertifikat/Verbindung wird als gültig angezeigt und ist auch das srv.domain.de Zertifikat)
Wenn ich über https://abc.local/certsrv die Website aufrufe wird natürlich das Zertifikat als ungültig angezeigt weil natürlich der Common Name falsch ist. Die Site wird aber trotzdem korrekt angezeigt (und im Hintergrund korrekt authentifiziert)
Wie versucht denn IIS einen Benutzer technisch zu authentifizieren?? Das würde mich mal gerne interessieren...
(wenn man den Credential-Dialog abbricht, kommt ja eine 401.2 Fehlermeldung. Aber das Zertifikat/Verbindung wird als gültig angezeigt und ist auch das srv.domain.de Zertifikat)
Wenn ich über https://abc.local/certsrv die Website aufrufe wird natürlich das Zertifikat als ungültig angezeigt weil natürlich der Common Name falsch ist. Die Site wird aber trotzdem korrekt angezeigt (und im Hintergrund korrekt authentifiziert)
Wie versucht denn IIS einen Benutzer technisch zu authentifizieren?? Das würde mich mal gerne interessieren...
Moin,
Klar. Sonst wäre ja auch der IIS falsch konfiguriert. Das Zertifikat dient aber nicht dazu, den User zu identifizieren, sondern lediglich dazu, eine gesicherte Verbindung aufzubauen.
Da ist zwar das Zertifikat falsch. Wen Du es aber akzeptierst und der Vorgang weiter geht, dann wird festgestellt, dass Du Dich in derselben Domain wie der Server befindest. Du hast single login konfiguriert. Also schiebt Windows die Credentials rüber und alles ist gut.
Na anhand des Domain Names. Und das dürfte das Problem sein. Wenn Du über srv.domain.de kommst, dann bist Du nicht in der Domain abc.local. Deshalb werden auch die Credentials nicht einfach übergeben. Das ist auch gut so. Stell Dir mal vor, wie einfach das wäre, Credentials zu stehlen, wenn die auf jede x-beliebige Site übertragen werden. Also fragt der Server nach Benutzername und Passwort. Nun gibst Du, vermute ich, den Benutzernamen ohne Domain an. Dann guckt der IIS nach, ob es den Benutzer benutzername@domain.de gibt und stellt fest, dass dem nicht so ist. Nochmal bitte. Hast Du es schon einmal mit benutzername@abc.local versucht?
BTW: Dass beide Einträge auf dieselbe IP zeigen und deshalb nslookup das gleiche Ergebnis liefert, heißt nur, dass es sich auf OSI 3 um denselben Netzwerkadapter handelt. Die Authentifizierung findet aber auf OSI 5-7 statt und da sind abc.local und domain zwei vollkommen unterschiedliche Dinge.
hth
Erik
Zitat von @Michl16:
Richtig. Das Zertifikat ist auf srv.domain.de ausgestellt und findet er auch - von intern wie auch extern
(wenn man den Credential-Dialog abbricht, kommt ja eine 401.2 Fehlermeldung. Aber das Zertifikat/Verbindung wird als gültig angezeigt und ist auch das srv.domain.de Zertifikat)
Richtig. Das Zertifikat ist auf srv.domain.de ausgestellt und findet er auch - von intern wie auch extern
(wenn man den Credential-Dialog abbricht, kommt ja eine 401.2 Fehlermeldung. Aber das Zertifikat/Verbindung wird als gültig angezeigt und ist auch das srv.domain.de Zertifikat)
Klar. Sonst wäre ja auch der IIS falsch konfiguriert. Das Zertifikat dient aber nicht dazu, den User zu identifizieren, sondern lediglich dazu, eine gesicherte Verbindung aufzubauen.
Wenn ich über https://abc.local/certsrv die Website aufrufe wird natürlich das Zertifikat als ungültig angezeigt weil natürlich der Common Name falsch ist. Die Site wird aber trotzdem korrekt angezeigt (und im Hintergrund korrekt authentifiziert)
Da ist zwar das Zertifikat falsch. Wen Du es aber akzeptierst und der Vorgang weiter geht, dann wird festgestellt, dass Du Dich in derselben Domain wie der Server befindest. Du hast single login konfiguriert. Also schiebt Windows die Credentials rüber und alles ist gut.
Wie versucht denn IIS einen Benutzer technisch zu authentifizieren?? Das würde mich mal gerne interessieren...
Na anhand des Domain Names. Und das dürfte das Problem sein. Wenn Du über srv.domain.de kommst, dann bist Du nicht in der Domain abc.local. Deshalb werden auch die Credentials nicht einfach übergeben. Das ist auch gut so. Stell Dir mal vor, wie einfach das wäre, Credentials zu stehlen, wenn die auf jede x-beliebige Site übertragen werden. Also fragt der Server nach Benutzername und Passwort. Nun gibst Du, vermute ich, den Benutzernamen ohne Domain an. Dann guckt der IIS nach, ob es den Benutzer benutzername@domain.de gibt und stellt fest, dass dem nicht so ist. Nochmal bitte. Hast Du es schon einmal mit benutzername@abc.local versucht?
BTW: Dass beide Einträge auf dieselbe IP zeigen und deshalb nslookup das gleiche Ergebnis liefert, heißt nur, dass es sich auf OSI 3 um denselben Netzwerkadapter handelt. Die Authentifizierung findet aber auf OSI 5-7 statt und da sind abc.local und domain zwei vollkommen unterschiedliche Dinge.
hth
Erik
Zitat von @erikro:
Klar. Sonst wäre ja auch der IIS falsch konfiguriert. Das Zertifikat dient aber nicht dazu, den User zu identifizieren, sondern lediglich dazu, eine gesicherte Verbindung aufzubauen.
Klar. Sonst wäre ja auch der IIS falsch konfiguriert. Das Zertifikat dient aber nicht dazu, den User zu identifizieren, sondern lediglich dazu, eine gesicherte Verbindung aufzubauen.
Richtig. Hätte nur sein können, dass eine korrekte Validierung auf einer sicheren Verbindung akzeptiert wird. Aber das konnte ich ja bereits selbst widerlegen und wollte es nur nochmals erwähnen.
Zitat von @erikro:
Nun gibst Du, vermute ich, den Benutzernamen ohne Domain an. Dann guckt der IIS nach, ob es den Benutzer benutzername@domain.de gibt und stellt fest, dass dem nicht so ist. Nochmal bitte. Hast Du es schon einmal mit benutzername@abc.local versucht?
Nun gibst Du, vermute ich, den Benutzernamen ohne Domain an. Dann guckt der IIS nach, ob es den Benutzer benutzername@domain.de gibt und stellt fest, dass dem nicht so ist. Nochmal bitte. Hast Du es schon einmal mit benutzername@abc.local versucht?
Das hatte ich auch vermutet und hätte gedacht, dass eine explizite Angabe der Domain (also in abc\ oder user@abc.local) spätestens klappen sollte. Tut es aber leider nicht. Das verwundert mich auch...
