App-V Buch
Unser App-V
Buch

- App-V Infrastruktur
- App-V Client
- App-V Sequenzierung
- Tools & Troubelshooting
- PowerShell mit App-V

Image is not available
Services
Image is not available
Image is not available
Image is not available
Image is not available
Image is not available

Hochwertige Lösungen mit bestem Kundenservice

Terminalserver- und Desktop Umgebungen mit der besten Usability

Schulungen und Workshops

Intuitive individuelle Lösungen

Standartanwendungen
App-V SaS über 20 Standardanwendungen

Alle wichtigen Browser

Wichtige Standardanwendungen

Wöchentlich aktuallisiert

Mit Support

Individuelle Anpassungen sind möglich

Schnell auf Sicherheitslücken reagieren

Bonus: Einige MSIX Pakete für WVD

App-V Buch
Services
Innovative IT-Lösungen
previous arrow
next arrow
Schriftgröße: +
3 minutes reading time (507 words)

Autentifizierung: IIS Express Single Sign-On und Internet Explorer

Code a180x180Wenn eine Single Sign-On Anwendung für das Active Directory erstellt werden soll, fällt auf, dass trotz aller aktiven Attribute dennoch immer eine Anmeldemaske kommt. Eine Anmeldung ist nicht einmal erfolgreich und wenn diese erfolgreich ist, werden dennoch nicht die korrekten Gruppen angezeigt. Insbesondere in Verbindung mit lokalen Gruppen und ohne eine Domäne. Das fine ich aber gerade zum testen sehr schön. In diesem Blog beschreibe ich kurz die Fallstricke und alles was zu konfigurieren ist.

Ich wollte das Thema zunächst mit lokalen Accounts austesten (das muss auch funktionieren). Daher habe ich den entsprechenden Anweisungsblock in meine meine „Web.config“ Datei eingefügt. Dieser Block sollte die Authentifizierung ermöglichen:

 

  <system.web>
...
    <authentication mode="Windows" />
...
    <authorization>
      <deny users="?" />
    </authorization>
...
    <roleManager enabled="true" defaultProvider="AspNetWindowsTokenRoleProvider">
      <providers>
        <clear />
        <add name="AspNetWindowsTokenRoleProvider" type="System.Web.Security.WindowsTokenRoleProvider" applicationName="/" />
      </providers>
    </roleManager>
    
  </system.web>

 

Im Anschluß daran, ist die "Loakle" Gruppe für den Controller zu berechtigen. Das funktioniert auch mit der SID. Gerade wenn man "Vordefiniert" verwendet währe das auf einem englischen System wieder eine "BUILDIN" Gruppe. und die Anwendung würde in dieser Umgebung nicht funktionieren.

 

     [Authorize(Roles = "S-1-5-32-545")] //Users
        public ActionResult Index()
        {
oder auch
[Authorize(Roles = "test")] //Users public ActionResult Index() {

 

Im unteren Codeschnipsel ist schon eine lokale Testgruppe defineirt "test". Für diese würde jetzt im IE eine Anmeldemaske erscheinen und funktioneren wird nichts. Hingegen "Vordefiniert\\Benutzer oder die SID dazu S-1-5-32-545 führen zu einer Anmeldung. Irgendetwas fehlt. Vielleicht die IE Sicherheit? Zumindest im Intranet mit "Localhost" sollte das funktionieren - tut es auch. Aber das vorweg. Es kann Umgebungen geben, wo genau hier gedreht werden muss. Dann aber immer in Verbindung mit HTTPS - zu Ihrer Sicherheit. Beispielsweise für die "Trusted Sides".

IE-SicherheitSicherheitstufe

Die Stufe "Lokales Intranet" und "Automatisches Anmelden nur in der Intranetzone sind ok. Nur funktioniert es nicht! Nun baue ich etwas in den Code ein, um mir alle Gruppen zeigen zu lassen:

        [Authorize(Roles = "S-1-5-32-545")] //Users
        public ActionResult Index()
        {
            string[] roleNames = Roles.GetRolesForUser();
            var list = roleNames.ToList();
            String str = String.Join(", ", list.ToArray());
            ViewBag.str = str;
            return View();
        }

Das sind alle Gruppen in denen mein Konto lokal mitglied ist? Nur die Gruppe "test" fehlt, die ich eigentlich Authorisieren wollte.

NT-AUTORITÄT\Microsoft Konto-Authentifizierung,
LOKAL,
VORDEFINIERT\Benutzer,
NT-AUTORITÄT\Diese Organisation,
NT-AUTORITÄT\Authentifizierte Benutzer,
Jeder,
NT-AUTORITÄT\INTERAKTIV,
VORDEFINIERT\Leistungsprotokollbenutzer,
KONSOLENANMELDUNG,
NT-AUTORITÄT\Lokales Konto

Gefunden habe ich letztlcih den IIS Express als Ursache. Der macht per Default keine Windows Autentifizierung! Das ist ein bisschen komisch, da hier Gruppen angezeigt werden, aber eben nicht alle Gruppen. Das Gleiche dürfte ach in verbindung mit dem Active Directory passieren. Es ist letztlcih ganz leicht. Man öffne:

"...\Documents\IISExpress\config\applicationhost.config"

                <windowsAuthentication enabled="true">
                    <providers>
                        <add value="Negotiate" />
                        <add value="NTLM" />
                    </providers>
                </windowsAuthentication>

 Also "windowsAuthentication enabled" auf "true". Nun funktioniert auch alles in der ENtwicklungsumgebung. Für meine lokalen Gruppen erhalte ich nun die folgende Anzeige:

NT-AUTORITÄT\Microsoft Konto-Authentifizierung
NT-AUTORITÄT\Diese Organisation
LOKAL, VORDEFINIERT\Benutzer
test,
NT-AUTORITÄT\Authentifizierte Benutzer,
Jeder, NT-AUTORITÄT\INTERAKTIV,
VORDEFINIERT\Leistungsprotokollbenutzer,
KONSOLENANMELDUNG,
NT-AUTORITÄT\Lokales Konto

Die Gruppe "test" ist enthalten und auf diese kann auch nun ohne ein "Anmeldefenster" im IE autorisiert werden:

[Authorize(Roles = "test")]

Was sas System nicht mag, ist noch ein Computername vor dem Gruppennamen. Also [Authorize(Roles = "COMPUTER\\test")] hat bei mir nicht funktioneirt.

 

×
Stay Informed

When you subscribe to the blog, we will send you an e-mail when there are new updates on the site so you wouldn't miss them.

Firefox, App-V 5 und Single Sign-on Asp.net Anwend...
mit Powershell die Gruppen und die SIDs der Gruppe...
 

Kommentare

Derzeit gibt es keine Kommentare. Schreibe den ersten Kommentar!
Bereits registriert? Hier einloggen
Freitag, 19. April 2024

Sicherheitscode (Captcha)

Nick Informationstechnik GmbH
Dribusch 2
30539 Hannover

+49 (0) 511 165 810 190
+49 (0) 511 165 810 199

infonick-it.de

Newsletter

Anmeldung zum deutschen M.A.D. Newsletter mit Informationen zur Anwendungsvirtualisierung!

Wir nutzen Cookies auf unserer Website. Einige von ihnen sind essenziell für den Betrieb der Seite, während andere uns helfen, diese Website und die Nutzererfahrung zu verbessern (Tracking Cookies). Sie können selbst entscheiden, ob Sie die Cookies zulassen möchten. Bitte beachten Sie, dass bei einer Ablehnung womöglich nicht mehr alle Funktionalitäten der Seite zur Verfügung stehen.