Timeline for Securing usernames and passwords for external SQL DB
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 15, 2011 at 13:36 | comment | added | SPDoctor | No, you would create a group mapping and add your users, possibly through an "all authenticated users" group or something more restrictive. To elaborate on app pool identity, some DBAs might not trust this - depends how important your custom database is - perhaps more sensitive than your content db. In the case of RevertToSelf it is actually the identity of the BCS service, which is presumably different from the app pool identity. | |
| Apr 15, 2011 at 11:40 | comment | added | Benjamin J Athawes | I suppose the complexity is that I want all users with access to view a Web part to be able to view the back end data without having to give the users access to the DB. Would I allow the App pool identity access to use the SSS credentials in this scenario? | |
| Apr 15, 2011 at 10:45 | comment | added | Anders Rask | In SSS you can store the whole connection string (or any other string). Theres no demand to use login/pwd | |
| Apr 15, 2011 at 10:25 | comment | added | SPDoctor | Secure Store credentials can be Windows or SQL, or anything else for that matter. You need to consider carefully the implications of giving your app pool identity access rights to your database, if you go the trusted subsystem route. | |
| Apr 15, 2011 at 8:31 | comment | added | Benjamin J Athawes | I suppose I'm wondering if we should be storing credentials at all. We have used SQL auth in the past but I'd like to move to Windows on the understanding that it is more secure. In this scenario the trusted subsystem model (described above) seems like the way to go. | |
| Apr 15, 2011 at 8:22 | history | answered | SPDoctor | CC BY-SA 3.0 |