We have a project with Dal layers and View layer which is written in WinForm.
Those are separate project in same solution.
We have app.config file in the view project and in the Dal project that store the user name and the password of the DB.
I ask by the boss to check the possibility to work with Kerberos to avoid the need to write hard coded the password in the app.config.
I know that i have the option to encrypt the app.config as mention here Encrypt password in App.config
Still, id like to know how should i approach this thing to work with Kerberos.
What changes need to be done in the C# code, app.config file, databse server etc..
Thanx
P.S We do use with Kerbaros authentication in our compeny for other project.
This is how the authentication is right now:
1. Against the active directory: the user must be in some group, and of course we check the password that he type if it's much to one that store in the AD
2. Against a table in the DB
So with the kerbaros we don't need the user to type any password, right?
Enable Integrated Security on the connection string. This will use Kerberos (if properly configured) or NTLM. Read Authentication in SQL Server.
Related
I have two domains A and B.
Users sit on domain A and IIS, SSAS is on domain B. There is no trust between the domains.
Users shall be able to access data through the msmdpump on the IIS to access the SSAS server. It would be nice if they could do this seamless without authentication using in integrated windows security
Everything works fine if I allow anonymous users on the IIS and on SSAS. But then users are not authenticated.
One of the problems is msmdpump is a bit of a black box. You need access to it from the IIS but once Excel uses it i think it contacts SSAS directly using the credentials in the odc connection string.
Have anyone had a smilair problem and how did you solve it?
Integrated security doesn't work this way and msmdpump is really a blackbox ;) We have had similar problem in a scenario where we have a website with users that login and download excel reports with a predefined connection string. Unfortunately to avoid the user to have to type the password when he opens excel we have to store it in the excel file (and it is plain text). So our solution which might not be the best was to add ANOTHER proxy between the user and the SSAS which would take care about security. So the excel file instead of pointing to the MSDPUMP points to our proxy with some session token that gives permission to access reports.
In our case that proxy was part of the website and used the user session (if he is authenticated to the website currently he can open the excel report) and the SSAS password in the connection string was the real SSAS active directory password but it was not a security breach because SSAS was not accessible outside the internal the network. So the chain was:
User with excel file -> Our proxy that handles security -> IIS with msdpump -> SSAS
I am not sure it is the best solution but after lots of discussions and investigation we couldn't come up with something better and it works in the end ;)
I want to create a publication task in Jenkins to automatically publish my database changes along with my application.
If I understood correctly, a common practice is to create a publish profile that includes the database name as well as the account (login and password) of the account used for the deployment.
This means that the deployment account username and password will be stored in clear text on each developer computer as well as on the version control server and the continuous integration server.
Even though I created a specific login and password for the deployment, it seems pretty unsecured to me.
Is there a workaround? I can only think of replacing the password within the msbuild command line on the continuous integration server.
tl;dr version
Windows Authentication is the preferred, secure method of connecting to your SQL Server instance and if it's possible to use that then it's recommended to use that for connections.
If SQL Authentication is used then the default in publish profiles is that the password isn't saved. For build servers and other shared profile scenarios you may need to accept lower levels of security (by editing the publish profile to add the password, or setting it as a parameter in the build configuration) or work around it in some other way (custom script that reads it from some kind of a secret store, such as an encrypted value).
Long version
Windows Authentication: If at all possible use Windows Authentication, giving permissions as required to users who need it. For Continuous Integration scenarios you would need to give appropriate permissions to the account the build server executes under - full details are in the recent whitepaper on the SSDT blog.
SQL Authentication: If you look at the publish profile (Open With... Xml Editor) you'll see that the password information isn't actually stored there.
If you choose "Save Password" you'll have "Persist Security Info=True;" stored in the connection string rather than the password itself.
When a connection is made to a server/database in SSDT with "Save Password" enabled, the connection info is encrypted and stored in the registry under "HKEY_CURRENT_USER\Software\Microsoft\SSDT\ConnectionStrings". This has to be present on the machine in order to successfully publish using the publish profile.
Hence in a team environment every user would need to connect at least once before that publish profile would work for them. However, the password would be safely encrypted on user machines.
For the build server, your options are more limited. One possibility is to manually log in as the build server user and then connect to the database, but this isn't very scalable. To avoid the less secure options you mentioned you'd need to implement your own logic for persisting the password securely. You can look at the Protected Data API which can be used to do something similar to what SSDT does but on a per-machine level, or use an encrypted configuration file.
If you have to use SQL Authentication I think passing the password into the publish action as part of the build configuration may be the "best" way to go in terms of a tradeoff between ease of development and security. At least that way you can restrict who can view and edit the build configuration in TFS and regular developers won't see it.
I'm thinking of using application roles in SQL Server I've read the following on the Microsoft MSDN site:
http://msdn.microsoft.com/en-us/library/ms190998.aspx
Connecting with an Application Role
The following steps make up the process by which an application role switches security contexts:
A user executes a client application.
The client application connects to an instance of SQL Server as the user.
The application then executes the sp_setapprole stored procedure with a password known only to the application.
If the application role name and password are valid, the application role is enabled.
At this point the connection loses the permissions of the user and assumes the permissions of the application role.
I'm wondering, if the application must know the password, how best to achieve this. I would assume storing the password in source code is a security risk. Is there another secure way to deploy the password with the application (note this is a windows client application that will be deployed to user machines).
There is actually another way to deploy the password with the application.
You can store the password as a secret in the database itself.
For instance, use a stored procedure or a scalar function which returns this "secret". This is an additional step in the logic you describe, to be executed just after the connection is made by the application with the user credentials.
This is possible because the users will have access to the database using Windows Authentication anyway.
The permissions need to be setup so that users are granted access to connect to the database and to the programmable object only.
To "obfuscate" (NOT secure) the password, you can store an encrypted version in the database and use a simple encryption / decryption (like this one).
This approach has the following advantages:
The password is not stored in clear text anywhere (please note though that it will travel in clear text on the network if you do not use SSL Encryption)
Users of the application are not required to provide any input
The application source code does not include the password
The application deployment does not include the password
The password can be reset very easily, for instance on a schedule
There is no way to deploy a password on a user workstation w/o a local administrator being able to discover it. You can only raise the bar so high, but if the price is worth it they will find it.
You should rely on the user providing the password, which ultimately boils down to using Windows authentication instead, if possible. You should always assume that whatever privileges the application has, the user has them as well and he/she can exercise them using an alternative access API (ie. any query tool). If you cannot trust the user with certain privileges, then you must not deploy the application on his/her computer. For example use a multi-tier solution that isolates the database from the user and add any necessary validation in this intermediate tier (most ASP.Net and/or WCF apps would qualify as such multi-tier when done properly).
I am creating an Access project linked to a SQL Server. Instead of using Windows authentication for the SQL Server I want to use an application specific username/password and authenticate users myself using a login form. The reason is that other applications may connect to this database from a context where Windows authentication is not an option (FileMaker Server for instance).
I have found myriad discussions that cover this issue from one angle or another, but none that have actually enabled me to implement a solution. I do not have a lot of VBA or LDAP experience but I know this must be possible.
So, what I want to do is:
Ask the user for a username and password when they open the database.
Use that username and password to authenticate them
against our LDAP server.
Proceed if it passes, fail if it does not.
Can someone sketch out how this works or point me to a resource that describes this?
One way to accomplish this is to create a VBA procedure which loops through all of your linked tables and alters the connection string to embed the username and password from a login form.
You can get the syntax for the existing ODBC linked tables by going to the debug window and typing this:
? CurrentDb().TableDefs("My Table Name").Connect
Which should give you something similar to:
ODBC;DRIVER=SQL Server;SERVER=MYSQLSERVER001;UID=JPARKER;PWD=Pizza123;APP=2007 Microsoft Office system;DATABASE=MyDatabaseName
So your login form would capture the user name and password from the user, then store those as variables and use to build a new connection string. Then iterate through the tabledefs collection updating the connect property. Happens pretty quickly.
I prefer to keep our SSIS packages in a solution on the server, not in sql. By default, sensitive data is encrypted with a user key. Since the sql server agent uses a service account to run jobs, we have to change this encryption method to something else. I like encrypting with a password.
The problem is whenever I setup a job in a step there is no place to input this password. When I click on the configurations tab, I get a popup dialog for the password. That keeps it stored properly, but is this really the right place to put it. It seems really unusual, and I keep running into issues where it seems to reset itself if I make certain changes.
Does anyone know of a better place to input this password that is more stable?
Thanks,
There is no need for you to have a password in the package at all if you can use Windows authentication and avoid SQL Server authentication and ensure that the rights necessary to execute your package are available to your service account.
Barring that, you should already be overriding the connection string with a config file using package configurations so your package is portable, and then the password doesn't need to be in the dtsx anyway.
The way you deploy your package and store your package in your local project solution can be different. You can save sensitive data with a password when saving your packages locally and "rely on server storage and roles for access control" when deploying the package. Although the data will not be stored in an encrypted format in the msdb database, you can restrict access to the password information by managing pre-existing database roles.
You need set the password on your Job.
Go to the properties of your Job > two clicks over your Step > in the tab "General" type your login and password, than in the tab "Configuration" type your password (the password that you put inside the SSIS)