I'm looking to identify all linked servers connections that have security setup with either "Be made using the login's current security context" or "Be made using this security context"
I can utilize a centralized job or PowerShell command to run on all of my instances, but I can't find any queries that link security to queries like select * from sys.syservers, or sys.servers, or executing the stored procedure sp_linkedservers. All of those give me information about that servers linked servers, but no information about the security related to those connections. Is there system tables that I'm not finding that add this information, maybe with a join or something? I'll be doing this on a range of environments from 2014 to 2019.
Related
Public Domino server has a publicly available Lotus Notes database. That database has a form that an unauthenticated user can fill out and submit using his/her browser.
This publicly available form is only used for the post request and data must not be stored on that publicly available server. Instead, I need to connect to a database on an internal server and create the document there.
Obvious solution is a Lotus Script agent but when I worked on Notes, I remember non-user agents were prevented from opening databases on another server for security reasons. I certainly cannot introduce secure server setup. I need to find a way to do this that fits current setup. The servers are in two different Notes networks but mail is routed between them, so if I don't find a better solution, I will probably mail the document.
Any ideas? I have not worked with latest Notes servers. Anything in 8.5 that can help here?
In the server document on the security tab there is an Option called "Trusted Servers" if you could put the external server into that field, then the agent would be allowed to dirctly write into databases on the internal server.
If you are not able / allowed to do this, then you have to write to a "local" database (on external server) and replicate this database to internal server either by using a console command (NotesSession.SendConsoleCommand) or with the replicate method of the NotesDatabase class (not sure, if this will work due to the same security restrictions) or via scheduled replication.
If the database itself cannot be replicated on the external server, then you should use a container database and let an agent on the internal server copy the data to the internal database.
And the last possibility you already mentioned: compose the document and send it via mail. Make the target database a mailin- database and simply send you data there with NotesDocument.Send...
One of these options should solve your problem.
I have been allocated the responsibility at work of revising the current reporting services authentication process. The aim is to maintain the necessary level of security and also simplify the maintenance/configuration of granting access to the individual reports.
I do NOT have access to the domain controllers to be able to modify or create new AD groups. I have to work with the groups/users that currently exist.
In terms of authentication, it seems that I have the option of using either:
Windows authentication
SQL Server authentication.
Both the report server and the report database will reside on the same server. With this in mind, I understand that Windows authentication is probably a better solution as there is no need to maintain a separate SQL Server table of Users (and their passwords). Granting access to a report once it has been deployed on the report server, would simply involve adding the user/group to the report (load the report in a browser and access the Properties\Security option).
Using the second option of SQL Server authentication does not seem as appropriate as using Windows authentication for the reason the report server and report database are on the same box.
I am using SQL Server 2000 databases. The version of reporting services I have installed is Microsoft SQL Server 2008.
Please could someone let me know if my thinking is correct (i.e. I should go for Windows authentication). Cheers.
Jimmy
Sql Server authentication is not an option for users connecting to SSRS. It is an option for SSRS connecting to databases where it will get its data.
So bottom line, yes, you need to use Windows Authentication for user connections to SSRS. You can use special user names such as "Authenticated Users" or "Everyone" in SSRS to allow broad access.
I understand that you don't have access to AD, but managing the user accounts' membership in AD groups would be much easier than tracking and managing individual access in SSRS.
But without the AD access you can still add Windows/AD accounts to the report permissions and use those. You just create a more complex system, since you need to manage permissions for every individual separately. You can group the reports in folders and secure the folders: the reports can inherit that security.
We have a DB server with a couple web app db's on there (don't get a ton of traffic). We'd like to make use of the server and allow it to be the DB server for sharepoint. I'm assuming it's not good practice and that sharepoint should have it's own exclusive db server. Am I right in that conclusion, or is it alright if we put the database on a server that already hosts other databases.
You can install SharePoint on an existing DB server, sure. Unless your environment is going to be huge, I don't see why you would give it its own DB server. It will use an embedded SQL Server instance if you want, but you'll get better performance if you have the full-blown version. We're running a few SharePoint apps on our DB server with a number of other applications.
The way in which I solve this is to install a second SQL Server instance dedicated to SharePoint, as SharePoint likes to have a lot of control over the database and spews all sorts of stuff such as logins, etc. across the instance, which you really want to separate from your standard line of business instance.
The added bonus is multiple SQL Server instances on the same physical machine are included in your licence.
Be careful with the SQL Server collation. I think SharePoint requires a particular setting for this. See http://www.moss2007.be/blogs/vandest/archive/2007/07/24/sharepoint-2007-and-sql-server-collation-latin1_general_ci_as_ks_ws.aspx for one reference.
Prior to centralizing our environment we had many Sharepoint sites located on servers with existing applications. I'm not a fan of adding an additional named instance as this increases the administrative overhead for the DBA. You have to know how much use you expect of your Sharepoint instance then measure the resource utilization of your existing applications balance it from there.
I am trying to test a proof of concept that I can run a distributed transaction across two linked SQL Servers, linked using sp_addlinkedserver - their names are Server1 and Server2, both running under default instances. Each server holds a single database, Source and Destination respectively and the destination database holds a single table called Output, i.e.
Server1.Source
Server2.Destination.Output
The OUTPUT table has the following structure:
OUT_PKEY int identity(1,1) primary key,
OUT_TEXT nvarchar(255)
From Server1 I have called sp_addlinkedserver 'Server2' to link the two databases and I've attempted to run the following query to test that the link does indeed work:
Select *
From Server2.Destination.dbo.Output
I am returned the following exception:
Access to the remote server is denied because no login-mapping exists.
Fair enough, so from Server1, I run sp_addlinkedsrvlogin 'Server2' which according to the documentation says that it should take the user credentials of whomever runs the query remotely (i.e. from Server1) and apply those credentials to Server2. This implies that since I am connected to Server1 using Windows Authentication, this should mean that my Windows Credentials are applied to Server2 also.
Now the exception message changes to:
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
Having Googled this exception, I came up with nothing useful that pointed me in the right direction. What am I missing? I would expect [should the login fail at all] the exception to reference my Windows Credentials, not the anonymous logon credentials.
It looks like once I get the link itself working, the distributed transactions themselves should be a fairly simple affair - the documentation implies that I just need to ensure that the DTC Service is running on Server1 and that any queries run on Server1 that will be transacted across the link:
Include SET XACT_ABORT ON prior to initializing my distributed transaction
I use BEGIN DISTRIBUTED TRANSACTION instead of BEGIN TRANSACTION
If I wish to reference a non-default instance of SQL Server on Server2, I replace any instances of the name Server2 in my query with [Server2\InstanceName]
My questions are these:
how do I get past this login issue? The sp_addlinkedsrvlogin stored procedure alone doesn't seem to be doing the trick.
Is it indeed as simple as that to run the distributed transaction as the documentation implies?
TIA
If you're on a domain, then the setting should be "Be made using the login's current security context", but there's one more step - you need to grant an SPN to each of the servers involved in the transaction.
Assuming you're running the SQL Services on both servers as a domain user (which you'll need to in order to make this work - LocalSystem won't do it), here are the instructions you'll need:
http://technet.microsoft.com/en-us/library/bb735885.aspx
Remember that the user will need an SPN for both servers, but not the client - for example, if you are going from client -> server1 -> server2, the SQL Service account will need an SPN for both server1 and server2.
If you're confused (it's a confusing process), post a comment and I'll clarify the instructions.
Assuming these servers are both on the same domain - have you enabled trusted delegation to allow your server to pass the credentials to the targeted server? You would pull up the Active Directory object for the server and go to the Delegation tab and select "Trust this computer for delegation to specified services only" and then enter the SQL Server details that the server is allowed to pass credentials to:
Service Type = MSSQLSvc
User/Computer = YourTargetServer.Your.Domain
Port = 1433
Sadly, a lot of these types of authentication issues with linked servers require a reboot to fully take effect (so if these are production servers it is hard to troubleshoot during the day).
In regards to distributed transactions - if you eventually get the linked server connection up and running correctly then distributed transactions work great. Although the next thing you'll probably run into once you get it working is finding the huge flaw that you can't use any form of SCOPE_IDENTITY(), ##IDENTITY, etc. to retrieve primary keys after inserting something into a linked database. But that's another issue with its own fun workarounds...
I have built an application that uses SQL Express 2005 and I want to deploy it, but the problem is that anyone who has SQL Management Studio(or something like that) installed on his computer, can connect to my database and change it.
Is there anyway to prevent end-users from seeing or editing the content of my database, even those with the Administrator privileges?
I guess you're referring to the fact that by default SQL Server installs allow Windows and SQL Server Authentication. If you remove the Windows Authentication mode then users will have to connect via SQL Server authentication.
This from http://support.microsoft.com/kb/247931
SQL Server authentication SQL Server
authentication relies on the internal
user list maintained by the SQL Server
computer. This list does not include
Windows NT users, and is specific to
the SQL Server computer. Users are
created and configured using the SQL
Server Enterprise Manager. To use this
authentication method, perform with
the following steps:
• If you connect
through Open Database Connectivity
(ODBC), in the ODBC Administrator,
choose SQL Server authentication when
you configure the data source.
•In
the ActiveX Data Objects (ADO)
connection string, include the
parameters "UID" and "PWD" when you
use ODBC, and "User ID" and "Password"
when you use the SQLOLEDB provider.
I suppose this is not the answer you hoped for but it is unavoidable that anyone with administrative rights will be able to browse and edit information in the database.
You cannot change this.
Perhaps you could consider WHY you want to prevent this kind of access?
I expect you want to prevent tampering or accidental corruption of the data?
If that is the reason then you can go a long way to prevent corruption by adding constraints to your database. Add foreign key constraints, uniqueness constraints, everything that will help prevent data corruption.
Then an administrator would need to deliberately undo these constraints before they tamper, which would prevent most accidental corruption but of course not prevent malicious vandalism.
If you are concerned about protection of your intellectual property, you could encrypt the programmatic components (stored procedures and views and functions). This kind of encryption is not very strong but prevents casual inspection.
Encryption is added by using the
WITH ENCRYPTION
clause in your CREATE or ALTER statements.