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 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, March 06, 2005 2:35 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification Ok, let's review and recap to make sure we are on the same page: - Rick wants to authenticate extranet users as users in the ADAM store (requires simple bind) - Rick also wants to authenticate AD users in the internal forest The ADAM users require simple bind. AD users use either SASL bind with pass through auth or simple bind with userProxy objects. To authenticate AD users in either scenario, the ADAM server has to be a domain member in a domain that has a trust that will allow the authentication. ADAM can't be workgroup in this scenario. Rick can put ADAM in the internal DMZ and allow port 636 traffic from the external DMZ, so ADAM should be able to provide LDAP authN services to the server(s) in the outer DMZ. Also, Rick can get ADAM to DC traffic approved with ADAM in the internal DMZ. Therefore, it looks like the question comes down to whether he wants to use a mix of simple and SASL with pass through or do all simple bind, userProxy objects and bind redirection. The latter will require some sync to get the userProxy objects created. I'm not sure I know enough to know which one is the way to go, but it looks like either is possible at this point. Did I miss something? Joe K. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, March 06, 2005 11:50 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification > One other interesting tidbit - how does ADAM, as a non-member server, > now who to talk to? I'm hoping that I don't have to hard define a > particular DC. Is there a possibility that a call made references the > RootDSE, leaving the redundant capabilities of AD in place? Talk to for what? If it isn't a member, it don't give a hoot about any domains. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Sunday, March 06, 2005 11:38 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification Joe, Thanks for the feedback. This is pretty much what I had concluded, after doing some testing last night after this bugged me to the point that I couldn't go to bed. IPSec is an option, but I won't get it past InfoSec. They flat refuse to allow domain-direct communications to the DMZ (or from, more correctly). Let me elaborate for a minute: We have a three layer DMZ, our external (Public DMZ), the middle layer (Private DMZ), and the internal network. By policy, incoming communications can only communicate one layer at a time. So, in the solution that I've proposed - The Portal Web server sits in the Public DMZ and ADAM sits in the Private. Getting firewall and / or IPSec set up for 389 / 686 traffic is not an issue. Setting up traffic from ADAM to the internal, specifically DCs is not an issue (please - don't ask how that's different than a domain member sitting in the DMZ - I've suffered aneurysms trying to convince InfoSec that the difference is semantics). One other interesting tidbit - how does ADAM, as a non-member server, now who to talk to? I'm hoping that I don't have to hard define a particular DC. Is there a possibility that a call made references the RootDSE, leaving the redundant capabilities of AD in place? Thanks much! -rtk -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, March 06, 2005 10:18 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification You need domain membership for the SASL bind as well. Essentially, it is calling LogonUser under the hood to authenticate Windows users on the ADAM box, so users need rights to log on locally for bind redirection. Do you have an option for IPSEC or something to enable domain membership? Otherwise, I don't see how you are going to get any of the options to work. You would instead need duplicate synchronized accounts in ADAM with the internal AD users' passwords to make it work and then you are getting in password capture and stuff (icky). We use IPSEC to do domain membership in the DMZ and it works pretty well for us (although it is a bit of a PITA). Another thing I can think of is perhaps using LDAP bind (simple or SASL or both) over SSL/LDAP and putting ADAM inside the DMZ. Then, you poke a hole in the firewall for port 636 between these two IP addresses. Eric will probably weigh in this as well. Joe K. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, March 05, 2005 10:57 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] ADAM - Clarification All - We have a Web Portal solution that has the option to use LDAP v3 for AuthN calls. Obviously, we want to use AD for our internal customers, and implement user objects that would not reside in AD for our external customers. In my mind, this screams ADAM. I can create the user objects in ADAM for the external customers. And, I've read thoroughly the Tech Refs and some other words from Joe Kaplan on the subject. I also took a look at ~Eric's blog for a post or two, which were helpful. The problem - to the point - is this. The Portal web server, where the LDAP AuthN calls come from is in the external perimeter. There are four options that are indicated in the docs: # Anonymous bind (no password) # Simple LDAP bind (ADAM security principal with password) # SASL binding (Windows security principal in local computer or AD) # Bind redirection (security principal is in ADAM, but has a reference to an AD security principal) Bind redirection (userProxy) has a domain membership requirement for the machine on which ADAM resides. Given that the security requirements won't allow this, this one is out. However, I can't seem to find anything that indicates the requirements for SASL bind. Is this an option? The bottom line is that I want to use ADAM, but have run into this brick wall. What options do I have, as I've exhausted the resources that I have at my disposal, at this point in time at least :) Rick Kingslan MCSE, MCSA, MCT, CISSP Microsoft MVP: Windows Server / Directory Services Windows Server / Rights Management Windows Security (Affiliate) Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone WebLog - www.msmvps.com/willhack4food 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/ 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/
