Help with Perplexing Questions re Domains

Hello,

I have been struggling with a network design issue that I am hoping some of the experts here can help me solve. My questions have to do with how to set up domains, domain controllers, etc. in the following situation involving two servers and a LAN:

Server #1: File server running SBS 2003. This acts as its own domain controller for itself and a small LAN of 5 computers.

Server #2: Is a new web server that is running Server 2008 Standard Edition. This web server is running a custom .NET application and a SQL 2005 database. This server is replacing an old W2K machine. It is new and is only partially set-up. It is currently configured as a member of a workgroup but would preferably join a domain and use Active Directory. We would like to use Windows authentication on this server.

Both servers sit behind a (Juniper) NetScreen firewall that has two zones (one for the web server and one for the file server/LAN). All traffic from the web server to the file server is blocked by a firewall policy.

I am struggling with how to set up the new 2008 server. Below are some ideas that we have bounced around internally and with Dell's and Juniper's tech support. I could really use some guidance here.

Option #1: Leave SBS server as is and configure the Server 2008 with the Read Only Domain Controller. Dell is concerned that if somehow SBS sniffs out this other DC that it will start shutting down services and create a major headache for me. Others have said that for 2008 ROD to work I need at least another 2008 server acting as a DC. If this is true, this option is out.

Option #2: Punch a hole in my firewall so the web server can join the SBS 2003 domain. The concern is that we are making my file server and entire network vulnerable. We also do not know what is the smallest hole that is needed (what ports/services must be open).

Option #3: Leave SBS server as is and run the web server in a workgroup. This is how my current W2K web server is configured. Dell is concerned that a workgroup configuration gives little protection to a web server. Is this true? This seems like it would be the easiest, but how safe would my web server be?

Option #4: Get rid of the two zones (DMZ) and put the web server on the same subnet as the file server. I really do not like this idea, but wanted to mention it.

Option #5: Keep the new 2008 server on its own subnet (separated from the LAN by the firewall). Set it up to be its own Domain Controller. I do not forsee any need to network another computer directly to this web server.

Please let me know if you have any questions. Someone please help me figure this out!!!

 

My preference would be for option 3, unless there is a compelling reason for users of the .Net web app to authenticate against the internal domain. If there is a compelling reason, I'd use option 2.

There is no prefect answer to security (perhaps disconnecting the server from the network completely and walling up the room it lives in ). Domain security provides advantages such as it being easier to manage, but has its own disadvantages - it is done via the network connection for example. Therefore, I would not say that domain is an inherently more secure authentication system than workgroup for securing a single computer, but that the vulnerabilities are different.

Do the obvious things like keep the server patched and up to date, replace the Administrator account with an account with the same privileges but different name. Use very secure passwords. Personally, I'd not use windows authentication in the web app unless I had to. Manage users in the service environment and isolate them from the OS. I'd also install AV and a small firewall app.

If I had to use option 2, I'd dual host the server (add a second network card - NIC). Use one NIC for external traffic and one NIC for internal traffic). I'd have the external NIC on a different subnet to the internal one. Then set up firewall rules that :

• allow incoming network traffic from the internet to the .Net server only to the external NIC address and only on the ports the .Net service listens on (80 for example).
• allow authentication traffic only from the DMZ to the SBS server and only from IP address of the internal NIC on the server.
• allow access to the .Net service from the internal SBS network if necessary.
• Block all other DMZ traffic.

That would mean there is not a single path from the internet in to your SBS network via the DMZ. Anyone trying to get in would first have to compromise and control the server before they could access the inner connection.

I'd also look to see if the .Net server actually needs to be a member of the domain. If it only needs to check users' credentials you could just use LDAP. That's a single service, a single port and therefore a simpler security problem. A web service can check user credential via LDAP without being a member of the domain.

 

Reggie,

Thank you for such great feedback. After talking this through with Dell Enterprise Support and my developer last night, we came to similar conclusions that you did. We are strongly leaning towards Option 2.

My preference would be for option 3, unless there is a compelling reason for users of the .Net web app to authenticate against the internal domain. If there is a compelling reason, I'd use option 2.... I'd also look to see if the .Net server actually needs to be a member of the domain. If it only needs to check users' credentials you could just use LDAP. That's a single service, a single port and therefore a simpler security problem. A web service can check user credential via LDAP without being a member of the domain. Reggie, my developer said that with SQL Server and the .NET app that we would be much better off with a domain set-up and windows authentication. I will ask him if LDAP would be sufficient. Dell was saying that I should open up DNS, LDAP, and Kerberos. If I could get by with just LDAP, all the better!

Would you mind explaining how the .NET server can be autheticated with LDAP if it does not belong to the domain? Would I leave the .NET server in a workgroup? If so, how do I set up the LDAP authentication?

Do the obvious things like keep the server patched and up to date, replace the Administrator account with an account with the same privileges but different name. Use very secure passwords. Personally, I'd not use windows authentication in the web app unless I had to. Manage users in the service environment and isolate them from the OS. I'd also install AV and a small firewall app. I agree with the patching. Can I literally delete the Adminstrator account (after I create another with the same privaleges)? I seem to recall in W2K that I could only disable this account, but not delete it. This may sound easy, but exactly how do I do this? Is it a good idea to do this on the 2003 SBS server as well? Or does SBS require an Adminstrator account?

If I had to use option 2, I'd dual host the server (add a second network card - NIC). Use one NIC for external traffic and one NIC for internal traffic). I'd have the external NIC on a different subnet to the internal one. Then set up firewall rules that ... This is exactly what we decided to do late last night. I think I can work with Juniper to get the right policies in place.

Reggie, I am going to look into this some more and may have a few follow-up questions besides the one about LDAP.

Thanks!
Chip

 

If you go on the MS SQL training courses they describe a model where individual users directly access the database. That's fine in certain circumstances (for example where you have a large IT support team), but it isn't the best model for a web application. With a web app there is no need to let users anywhere near your database. They should only access data via the web application. Therefore, what you need to provide is the web application access to the database and not individual users (other than admins). In this model that means one or two local windows users with admin rights to the database and a SQL user defined and used by the web application and only the web application. This SQL user is authenticated by SQL and is limited so it can only access the tables it needs to access.

Sorry, I played with .Net and didn't like it. So rather than going the usual ASP to ASP.Net route, I went ASP to PHP to Ruby. With ASP/VB/VBScript you can access LDAP resources via GetObject.

This is a bit of VBScript that uses GetObject to return an LDAP object containing user information and then steps through it looking for a particular user and pulling their e-mail address out. The LDAP object is a AD OU, with users grouped in a number of daughter OUs.

Code:

UserName =  "Joe Bloggs "

Set objLDAP = GetObject( "LDAP://server.domain.local/ou=users,dc=domain,dc=local ")

For Each objSubOU In objLDAP 
	'Step through each object
	For Each objUser In objSubOU
	      'Test to see if object is a user or a contact (only process users)
		If objUser.UserAccountControl > 1 Then 
			'Test is the current user is the searched for user
			If CStr(objUser.cn) = UserName Then UserEmail = CStr(objUser.mail)
		End If
      Next
Next

However, .Net has moved on since I wrote this. I'm not up to date on the latest .Net methods, but have a look at this Microsoft article on using LDAP to authenticate with ASP.Net 1.1

 

Actually, renaming Administrator is a better option. Sorry to confuse matters there.

I'd say it is a judgement call.

On a new system it is something I'd recommend doing as part of the initial set up. At that point it is easy to do. With an existing system things are more problematic (though not insurmountable), in particular with reconfiguring services that use the Administrator account credentials.

On a system that is new (so the process is easy) or directly exposed to the internet (where you need all the security you can get) then I would consider the hassle involved is worth the gain in security.

On an existing system that is well secured behind a firewall and doesn't directly offer services to the internet, I think I'd probably compromise and give it a miss. Especially on something like SBS where the server is running a lot of inter-connected services.

But as I said, a judgement call. If the SBS server was allowing direct internet access to services like Outlook Web Access and/or Sharepoint services, I'd book a weekend in the office, site myself down with a large supply of coffee and bite the bullet. If all it was doing was accepting mail on port 25, I wouldn't bother.