I am new to service broker and I am setting up a distributed topology. Two physical servers in the same domain, to replace a hacked up two way replication that continues to cause data corruption.
I am using the same domain account for both ends of the conversation and I am getting "The certificate's private key cannot be found" in profiler.
I had the same setup working with two separate local logins previously, so I am thinking that my issue is the fact that I am now attempting to use the same user account on both ends.
So my question is, does service broker require separate user accounts on each end of the conversation if I am using domain account with windows authentication, and if so is there any real advantage to using domain accounts instead of the way I had it previously with two local logins.
Related
We have an instance of SSRS running on 'Local System' service account. I have added the SMTP settings to the Configuration Manager. I now want to change the service account to use an authenticated Windows AD account to I can access the Exchange server and utilise subscriptions.
I am using 2008, other than a need to restart IIS/RS I want to check about the symmetric keys that are used for accessing the report server database that have been encrypted with the local machine.
I want to check the steps and caveats of changing the service account in configuration manager from Local System to MyDomain\My.User.
This page mentions about having to backup encryption keys first, then removing the reference to it after stopping IIS. Updating the service account and creating a new key before starting IIS.
So I need to do/worry about this or will the tool just handle this?
I suspect the tool 'should' manage all this for me but we know what assumptions are.
You need to use the Reporting Services Configuration tool to make changes to the service account being used. If you use this tool then it will automatically take care of permissions changes and modifying encryption keys. More details are available on MSDN.
The issue described on the website you linked to probably occurred because the service account was changed using the Services management tool in Windows, rather than the Reporting Services Configuration tool, and therefore the encryption key was not automatically updated.
Regardless of the above you should always back up the encryption keys for the report server and store them elsewhere.
I have a WCF web service that should always use a specific AD account, which has been granted access to the database, to execute SQL transactions. I read a couple of articles, but I'm obviously doing/understanding something wrong because I'm not getting it to work the way I want.
I figured that that web service should impersonate the AD user, so I enabled impersonation in the web service web.config:
<identity userName="dmn\wsusr" password="p#55w0rd" impersonate="true"/>
Then, since I'm technically using a Windows user to connect to SQL, I set the connection string as follows ("Integrated security=true;" for Windows authentication, right?):
Data Source=SQLSVR\INSTNC; Failover Partner=SQLSVR\INSTNC2; Initial Catalog=DB; Integrated Security=true;
For testing the connection I insert some values into a table. One of the columns of the table I'm inserting to has the following definition:
[LogUser] VARCHAR(75) NOT NULL DEFAULT USER
So, theoretically, the AD username of the user who opened the connection will automatically be inserted into the column. Unfortunately, however, the column contains my own AD username every time.
I'm testing the web service via a web site that uses Windows authentication, so I'm assuming that this plays a role in the cause of the problem. But the website authentication should be disregarded since this will be an externally accessible web service and SQL transactions should never rely on authentication between the client and the web service.
Thanks!
EDIT
I also tried:
Adding Trusted_connection to the connection string, but it yielded the same result as above.
Using User ID and Password in the connection string, but since the connection string only accepts SQL users, this resulted in a Login failure error
EDIT2
I suggested to my superiors that we should try the approach where you create a separate application pool for the service, set it up to run as the AD user, and allow the AD user to log on as a service (something I read somewhere) but they're not keen on that and reckon it should be a "last resort"
we have an application being developed where it is running as the AD user connecting to a service broker enabled SQL Server 2008 database.
We are having trouble granting the right permissions to get the app to work for the specific user,
(the app creates/deletes queues during its operation) unless we make that user a member of dbo for the database being used for the service broker application.
Is this the only way we can get the app to work, put each user as a member of dbo in the database?
Granting CREATE QUEUE/SERVICE TO user and SELECT on the specfic tables doesnt seem to be enough.
thanks
Due to the distributed nature of Service Broker, queues and services should be long lived objects. An application that creates and drops queues and services is very unlikely to act correctly.
That being said, the required permission is RECEIVE to operate on a queue (BEGIN CONVERSATION/SEND/RECEIVE). The user that created a queue is the queue owner and has this permission implicitly. To deliver messages to a target service the initiator service must have SEND permission, but be carefull that identity is established using Service Broker dialog security which is based on certificates. Note though that * within a SQL Server instance* the Service Broker conversation security model will emulate the familiar model of user-id (ie. no certificates are required to establish identity), but is subject to EXECUTE AS context.
If you can be more specific about which operation fails, we can be more specific about what permission is required.
Create separate schema per user and make the user the owner of that schema. Service broker will create the sprocs and queues in the default schema of the user. This post on how to setup service broker permissions may help you: http://kreelbits.blogspot.com/2014/10/microsoft-sql-useful-database-role-for.html
I've been searching hard to get my head around security related issues in a SQL Server.
We're developing a .NET application that targets SQL Server 2008 and we want to use FileStream.
Now I've found out that SQL Server only allows FileStream through the Win32 API if you use Integrated Security. The problem is that we have around 80% of our application finished, but it is entirely based on SQL Authentication. So we are doing INSERT's straight form our application and are not using Stored Procedures for every CRUD operation.
This is relatively safe because I can store the the SQL username and password in an encrypted form. I know the password is transported in Clear Text, but I'm willing to accept that.
We want end-users to be able to connect to the databse through tools such as Crystal Reports and for that we have an extra SQL login that has only SELECT-rights granted.
Now, if we change to Integrated Security we would have to give individual users (via AD groups, etc.) rights to do the things the application can do. Otherwise the application would not be able to do it's work. But then the end-user would also have these rights when he connects straight to the DB.
I see people saying that you should use Stored Procedures for every CRUD operation and grant the EXEC-rights only to the AD-group, but how would I do this? I do not see how a user would have different authorizations when he connects directly or through the application... Can anybody enlighten me on this.
An extra question for bonus-points: Intergrated Security will not work on a Workgroup as far as I understand. How do people get FileStream to work in a Workgroup then? Or is this considered an impossibility?
Integrated security WILL work in a workgroup, using the legacy mechanism, where you have a matching username and password on the two machines. Also, a domain user can use the legacy mechanism to log into a non-domain server if the server has a matching user account.
Integrated security can even work with non-matching usernames and passwords. This may help you in your scenario.
Try this:
NET USE \\DBSERVER /USER:DOMAIN\USERNAME
You will be prompted for your password. This establishes a NetBIOS session with the database server. You should be able to see the shared folders and shared printers on the database server once you have done that.
Once a netbios session has been established between the client computer and the database server, you will THEN be able to use integrated security without being prompted for a password.
You may have to specify "named pipes" as the network protocol to usem, if it doesn't work with TCP (but I think it will). Named Pipes inherits your existing NetBIOS session, so provided you can list the shares you are probably good to go.
You can also establish the logon session using the windows API function NetUseAdd with USE_INFO_2 (level 2) information which incorporates the password.
I guess the short answer then is that you can have a special Windows logon for your application and have the users log in using that. However note that they cannot also be connected to the same server using their own username and password.
So far, after creating DB with all the schema, all I have done so for was accessing them (tables) by reference through ConnectionStrings.
Now, twice, I've read that it's better to create a DB user and access the DB trhough that user by including him in the connectionString.
I'd like to know why so?
Thank for helping
Your question isn't that clear. It seems that you're asking if it is better to use windows security ("Integrated Security=SSPI" in the connection string) or a username/password ("User ID=myUsername;Password=myPassword;").
Its always better to use windows security. Having login information within the connection string is a security risk. Its in cleartext (unless you take some complicated steps to secure that section), and is sent across the wire as cleartext unless you set up a trusted connection between application and server.
Is it better to "create a db user and access the db trhough that user by including him in the connection string?" No. Its better to create a sql server login for user's windows identities and let them use those credentials to access the server.
You do this if you wish to connect as a specific user, rather than (for example) just using the context of the current user which your application is running under. However, if you use SQL Server authentication (i.e. username and password), you'd need to provide that password in the connection string, which is something of a security problem.
If the application has a group of anonymous users (or manages users/passwords itself) then its better to use a Windows login and run the application under a service account (which has minimal required access to the database).
If you're running an interactive application on the desktop, you should let those users connect to SQL server in their own context, by adding them to SQL Server with the required rights (e.g. db read/write , remove any higher functions). Obviously you would use groups to make administration simpler rather than adding individual users.