Buch
- App-V Infrastruktur
- App-V Client
- App-V Sequenzierung
- Tools & Troubelshooting
- PowerShell mit App-V
Wenn 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".
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.
Kommentare