Pregunta

Me encuentro con un problema que tuve antes;No puedo encontrar mi referencia sobre cómo resolverlo.

Aquí está el problema.Ciframos la sección de cadenas de conexión en app.config para nuestra aplicación cliente usando el siguiente código:

        config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None)
        If config.ConnectionStrings.SectionInformation.IsProtected = False Then
            config.ConnectionStrings.SectionInformation.ProtectSection(Nothing)

            ' We must save the changes to the configuration file.'
            config.Save(ConfigurationSaveMode.Modified, True)
        End If

El problema es que un vendedor se fue.La computadora portátil vieja va a un nuevo vendedor y, bajo el inicio de sesión del nuevo usuario, cuando intenta hacerlo, aparece un error.El error es:

Unhandled Exception: System.Configuration.ConfigurationErrorsException: 
An error occurred executing the configuration section handler for connectionStrings. ---> System.Configuration.ConfigurationErrorsException: Failed to encrypt the section 'connectionStrings' using provider 'RsaProtectedConfigurationProvider'. 
Error message from the provider: Object already exists.
---> System.Security.Cryptography.CryptographicException: Object already exists
¿Fue útil?

Solución 2

Encontré una solución más elegante que en mi respuesta original.Descubrí que si simplemente inicié sesión como el usuario que instaló originalmente la aplicación y provocó que las cadenas de conexión del archivo de configuración se cifraran y fuera al directorio de .net framework en un símbolo del sistema y ejecutara

aspnet_regiis -pa "NetFrameworkConfigurationKey" "{domain}\{user}"

le dio permiso al otro usuario para acceder al contenedor de claves de cifrado RSA y luego funciona para los otros usuarios.

Solo quería agregarlo aquí porque pensé que había escrito este problema en nuestro blog de desarrollo pero lo encontré aquí, así que en caso de que necesite buscarlo nuevamente, estará aquí.También agregaremos un enlace a nuestro blog de desarrollo en este hilo.

Otros consejos

http://blogs.msdn.com/mosharaf/archive/2005/11/17/protectedConfiguration.aspx#1657603

copiar y pegar :D

lunes 12 de febrero de 2007 0:15 por Naica

re:Cifrar archivos de configuración usando configuración protegida

Aquí hay una lista de todos los pasos que he realizado para cifrar dos secciones en mi PC y luego implementarlas en el servidor web.Tal vez ayude a alguien...:

  1. Para crear un contenedor de claves RSA a nivel de máquina

    aspnet_regiis -pc "DataProtectionConfigurationProviderKeys" -exp
    
  2. Agregue esto a web.config antes de la sección ConnectionStrings:

     <add name="DataProtectionConfigurationProvider"
    
          type="System.Configuration.RsaProtectedConfigurationProvider, System.Configuration, Version=2.0.0.0,
    
                   Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a,
    
                   processorArchitecture=MSIL"
    
          keyContainerName="DataProtectionConfigurationProviderKeys"
    
          useMachineContainer="true" />
    

    No te pierdas el <clear /> ¡desde arriba!Importante al jugar con cifrar/descifrar muchas veces

  3. Verifique que esto esté en la parte superior del archivo Web.Config.Si falta agrégalo:

    <configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
    
  4. Guarde y cierre el archivo Web.Config en VS (¡muy importante!)

  5. En la ventana del símbolo del sistema (mi PC local), vaya a:

    C:\WINNT\Microsoft.NET\Framework\v2.0.50727

  6. Cifrar:(¡Tenga en cuenta que debe cambiar la ruta física de su aplicación o usar la opción -app y proporcionar el nombre del directorio virtual de la aplicación!Como usé VS en mi PC, preferí la siguiente opción.La ruta es la ruta al archivo Web.config)

    aspnet_regiis -pef "connectionStrings" "c:\Bla\Bla\Bla" -prov "DataProtectionConfigurationProvider"

    aspnet_regiis -pef "system.web/membership" "c:\Bla\Bla\Bla" -prov "DataProtectionConfigurationProvider"

  7. Para descifrar (¡solo si es necesario!):

    aspnet_regiis -pdf "connectionStrings" "c:\Bla\Bla\Bla"
    
    aspnet_regiis -pdf "system.web/membership" "c:\Bla\Bla\Bla"
    
  8. Eliminar contenedor de claves (¡solo si es necesario!)

    aspnet_regiis -pz "DataProtectionConfigurationProviderKeys"
    
  9. Guarde la clave anterior en un archivo xml para exportarla desde su PC local al servidor web (UAT o producción)

    aspnet_regiis -px "DataProtectionConfigurationProviderKeys" \temp\mykeyfile.xml -pri
    
  10. Importe el contenedor de claves en los servidores WebServer:

    aspnet_regiis -pi "DataProtectionConfigurationProviderKeys" \temp\mykeyfile.xml
    
  11. Conceder acceso a la clave en el servidor web.

    aspnet_regiis -pa "DataProtectionConfigurationProviderKeys" "DOMAIN\User"
    

    Ver en IIS el usuario ASP.NET o utilizar:

    Response.Write(System.Security.Principal.WindowsIdentity.GetCurrent().Name
    
  12. Eliminar Otorgar acceso a la clave en el servidor web (¡solo si es necesario!)

    aspnet_regiis -pr "DataProtectionConfigurationProviderKeys" "Domain\User"
    
  13. Copie y pegue en WebServer el archivo Web.config cifrado.

Así que lo hice funcionar.

  1. Se eliminó la cuenta de usuario anterior de la computadora portátil.
  2. restablecer app.config para tener la sección no protegida
  3. Se eliminó el archivo de claves de todas las claves de máquina de los usuarios.
  4. Ejecuté la aplicación y le permití proteger la sección.

Pero todo lo que esto hizo fue que funcionara para este usuario.

AHORA necesito saber qué tengo que hacer para cambiar el código para proteger la sección para que varios usuarios en una PC puedan usar la aplicación.¡Aquí vengo la PC virtual (mucho después de las vacaciones en WDW desde mañana hasta el próximo miércoles)!

algún consejo que me ayude a orientarme en la dirección correcta, ya que no tengo mucha experiencia en este tipo de cifrado RSA.

Suena como un problema de permisos.¿El (nuevo) usuario en cuestión tiene permisos de escritura en el archivo app.config?¿El usuario anterior era un administrador local o un usuario avanzado que podría haber enmascarado este problema?

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top