I think that pretty much covers it. Given the option, I'll likely go with the SASL, as the MS docs don't recommend the proxy. I'll dig into why, but I suspect that it might have to do with issues of security. However, LDAP/SSL is the default, and one would have to change a couple of settings to turn it off.
My challenge in the next couple of days is putting together the presentation to our InfoSec group to show them that having a hardened member server in the DMZ is not a sign of the Apocalypse. There are a number of things that we need to do with it (like, Ironmail confirming that, yes - rtkingslan does exist in the AD and making Spam decisions based on user existence) and putting the brakes on this is not a forward thinking decision. IPSec, SSL, firewalls - these were all devised with these types of situations in mind. What I may end up doing, as joe rightly does conclude, a domain in the DMZ might not be a bad idea either. I could use 1-way synch to this domain, and then further isolate the information to ADAM for the Portal and Ironmail. So, I think that what I needed to get out of this conversation was accomplished. Thanks for JoeK, joe, and Al for the input. -rtk -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, March 06, 2005 1: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/
