What is the best practice when making connection strings when using Thycotic secret server? - web-config

I would like clarification on the secure use of connection strings within web.config files when using Thycotic Secret Server.
Fortify has flagged the web.config files as being insecure due to an “Insecure Transport: Database” issue. The common fault identified here is that the attribute “Encrypt=” is not set in the connection string. E.g.
Bad setting:
<add name="LOG.ConnectionString" connectionString="Data Source={SECRET:AA.SERVER}:{SECRET:AA.PORT}/BB.WEBSITE.COM;User ID={SECRET:AA.USER};Password={SECRET:AA.PASSWORD};pooling=true;Max Pool Size=55" providerName="Oracle.DataAccess.Client"/>
Recommended setting is:
<add name="LOG.ConnectionString" connectionString="Data Source={SECRET:AA.SERVER}:{SECRET:AA.PORT}/BB.WEBSITE.COM;User ID={SECRET:AA.USER};Password={SECRET:AA.PASSWORD};Encrypt=yes;pooling=true;Max Pool Size=55" providerName="Oracle.DataAccess.Client"/>
Also the servers are configured with SSL/TLS settings.
Connection fails when “Encrypt=yes” is set in the connection string when Thycotic is in use.
I have a few questions around this.
When using Thycotic, is it recommended to set the encrypt attribute or can it be ignored and still be considered secure?
If the encrypt attribute should be set, do you have any ideas why it would be failing?
Any assistance would be greatly appreciated.

Related

Azure WebJob no longer picking up Entity Framework connection string setting in portal

I've had an Azure WebJob running for at least two years without any problems. The app.config contains the following...
<connectionStrings>
<add name="UniversalModelEntities" connectionString="dummy - the actual connection string is specified in the portal but for some reason we need this element here" providerName="System.Data.EntityClient" />
</connectionStrings>
And in the portal's Application Settings I have...
This has run without any problems... until this morning when I found the error
The connection string 'UniversalModelEntities' in the application's configuration file does not contain the required providerName attribute."
Everything I've found regarding Entity Framework connection strings in the Azure portal says that I should set that drop-down to Custom.
So what's the problem?
Furthermore, I've found that even if declare the full connection string in the app.config, I still get the same error message, which suggests that the problem lies in the portal's setting.
I managed to solve this problem by setting the drop-down option for the connection string to SQLAzure...
...which obviously results in an error, then changing it back to Custom...
Now the WebJob picks up the connection string correctly.

SQL Azure EF Database First Connection String in Azure Management Portal

I have a site running n Azure, which uses EF Database First model.
If I embed the connection string in the web.config and deploy all is rosy.
<add name="MyEntities" connectionString="metadata=res://*/App_Code.Model.csdl|res://*/App_Code.Model.ssdl|res://*/App_Code.Model.msl;provider=System.Data.SqlClient;provider connection string='Data Source=my.database.windows.net;Initial Catalog=myTest_DB;User ID=***;Password=***; MultipleActiveResultSets=False'" providerName="System.Data.EntityClient"/>
But, I don't want the connection string in the web.config because it contains credentials.
So I moved it to the connection string area in Azure Properties.
First issue I hit is getting metadata invalid keyword error.
I solved that by changing the type from SQL Database to Custom.
However, I now get this error:
The connection string 'MyEntities' in the application's configuration
file does not contain the required providerName attribute."
I've trawled the web and tried many variations of the connection string but not yet found the correct one.
Note: I guess I could make this an app setting and move the initialisation of the string to code, but even if only for curiosity sake I would like to know how to do it via the portal.
The problem is not the connection string, but the inability to specify the providerName from the portal.
Try publishing with a local or dummy connection string in place, and overwriting it as you have in the Azure Application Settings. See this answer: https://stackoverflow.com/a/18964294/94853

Failing to get EF connection string to work when setup in Azure's management portal?

I am using ASP.NET MVC4 deployed on WebApps, EF6, Azure SQL Database
I have two connectionstrings, one direct to the DB and one that is needed as I am using Entity Framework. If I setup the first via Azure and leave the EF string in web.config, all works fine. Once I try to move the EF connectionstring to Azure, it breaks.
I have tried to follow all the posts on how to setup an EF connection string in Azure Management Portal, and the advice seems to be to use the following:
In Management Portal:
Name:
EFConnectionString
Value:
metadata=res://MyModel/model.csdl|res://MyModel/model.ssdl|res://MyModel/model.msl;provider=System.Data.SqlClient;provider connection string="Data Source=tcp:myserver.database.windows.net,1234;Initial Catalog=mydatabase;User ID=Admin#myserver.database.windows.net;Password=12345678"
SQL Database:
Custom
Note:
" is replaced by " in the Azure string.
In Web.config I still need the following:
<add name="EFConnectionString" connectionString="" providerName="System.Data.EntityClient"/>
I have changed certain details in the connectionstring for security reasons, but the true string does work fine in Web.config.
However when I do attempt the above, I get :
The page cannot be displayed because an internal server error has occurred.
Further Log error message:
The specified named connection is either not found in the configuration, not intended to be used with the EntityClient provider, or not valid.
Any help appreciated. I am trying to do this to enhance the security of stored passwords for accessing DB on Azures, as I understand that setting them up via the portal encrypts them.
Thanks.
First check your deployment. I've run in a similar problem, and after a couple of hours struggling I found out that I was deploying without actually sending connection strings, falling back to whatever was in the portal config... the others keys in the we.config were being sent over, but the conn strings weren't... after I properly set it up on the portal, everything went back to normal...

The connection string in the application's configuration file does not contain the required providerName attribute

I have a WorkerRole in Azure that's connecting to an MSSQL database (also in Azure, on its own virtual machine -- in other words not an Azure SQL database). The WorkerRole is using EntityFramework (code first).
My connection string looks like this and connections from the worker role works just fine in my development environment:
<add name="MyConnectionString" connectionString="Data Source=mydatabaseserver.cloudapp.net;Initial Catalog=MyDatabase;User ID=MyUser;Password=ThePassword;" providerName="System.Data.SqlClient" />
However, the application throws the error:
The connection string MyConnectionString in the application's configuration file does not contain the required providerName attribute
As you can see, it clearly does contain the providerName attribute. I have checked the obj/Release folder to see the actual configuration file that is published to Azure, and it does contain the attribute as well.
What am I doing wrong?
Never mind. It is in fact working now.
The reason I thought it wasn't working is that there is a delay in how Azure writes Trace data to TableStorage. This led me to believe that the WorkerRole was still throwing the error after updating the connection string, even though it wasn't.

Relative connection string to AzMan XML store when using security application block

Is it possible to specify a relative connection string for an AzMan XML store?
My current connection string is connectionString="msxml://c:/azman.xml" but I really need to make that relative so other developers and automated builds can get the latest authorization store.
MS documentation seems to suggest that connectionString="msxml://azman.xml" should work but that throws a The request is not supported error.
EDIT: I realised that the fact I'm using AzMan through the Enterprise Library Security Application Block was important to the question.
It is possible to enter the token {currentPath} into the connection string used by the security application block.
This gave me the behavior I was after, allowing the AzMan.xml file to be accessed from with the application folder.
The connection string I am using is:
<authorizationProviders>
<add storeLocation="msxml://{currentPath}/azman.xml"
application="My_Application" scope="" auditIdentifierPrefix="AzMan Authorization Provider"
type="Microsoft.Practices.EnterpriseLibrary.Security.AzMan.AzManAuthorizationProvider, Microsoft.Practices.EnterpriseLibrary.Security.AzMan, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
name="AzMan Provider" />
</authorizationProviders>
Adding the ~ will make it relative to the application
<add name="AuthorizationServices" connectionString="msxml://~/App_Data/AzMan.xml"/>
If you use {currentPath}, be sure your current directory is properly set before you make the "AuthorizationFactory.GetAuthorizationProvider" call. I am also using the Enterprise Library Security Application Block.
Ex.
My.Computer.FileSystem.CurrentDirectory = HttpContext.Current.Request.PhysicalApplicationPath