Sorry for just weighing in on this thread now, this weekend has been crazy busy with things related to my upcoming move.
I can take some of the credit/blame (you decide :)) for our guidance on ADAM generally, as I've been involved in the docs out there. There are two major reasons we don't recommend bind proxy: 1) It requires a simple bind, so in the absence of LDAPS (which is required by default, but some people disable this) your creds are flying naked over the wire. Some other bind types give you security in the absence of LDAPS, which is nice. 2) Bind proxy requires more mgmt overhead - you need to keep proxy objects around, and up to date. If you create a new user, you need to create a new proxy. If you migrate a user you need to recreate the proxy (sidHistory buys you time). If you delete a proxy you should delete a proxy (though I guess you don't have to if you don't mind the cruft). In the DMZ, you could sync your AD users out, or have enough connectivity such that the ADAM box can talk to a DC in the domain in question if you're going to use proxy bind. ADAM uses LogonUser() to auth the user in the proxy scenario, so take that for what it is worth. If you're not going to open anything from the DMZ to the internal (or not enough for a domain member) then proxy bind is off of the table. In that case you have some options which include: 1) You could sync your internal AD users to the extranet (in to an AD environment or ADAM that is out there). This requires password sync, which may or may not be ideal for you. 2) You could just have LDAPS open from the extranet in, and then have your users in the internal AD environment just get auth'd over that, and your extranet users (the ones in ADAM) just be a local bind against that ADAM instance, with the logic of deciding where being in your extranet app. By no means a complete list of options, just a few thoughts that sound like they are along the lines of what you're thinking about. I see mention earlier in the thread of using a workgroup machine out there (SAM db) and syncing crud out. I'm not sure I'm a fan of this, but am open to a compelling argument if someone has one. I don't see the benefit of this vs. just setting up an extranet domain that has no relationship to the intranet domain. If nothing else, the extranet domain can be just as hardened as the workgroup extranet scenario, and you have other options (policy, auth between extranet boxes, no user scalability issue as it is AD and not the local SAM db crud, etc.). And you have the same user sync out to the extranet problem either way. My $0.02 If you have specific questions just holler. ~Eric -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Sunday, March 06, 2005 8:55 PM To: [email protected] Subject: RE: [ActiveDir] ADAM - Clarification 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: [email protected] 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: [email protected] 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: [email protected] 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: [email protected] 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: [email protected] 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/ 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/
