I don't have a problem with AD in the DMZ, I just wouldn't let it be connected to my internal AD either via trusts or the truly uncool idea of putting an internal AD DC in the DMZ.
The idea of using the local SAM ID's is if you want secure auth but don't want to use the required SSL for AD/AM user auth and you don't want to set up an AD. You sync your users from internal AD, the ones you need out on the extranet, not necessarily all of them to the local machine's SAM database. Then you can use a secure bind to connect to ADAM using those local Windows users. Of course if you go so far as to put up AD in the DMZ, do you need AD/AM? Maybe, depends on what else you are intending to do. If you are putting in app specific data, I would recommend AD/AM over AD and just have the auth bump over to AD. Of course others would say use an app partition, I don't like app partitions in AD. I am old fashioned but I see AD as my NOS auth store, I want everything else to get away from it because I consider auth more important than everything else. I constantly have fights with Exchange folks who consider the directory as theirs. It used to be theirs, now it is mine, stop abusing it before I slap you and you need to get that crap out, at least the config container stuff. I recall once a long while back before AD/AM was announced to anyone I knew or at least anyone willing to talk to me about it and I was talking to some MS Dev person who was trying to tell me how cool app partions in the up and coming Windows .NET would be and would I use them personally or as part of the enterprise I managed or would I recommend their use. I was like, I don't like the idea at all, why don't you guys just get over it and build a standalone LDAP server app; you have everything you need already. Why try to make AD the end all be all. I didn't believe it would ever happen the first time I heard about that plan, didn't believe it when I was talking with this guy about App partitions, and don't seem to be alone in believing in it now hence the push on MIIS. Sure it is possible to pull it off in the small companies and even medium ones that are all strictly MS with few directory aware apps. Once you get into the larger companies, the mere thought of one directory for everything sounds pretty funny. That old adage of you can't be everything for everyone comes in hard in that realm. I really wasn't and am not still a fan of app partitions. You want to put some cool things into AD, give me caching DCs (no not BDCs) and give me multiple domain hosting from a single DC. I can get along fine if the requirement for the multiple domains is XP SPx or better. I don't want to hear the excuse of well what about legacy clients. My response is, if someone sets up the multiple domain hosting, damn their legacy clients. Back to the topic, I am not even sure if I would sync the internal AD to the DMZ AD or AD/AM in Rick's case. I think there is something that can be said for a company that has users have different passwords for external access into the company versus internal access. Obviously I don't know all of the particulars and in Rick's shoes may think that having the users use that one password in both places is exactly what is needed. But if that were the case, I would also probably require a second form of auth as well, such as a securid token. I guess I am funny about extranet stuff, I don't trust it at all. I always assume the worst about it and am extremely paranoid about it. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, March 06, 2005 5:05 PM To: [email protected] Subject: RE: [ActiveDir] ADAM - Clarification The DMZ AD sounds like a good way to go for me too. Our security guys are pretty terrified of AD in the DMZ (we use IPSEC to deal with this), but it seems like it would save a lot of hassle. I don't personally deal with IPSEC, but it seems to have a "suck factor" reputation with the people here who do. I don't think I follow the users in the local SAM database thing you are talking about here. Where would that fall in with Rick's scenario? Would those be for the internal users or the external? Joe K. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, March 06, 2005 2:25 PM To: [email protected] Subject: RE: [ActiveDir] ADAM - Clarification Good restate. I think that captures it all. The key being that the ADAM server must be a member of the internal domain. If it isn't, all users need to go into some store (whether local, ADAM, or spinning up AD in DMZ) in the DMZ. Personally, I am not a fan of hooking anything outside the LAN/WAN to an internal AD so for me. I would look at populating the needed info out to the DMZ either in an AD sitting in the DMZ specifically for that purpose or into ADAM itself - don't forget to use SSL so you don't pass clear text passwords. If the number of users was under 50-60k or maybe evey 80k I would consider pushing the user auth into the local SAM of the server. If using a DMZ AD or the local SAM then you can use secure binding without invoking SSL overhead. Considering the fact that you may want to add additional AD/AM servers at a later point for redundancy makes me think a DMZ AD may be the way to go unless you want to use SSL and AD/AM users. joe This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
