Web/IIS Server on Internal Domain?

Topic

New Reply

The company I work for is set up with 2 subnets.
One is a DMZ that is made up of static IP addresses that have to be mapped to an external IP address in the firewall to have internet access that includes connecting to it externally.
This includes our Exchange server.

The other is our internal domain subnet with a small DHCP range and most equipment on static IP, including IP Phones. It includes our DC, file servers and SQL server. This subnet has outgoing access to the internet but cannot be accessed outside of the company.

Our web/iis server is currently in a workgroup and it is outward facing on the DMZ.
On that server we have our “intranet” interface that allows employees to login anywhere and report time/expenses/etc and supply needed information to our database. This means that the web server needs to access the SQL server, which is NOT on the domain as yet.

Our goal is to sync the web login with the employee’s domain login/email and make it easier to manage users. This would require joining the web/iis server to the domain.

Can someone please give me some insight as to the pros and cons of doing this? Any help would be greatly appreciated.

Rick

Reply | Quote

Replies

An amendment to this post. We will NOT be syncing the user logins with their email accounts. These will continue to be 2 separate logins and passwords.

Reply | Quote

I think you need ADLS on the web server.
You have experience with ADLS on your exchange server.

cheers, Paul

Reply | Quote

I think you need ADLS on the web server.

Paul,
Upon reading this link I noticed it was for apps that need a directory based authentication. Our logins on the Web Server are only stored in a linked SQL database. Would I still need to install ADLS? Also, I was looking specifically for input regarding security comparison between keeping it on a workgroup vs adding it to the domain.

Once again, thanks for your help.

Rick

Reply | Quote

Makes more sense now.
There is no need to join it to the domain as the details are just SQL records.
How do you envisage syncing the user details? You could allow a machine on your domain to send SQL requests to the SQL server, then you don’t need to allow the DMZ machine to contact your domain.

cheers, Paul

Reply | Quote

Makes more sense now.
There is no need to join it to the domain as the details are just SQL records.
How do you envisage syncing the user details? You could allow a machine on your domain to send SQL requests to the SQL server, then you don’t need to allow the DMZ machine to contact your domain.

cheers, Paul

Paul,
The web server currently contacts the SQL server to authenticate logins on our “Intranet” located on the web server. This is an interface for entering time worked, expenses, patient treatment data, etc. All of this is stored in the SQL server. My director only asked the question of how joining to the domain will effect the security of the web server and the domain. Any thoughts on that? I’m getting some answers from other forums I found in a search that say you have to decide if ease of management or security is more important. However there are ways to enhance security after joining to the domain. My concern is if we maintain the SQL as the authentication source for the login, will that really effect security since the only account on the server that would be effected would be the administrator.

Thanks,

Rick

Reply | Quote

Make sure your SQL users have only just enough rights to do what is required – stored procedures limit the possibilities even further. You don’t want a compromised web server to perform a SQL injection attack – I’ve seen databases dropped by injection attacks.

cheers, Paul

Reply | Quote

Maintain the SQL server as a stand-alone unit. If it is ever compromised you just re-build from backup instead of worrying if the domain is now compromised.

Having servers in the DMZ really means you want them separate from your primary network and security is easiest if they remain that way.
You should also have very limited connection between machines in the DMZ because you don’t want a compromised server to affect other DMZ machines.

Allowing RDP from the main network to the DMZ provides easy management. Files can be transferred using an FTP server on the main network.
The SQL server can perform its own backup and then FTP the files to you.

cheers, Paul

Reply | Quote

That’s really good information. Thank you Paul.

Reply | Quote