ssis handling of oracle and teradata passwords RRS feed

  • Question

  • Hi,

        This has gotten so bad I have to ask if there is a newer feature in ssis (like maybe vs 2017) that handles oracle and teradata passwords.   We work in a secure organization.  They don't want us leaving passwords in the packages for security reasons (I understand that ssis encrypts passwords it knows are passwords in the .dtsx file) so we have to clear them when development is done.  We also use what might be called a password vault for oracle and teradata passwords for our run time jobs which makes the transition from client development to batch job difficult.    Can anyone tell me why it would ever be useful for ssis to attempt a login to Oracle or Teradata when ssis knows the password it has is null or blanks?  A more paranoid part of me might think that Microsoft, with Windows Auth, is trying to drive their users off of Oracle or Teradata.  So is there some ssis job level parameter I can set that instructs ssis not to attempt an oracle or teradata access for metadata unless it has a password?   Some of our jobs access oracle or teradata in 5 or 10 different places, running in there to set Work Offline for each one of those accesses is difficult.  And I don't want to be told to set Oracle and Teradata to use Windows Auth (if that's even possible).   I don't control that and I need something that I, as an etl developer, control.   I can't believe SSIS competes with products like Datastage with the situation concerning Oracle and Teradata passwords being so bad.

    Monday, September 21, 2020 11:36 PM

All replies

  • Hi etlman,
    You question is mostly related to SQL Server Integration Services, I suggest you ask the question in SQL Server forum for more professional answer.
    Thank you for your understanding.
    Best Regards,
    Daniel Zhang

    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Tuesday, September 22, 2020 5:21 AM