Wer nach der Installation einer 3-Tier LightSwitch App noch einen Admin hinzufügen möchte benötigt das Tool Microsoft.LightSwitch.SecurityAdmin.exe, jedenfalls sofern er nicht direkt in der DB fummeln möchte.
Doch wo findet man das Tool?
Auf einem frisch installierten Server der die “LightSwitch für Visual Studio 2012 – Serverkonfiguration ohne lokales SQL Express“ (das ist der offizielle sperrige Name) erhalten hat, konnte ich es nicht finden.
Erst eine Suche auf meiner lokalen Entwicklungsmaschine hatte Erfolg. Und zwar hier: C:\Program Files (x86)\Microsoft Visual Studio 10.0\LightSwitch\1.0\Tools
Es reicht aber nicht aus das exe-File zu kopieren. Am einfachsten den ganzen Tools Order zippen und auf die Zielmaschine kopieren um die Microsoft.LightSwitch.SecurityAdmin.exe nutzen zu können.
Aufgerufen wird Microsoft.LightSwitch.SecurityAdmin.exe mit diesen Parametern:
Administrative utility to perform security operations
for a LightSwitch application. /? Display this help text. /createadmin Creates an administrator user. Options: /user:<username> UserName of the user. /password:<password> Password of the user. Required for
Forms authentication mode. /fullname:<full name> Full name of the person represented by the user.
Required for Forms authentication. /config:<config path> Absolute path to the web.config file
of the LightSwitch application.
Wie ich später feststellte war die gefundene Microsoft.LightSwitch.SecurityAdmin.exe von Visual Studio 2010 (LightSwitch 2011) und funktioniert nicht mit VS 2012 LightSwitch Apps. In Visual Studio 2012 ist dieses Programm nach meinen Recherchen nicht mehr enthalten. Stattdessen wird es laut Doku nun mit der “LightSwitch für Visual Studio 2012 – Serverkonfiguration ohne lokales SQL Express“ auf dem Hosting Server installiert… leider nicht immer. In meinem Fall konnte ich jedenfalls keine AdminSecurity.exe auf dem Server finden. Neu installieren war leider auch nicht möglich (Details dazu hier).
Um nun endlich weiter zu kommen und das deployment abschliessen zu können, habe ich dann den Weg über die StoredProcedure gewählt. Glücklicherweise war in meiner DB bereits ein Admin enthalten. Mit der folgenden SP kann das Passwort in der DB nach eigenem gusto angepasst werden:
declare @cd datetime set @cd=getdate() exec [dbo].[aspnet_Membership_SetPassword]
‚appname‘,‚<domain>\<user>‘,‚<plainpassword>‘,’salt‘,@cd,0
Der letzte Parameter identifiziert das Passwort Format: (0=Plaintext, 1=Hashed, 2=Encrypted). Hier ist insbesondere die Möglichheit 0=Plaintext hilfreich.
Diese spannende Geschichte ;-) soll mir in erster Linie als Gedankenstütze dienen… mal schauen ob es hilft.