![sql server connection string ssis sql server connection string ssis](https://i.stack.imgur.com/pra3l.png)
I advise people to do the expression stuff in SSIS variables and assign them in properties so instead of seeing "1SecretPassword!", in my packages you would see which has the password in clear text. If I have an expression on the Password and the expression is the string "1SecretPassword!" don't save sensitive can't wipe the password out because it's an expression, not a stored value. So, the advice back in the day was Don' Save Sensitive and use some other means of populating sensitive values. Encrypt all or sensitive with password is overkill for a single user and a shared secret among all the developers is no secret at all. Hard to unlock something when you're a ghost.
![sql server connection string ssis sql server connection string ssis](https://i0.wp.com/www.fmsinc.com/microsoftaccess/SQLServerUpsizing/importing/SSMS.jpg)
Which is great until that person leaves the organization and the AD account is removed. That is, the author of the package's Active Directory bits are used to transparently encrypt data.
![sql server connection string ssis sql server connection string ssis](https://s33046.pcdn.co/wp-content/uploads/2019/10/this-image-shows-the-ole-db-providers-list-found-i.png)
You can encrypt all or sensitive data with user key. There are challenges with Package Protection Levels other than DontSaveSensitive. You might enter the password, click validate connection and it's good but as soon as you save, it's wiped out and when you re-open, connections are broken because the password is incorrect (blank) The Package protection level matters here as a setting of DontSaveSensitive will remove any sensitive data, like a password, when you save the package.