SSIS: package write file to network share - Call Package (RDP vs Remote)

Question

I have an SSIS package that writes a .TXT data file to a folder. I tested this on my local machine: the SSIS packages successfully writes (to my C Drive-- C:\\myPath).

Then deployed to the server: the package fails to write (to network fileshare-- \\myDomain\\Folder1\\Folder2).

My user account has access to the folder. From the server, I have tried executing the package two different ways:

1) Remote connection from my computer with my user credentials, via SSMS (package fails to write the file). Remote session execution on my PC is not working.

2) RDP with Remote Desktop Connection to MYSERVER with my user credentials, via SSMS (package writes the file sucessfully). I am able to run it from the RDP session on MYSERVER and the file was written succesfully.

In summary: The package works, but it doesn't work. One of our network administrators added MYSERVER to have access to the folder-- which could be the reason why I can execute it from RDP session.

The exact error message is "Cannot open the data file":

My question:

A) Does anyone know why the package fails when I execute it with the same user account in two different ways (Local Connection vs. Server RDP)?

B) Does anyone have a recommendation on how I grant access for user to call the package themselves? The package has two input parameters (with default values) for the user to enter.

_

Message from my network administrator:

Your id is in the proper group to access the share and I even see numerous updates to the folder from your ID and yet I also find this.

Log Name:      Microsoft-Windows-SMBServer/Security
Source:        Microsoft-Windows-SMBServer
Date:          6/12/2018 9:01:21 AM
Event ID:      1006
Task Category: (1006)
Level:         Error
Keywords:      Audit Failure,(8)
User:          SYSTEM
Computer:      mySERVER.myDOMAIN
Description:
The share denied access to the client.
Client Name: \\10.26.151.96
Client Address: 10.26.151.96:57626
User Name: myDOMAIN\myUser
Session ID: 0x16C029C000581
Share Name: \\*\DIXFDev
Share Path: \??\D:\Shares\DIXFDev
Status: {Access Denied}
A process has requested access to an object, but has not been granted those access rights. (0xC0000022)
Mapped Access: 0x80080
Granted Access: 0x0
Security Descriptor: 0x0100048058000000680000000000000014000000020044000200000000031800FF011F000102000000000005200000002002000000002400BF011300010500000000000515000000007B755294545B7AB2192C25066D000001020000000000052000000020020000010500000000000515000000007B755294545B7AB2192C2500020000
Guidance:
You should expect access denied errors when a principal accesses a share without the necessary permissions. Usually, this indicates that the principal does not have direct security permissions or lacks membership in a group that has direct access permissions. To determine and correct the permissions on the specified share, an administrator can use the Security tab in File Explorer Properties dialog, the SMBSHARE Windows PowerShell module, or the NET SHARE command. You can also use the Effective Access tab in File Explorer to help diagnose the issue.
Applications may generate access denied errors if they attempt to open files in a writable mode first, and then reopen the files in a read-only mode. In this case, no user action is required.
If access to the share is denied and this event is not logged, you can examine the file and folder NTFS/REFS permissions.
This error does not indicate a problem with authentication, only authorization.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-SMBServer" Guid="{D48CE617-33A2-4BC3-A5C7-11AA4F29619E}" />
    <EventID>1006</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>1006</Task>
    <Opcode>0</Opcode>
    <Keywords>0x810000000000008</Keywords>
    <TimeCreated SystemTime="2018-06-12T14:01:21.342045500Z" />
    <EventRecordID>357496420</EventRecordID>
    <Correlation />
    <Execution ProcessID="4" ThreadID="2680" />
    <Channel>Microsoft-Windows-SMBServer/Security</Channel>
    <Computer>mySERVER.myDOMAIN</Computer>
    <Security UserID="S-1-5-18" />
  </System>
  <UserData>
    <EventData xmlns="Smb2Namespace">
      <ShareNameLength>11</ShareNameLength>
      <ShareName>\\*\DIXFDev</ShareName>
      <SharePathLength>21</SharePathLength>
      <SharePath>\??\D:\Shares\DIXFDev</SharePath>
      <ClientAddressLength>128</ClientAddressLength>
      <ClientAddress>0200E11A0A1A976000000000000000000000FFFF0A1A97600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000</ClientAddress>
      <UserNameLength>14</UserNameLength>
      <UserName>myDOMAIN\bl0040</UserName>
      <ClientNameLength>14</ClientNameLength>
      <ClientName>\\10.26.151.96</ClientName>
      <MappedAccess>0x80080</MappedAccess>
      <GrantedAccess>0x0</GrantedAccess>
      <ShareSecurityDescriptorLength>132</ShareSecurityDescriptorLength>
      <ShareSecurityDescriptor>0100048058000000680000000000000014000000020044000200000000031800FF011F000102000000000005200000002002000000002400BF011300010500000000000515000000007B755294545B7AB2192C25066D000001020000000000052000000020020000010500000000000515000000007B755294545B7AB2192C2500020000</ShareSecurityDescriptor>
      <Status>0xc0000022</Status>
      <TranslatedStatus>0xc0000022</TranslatedStatus>
      <SessionID>0x16c029c000581</SessionID>
    </EventData>
  </UserData>
</Event>

Script created from SSMS RDP session with paramter values:

DECLARE
        @execution_id bigint EXEC [SSISDB].[catalog].[create_execution] @package_name=N'FYE AP AuditFile_rep238.dtsx', @execution_id=@execution_id OUTPUT, @folder_name=N'IsolatedPackages', @project_name=N'FYE AP AuditFile_rep238', @use32bitruntime=False, @reference_id=56
        SELECT
                @execution_id DECLARE @var0 sql_variant = N'\\MYSERVER\folder1\folder2\SSISPackages\FYEAPAuditFile\audit-file-ap_ax-export_REP238_piped.txt' EXEC [SSISDB].[catalog].[set_execution_parameter_value] @execution_id,
                @object_type                            =                                                                                                                                                                30           ,
                @parameter_name                         =N'paramFilePath'                                                                                                                                                             ,
                @parameter_value                        =@var0 DECLARE @var1 sql_variant = N'2017' EXEC [SSISDB].[catalog].[set_execution_parameter_value] @execution_id                                                              ,
                @object_type                            =                                                                                                  30                                                                         ,
                @parameter_name                         =N'paramYear'                                                                                                                                                                 ,
                @parameter_value                        =@var1 DECLARE @var2 SMALLINT = 1 EXEC [SSISDB].[catalog].[set_execution_parameter_value] @execution_id                                                                       ,
                @object_type                            =                                                                                         50                                                                                  ,
                @parameter_name                         =N'LOGGING_LEVEL'                                                                                                                                                             ,
                @parameter_value                        =@var2 EXEC [SSISDB].[catalog].[start_execution] @execution_id GO

SSMS image of calling package:

Answer 1

In both cases, you connect to SQL Server using your user account, which was authenticated by a domain controller when you were logging on to

1. Your client computer
2. The server running SQL Server and SSIS

In the second case (RDP), that's like you on the server accessing the file share. In the first case (remote SSMS), you on your client computer are asking a remote SQL Server to access the file share using your security context. This is called Active Directory Delegation (or “Kerberos Delegation”) and needs to be configured. Ask your Domain Admins to create SPNs for SQL Server (or its service account) and the file server (both only if not already present). Then they have to configure ( allow ) Delegation from the SQL Server (or its Service account) to the file server (for example using “Active Directory Users and Computers”). This will allow SQL Server on the remote computer to communicate with a Domain Controller in order to request a service ticket (that is Kerberos speak) for the file server on behalf of you (or anyone else that is connected). That service ticket is then presented to the "SMB Server" service on the file server to check your file share and NTFS permissions.

PS: If you plan to execute the package with a SQL Server Agent job using the credentials of SQL Server Agent, you don't need all that delegation. Just set up the job, it can be started also from your remote SSMS session without any problem, provided that SQL Server Agent has the respective access to the file share.