Connecting to DB with the 'machine' account
-
This seems like a bad idea, but I'm having trouble identifying why. With an ASP.NET application I am using Windows Integrated Authentication. The aspnet_wp.exe runs as 'machine' per the processModel element in machine.config. By creating a domain\machine$ user in the database, I can successfully connect to the database. So in my case the domain is flintstone and the web server is fred. By adding the flintstone\fred$ user to the database, any .net process running on the web server can connect to the database. It seems like I'm opening the database up for malicous attacks from a rogue process on the web server. By moving from integrated security in the connection string to an explicit user/pwd I appear to have more control over what processes can access the database. What are your thoughts about this? It's good to be alive, Josef Wainz Programmer Analyst
-
This seems like a bad idea, but I'm having trouble identifying why. With an ASP.NET application I am using Windows Integrated Authentication. The aspnet_wp.exe runs as 'machine' per the processModel element in machine.config. By creating a domain\machine$ user in the database, I can successfully connect to the database. So in my case the domain is flintstone and the web server is fred. By adding the flintstone\fred$ user to the database, any .net process running on the web server can connect to the database. It seems like I'm opening the database up for malicous attacks from a rogue process on the web server. By moving from integrated security in the connection string to an explicit user/pwd I appear to have more control over what processes can access the database. What are your thoughts about this? It's good to be alive, Josef Wainz Programmer Analyst
Turtle Hand wrote: What are your thoughts about this? Integrated Security is better because you don't have the chance of the user name and password being discovered. If you connect to the DB with a username/password combination a rogue web application could still trash your DB through the web application. You can read my article on SQL Injection Attacks and Tips on How to Prevent Them[^] to see how. Turtle Hand wrote: By creating a domain\machine$ user in the database, I can successfully connect to the database. That doesn't sound right to me. It should be "machine\user" or "domain\user" (the former is prefered because then the account is local only to the machine). Turtle Hand wrote: any .net process running on the web server can connect to the database Only .NET processes running in the security context of the user that you've granted permission to in the database can access the database. Reduce your risk by granting access to limited accounts that cannot do much.
My: Blog | Photos WDevs.com - Open Source Code Hosting, Blogs, FTP, Mail and More
-
Turtle Hand wrote: What are your thoughts about this? Integrated Security is better because you don't have the chance of the user name and password being discovered. If you connect to the DB with a username/password combination a rogue web application could still trash your DB through the web application. You can read my article on SQL Injection Attacks and Tips on How to Prevent Them[^] to see how. Turtle Hand wrote: By creating a domain\machine$ user in the database, I can successfully connect to the database. That doesn't sound right to me. It should be "machine\user" or "domain\user" (the former is prefered because then the account is local only to the machine). Turtle Hand wrote: any .net process running on the web server can connect to the database Only .NET processes running in the security context of the user that you've granted permission to in the database can access the database. Reduce your risk by granting access to limited accounts that cannot do much.
My: Blog | Photos WDevs.com - Open Source Code Hosting, Blogs, FTP, Mail and More
Colin Angus Mackay wrote: That doesn't sound right to me. It should be "machine\user" or "domain\user" (the former is prefered because then the account is local only to the machine). The user's credentials passed from the browser make it to the web server, but can't get passed to the database server, there is a one hop limit when passing credentials. So when connecting, then, from the web server to the database server, the credentials from the aspnet process are used instead. Because 'machine' is specified in the machine.config processModel element, domain\machine$ is sent to the database server. If identity impersonate="true" is placed in the web.config file, aspnet pretends it is running as the user. But authentication on the db server fails because 'null' is passed instead of the user's. 'null is passed because of the one hop limit. If the web server and db server are the same server, then the one hop limit is satisfied and you can use identity impersonate="true" successfully. This however goes against MS recommendations when architecting a web app.