Laurentiu Cristofor's blog @microsoft.com : SQL Server - general

Finding information about which account xp_cmdshell is running as

lcris — Tue, 27 Oct 2009 21:24:00 GMT

If you ever needed to debug a permission related issue when using xp_cmdshell, you have probably realized that a crucial piece of information is about what particular account xp_cmdshell is executing under. If you are the administrator of the database, you already know the context used by xp_cmdshell, but otherwise you may not have that information. Here are some tips on how to find more.

First, if you have a command line tool that displays the current context, like whoami or a utility for dumping the security contex, you can just execute that under xp_cmdshell. That's pretty easy. But what if there is no such tool available? One thing you can try in this case is to loop back into SQL (assuming the xp_cmdshell account has access to the database - it usually does) and just ask SQL for more information with queries like the following:

EXEC xp_cmdshell 'osql -E -Q"select suser_sname()"'

EXEC xp_cmdshell 'osql -E -Q"select * from sys.login_token"'

Don't forget to pass in the server/instance name using the -S option, if you are not dealing with a default instance. These should give you plenty of information about the xp_cmdshell context and should help you figure out any access permission issue.

Given that I am on the topic of xp_cmdshell, here's how the command can be enabled using T-SQL:

sp_configure 'show advanced options', 1
reconfigure

sp_configure 'xp_cmdshell', 1
reconfigure

Some insight information into how SQL Server documentation is prepared

lcris — Thu, 15 Feb 2007 01:20:00 GMT

Buck Woody just wrote an interesting post about the process of writing documentation for SQL Server. After reading this, you should have no excuse for not providing feedback on Books Online articles that you feel are incomplete or have inaccurate information - your feedback matters!

Raul starts his blog...

lcris — Tue, 14 Mar 2006 00:22:00 GMT

Some of you may already know Raul from the SQL Server Security forums. Raul has just started his blog at http://blogs.msdn.com/raulga/. His first post provides a detailed discussion of indexing encrypted data: http://blogs.msdn.com/raulga/archive/2006/03/11/549754.aspx.

A couple of links for submitting feedback on Microsoft products

lcris — Fri, 02 Dec 2005 01:32:00 GMT

I want to advertise a couple of sites that can be used for submitting feedback and suggestions, or for filing bug reports for Microsoft products. These are:

The Microsoft Technical Forums at: http://forums.microsoft.com/MSDN/. The SQL Server Forums are at: http://forums.microsoft.com/MSDN/default.aspx?ForumGroupID=19&SiteID=1.

The Product Feedback Center at: https://connect.microsoft.com/default.aspx.

Update [2005/12/21]: Another useful link for reporting security vulnerabilities is: http://www.microsoft.com/technet/security/bulletin/alertus.aspx

A new blog link

lcris — Fri, 14 Oct 2005 03:15:00 GMT

Here's a link to a new blog that a colleague has started: http://blogs.msdn.com/yukondoit/. The first entry is about the various levels of data protection in SQL Server 2005 and you can access it at: http://blogs.msdn.com/yukondoit/articles/480854.aspx.

SQL Server 2005: How to fix outdated names of Windows logins

lcris — Tue, 27 Sep 2005 20:34:00 GMT

The SQL Server login catalogs store the names of Windows principals as well as their SIDs. Because the names are stored, changes that affect a name can lead to a state where a catalog entry is out of sync with the current login name. For example, in the case of local Windows accounts, if we change the machine name, the catalogs will reflect the old machine name. Also, if we change the name of an account, the catalog will still contain the old account name. One side-effect of this will be that queries that rely on logic like select * from syslogins where name = suser_name() will be broken. What needs to be done here is to update the login names using the ALTER LOGIN statement. Based on the LookupSid function that I introduced in my previous post, I wrote a small T-SQL script that loops over the server_principals catalog entries and verifies whether the names recorded are matching the names that Windows returns for the associated SIDs. If differences are detected, the script will output the ALTER LOGIN statements that will fix the situation. Note that no data is changed here; the script is simply producing as output the statements that should be run to rectify the problem. Here's the script:

--
-- Execute this to generate the list of statements that need to be executed
-- to fix the Windows login names that are invalid
--
declare @login_name sysname
declare @login_sid varbinary(max)
declare crs_fix_login_names cursor for select name, sid from sys.server_principals where lower(name) <> lower(dbo.LookupSid(sid)) AND (type = 'U' or TYPE = 'G')

open crs_fix_login_names
fetch next from crs_fix_login_names into @login_name, @login_sid
while (@@fetch_status = 0)
begin
print 'ALTER LOGIN ' + quotename(@login_name) + ' WITH NAME = ' + quotename(dbo.LookupSid(@login_sid))
fetch next from crs_fix_login_names into @login_name, @login_sid
end
close crs_fix_login_names
deallocate crs_fix_login_names
go

So, the script is using a cursor to go over each Windows login entry (of type U or G - Windows user or group) and verify whether the name in the catalog is different from the name returned by the OS for the SID. For each such instance, the script builds the ALTER LOGIN command that needs to be executed to update the login name. Nothing is actually modified by this code. If there is any output, it should be copied and examined for errors, then executed to correct the login names. If there is no output, then no problems were detected by the script.

SQL Server 2005: An example of writing a CLR function that wraps the LookupAccountSid WinAPI call

lcris — Tue, 27 Sep 2005 01:51:00 GMT

I was looking recently into writing a wrapper for the LookupAccountSid WinAPI function, so that I could use this functionality in T-SQL. I decided to write a CLR function and document the steps here:

1. First, we need to write the code into a file - I named it LookupNameSid.cs. I tested this code with both the 1.1 CLR and the 2.0 CLR. To keep this post shorter, I will not include comments in the code, but instead I'll provide a quick overview of what gets done here: the LookupSid function is passed the SID in a byte array, it copies these bits into memory pointed to by an IntPtr, and then we call the WinAPI function LookupAccountSid - first to determine the length of the buffers that will receive the output and a second time to get the result; the rest is just error handling and memory management.

/////////////////
//
// LookupNameSid
//
// Wrapper around WinAPI function LookupAccountSid
//
// compile command:
// csc /target:library /out:LookupNameSid.dll LookupNameSid.cs
//
/////////////////

using System;
using System.Runtime.InteropServices;
using System.Text;

public class LookupNameSid
{
    const int NO_ERROR = 0;
    const int ERROR_INSUFFICIENT_BUFFER = 122;

    enum SID_NAME_USE
    {
        SidTypeUser = 1,
        SidTypeGroup,
        SidTypeDomain,
        SidTypeAlias,
        SidTypeWellKnownGroup,
        SidTypeDeletedAccount,
        SidTypeInvalid,
        SidTypeUnknown,
        SidTypeComputer
    }

    [DllImport("advapi32.dll", CharSet = CharSet.Auto, SetLastError = true)]
    private static extern bool LookupAccountSid(
        string lpSystemName,
        IntPtr Sid,
        StringBuilder lpName,
        ref uint cchName,
        StringBuilder ReferencedDomainName,
        ref uint cchReferencedDomainName,
        out SID_NAME_USE peUse);

    public static string LookupSid(byte[] rgSid)
    {
        if (rgSid == null || rgSid.Length == 0)
            return null;

        IntPtr pSid = IntPtr.Zero;
        uint cbSid = (uint)rgSid.Length;

        pSid = Marshal.AllocCoTaskMem(Convert.ToInt32(cbSid));

        Marshal.Copy(rgSid, 0, pSid, (int)cbSid);

        StringBuilder name = new StringBuilder();
        uint cchName = (uint)name.Capacity;
        StringBuilder referencedDomainName = new StringBuilder();
        uint cchReferencedDomainName = (uint)referencedDomainName.Capacity;
        SID_NAME_USE sidUse;

        int err = NO_ERROR;

        if (!LookupAccountSid(null, pSid,
            name, ref cchName,
            referencedDomainName, ref cchReferencedDomainName, out sidUse))
        {
            err = Marshal.GetLastWin32Error();
            if (err == ERROR_INSUFFICIENT_BUFFER)
            {
                err = NO_ERROR;
                name.EnsureCapacity((int)cchName);
                referencedDomainName.EnsureCapacity((int)cchReferencedDomainName);

                if (!LookupAccountSid(null, pSid,
                    name, ref cchName, referencedDomainName,
                    ref cchReferencedDomainName, out sidUse))
                {
                    err = Marshal.GetLastWin32Error();
                }
            }
        }

        Marshal.FreeCoTaskMem(pSid);

        if (err == NO_ERROR)
        {
            return referencedDomainName.ToString() + "\\" + name.ToString();
        }
        else
        {
            return null;
        }
    }
}

2. The next step is to compile this into a DLL. I used the command line compiler for this: csc.exe. This can be found in the Windows directory, under Microsoft.NET\Framework\version\, where version is the CLR version. On my machine, the command looked like this:

C:\WINNT\Microsoft.NET\Framework\v2.0.50727\csc.exe /target:library /out:LookupNameSid.dll LookupNameSid.cs

The path to csc.exe may need to be updated according to the machine settings, for this to work. The result of this step should be that now we have a DLL file containing the LookupSid function.

3. Now come the steps required for installing this assembly. Note that this is an unsafe assembly because it calls unmanaged code - the WinAPI. Also, I decided to install this code in my master database, but a better idea is to put it in another database. Finally, because this is an unsafe assembly and because I didn't want to sign it, I decided instead to mark the database in which I placed it as trustworthy. Here are the T-SQL commands that I used to install the assembly (the path to the DLL in CREATE ASSEMBLY will most likely need to be updated):

--
-- Steps for importing the CLR code into SQL Server
--
ALTER DATABASE master SET TRUSTWORTHY ON;
GO

CREATE ASSEMBLY LookupNameSid FROM 'C:\TEMP\LookupNameSid.dll' WITH PERMISSION_SET = UNSAFE;
GO

CREATE FUNCTION LookupSid (@sid VARBINARY(85)) RETURNS SYSNAME AS EXTERNAL NAME [LookupNameSid].[LookupNameSid].[LookupSid];
GO

sp_configure 'clr enabled', 1
GO
reconfigure
GO

SELECT dbo.LookupSid(sid), name FROM syslogins;
GO

So, I turned on the TRUSTWORTHY attribute of the master database, then I created the assembly and the LookupSid function, and then I turned CLR on. Last command is just to test that the function works ok; it basically looks up the SID for each entry in the syslogins catalog, and it prints the name found, as well as the name recorded in the catalog. For SQL logins, we'll just print NULL. If the code from step 1 is modified to use a namespace, then the second part of the external name used in CREATE FUNCTION will also need to be modified to include the namespace name.

That's it! The LookupSid function can now be used to map SIDs to account names.

4. The following T-SQL commands can be used to revert the changes made to SQL Server in the above steps. I assume a default SQL Server state where CLR was not enabled and the master database was not marked as trustworthy, so if this was not the case, the corresponding cleanup steps should be skipped.

--
-- Cleanup steps
--
DROP FUNCTION LookupSid;
GO
DROP ASSEMBLY LookupNameSid;
GO
sp_configure 'clr enabled', 0
GO
reconfigure
GO
ALTER DATABASE master SET TRUSTWORTHY OFF
GO

An example for setting database mirroring in SQL Server 2005

lcris — Wed, 14 Sep 2005 20:45:00 GMT

I am not a database mirroring expert, but a while ago I have set up database mirroring between two of my machines. I collected the steps that I followed in the following script:

-- This script illustrates how to setup database mirroring between two machines.
-- The script assumes that the principal machine is SQLPRINCIPAL and that the mirror machine is SQLMIRROR.
-- Also, a dbm share will exist on SQLPRINCIPAL, and SQLMIRROR can read and write from it.

-- on SQLPRINCIPAL:
--
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Af01AufdSL';

CREATE CERTIFICATE cert_dbm_principal AUTHORIZATION DBO WITH SUBJECT = 'DBM - Principal';
BACKUP CERTIFICATE cert_dbm_principal TO FILE = '\\SQLPRINCIPAL\dbm\cert_dbm_principal.cer';

CREATE ENDPOINT dbm STATE=started AS tcp (listener_port=5022) FOR database_mirroring (role=all, authentication=certificate cert_dbm_principal);

CREATE DATABASE dbm ON PRIMARY (NAME = br_dat1, FILENAME = "c:\dbm\dbm.mdf", SIZE = 8mb) LOG ON (NAME = br_log1, FILENAME = "c:\dbm\dbm.ldf", SIZE = 8mb);
BACKUP DATABASE dbm TO DISK = '\\SQLPRINCIPAL\dbm\dbm.dmp' WITH FORMAT;

-- do the mirror steps before returning here.

CREATE LOGIN l_dbm_mirror WITH PASSWORD = 'Neufd1C';
CREATE USER u_dbm_mirror FOR LOGIN l_dbm_mirror;
CREATE CERTIFICATE cert_dbm_mirror AUTHORIZATION u_dbm_mirror FROM FILE = '\\SQLPRINCIPAL\dbm\cert_dbm_mirror.cer';
GRANT CONNECT ON ENDPOINT::dbm TO l_dbm_mirror;

ALTER DATABASE dbm SET PARTNER = 'tcp://SQLMIRROR.domain.company.com:5022';

-- on SQLMIRROR:
--
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Dgc6a3um';

CREATE CERTIFICATE cert_dbm_mirror AUTHORIZATION DBO WITH SUBJECT = 'DBM - Mirror';
BACKUP CERTIFICATE cert_dbm_mirror TO FILE = '\\SQLPRINCIPAL\dbm\cert_dbm_mirror.cer';

CREATE ENDPOINT dbm STATE=started AS tcp (listener_port=5022) FOR database_mirroring (role=all, authentication=certificate cert_dbm_mirror);

CREATE LOGIN l_dbm_principal WITH PASSWORD = 'Sc6d061t';
CREATE USER u_dbm_principal FOR LOGIN l_dbm_principal;
CREATE CERTIFICATE cert_dbm_principal AUTHORIZATION u_dbm_principal FROM FILE = '\\SQLPRINCIPAL\dbm\cert_dbm_principal.cer';
GRANT CONNECT ON ENDPOINT::dbm TO l_dbm_principal;

RESTORE DATABASE dbm FROM DISK = '\\SQLPRINCIPAL\dbm\dbm.dmp' WITH NORECOVERY;

ALTER DATABASE dbm SET PARTNER = 'tcp://SQLPRINCIPAL.domain.company.com:5022';

-- Additional commands
--
-- to remove mirroring, issue on either partner:
ALTER DATABASE dbm SET PARTNER OFF;

-- to check the state of mirroring, issue:
SELECT * FROM sys.database_mirroring;