See, I always get into trouble when I'm cynical. I didn't even look in the larger .EXE file.
-gil -----Original Message----- From: Fugleberg, David A [mailto:david.fugleberg@;nwa.com] Sent: Thursday, October 24, 2002 1:14 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] LDAP referral during subtree search Gil - It's that 'negative compression' feature... Actually, the compressed version includes some other goodies, including a powerpoint presentation, some sample vbs code, and such. After Tony jarred my memory, I went out looking on my hard disk and found that I had downloaded the doc some time ago to figure something else out. It's a good resource. Thanks for reminding me, Tony ! Dave -----Original Message----- From: Gil Kirkpatrick [mailto:gilk@;netpro.com] Sent: Thursday, October 24, 2002 2:17 PM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] LDAP referral during subtree search Did anyone notice that the uldap.doc file on this page is 706Kb, and the "compressed Word document", packaged as a self-extracting .EXE for download is 882Kb? Just thought I'd point that out. -gil -----Original Message----- From: Tony Murray [mailto:tony@;mail.activedir.org] Sent: Thursday, October 24, 2002 8:33 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] LDAP referral during subtree search Dave If you want an in-depth view on Active Directory LDAP support, see this whitepaper from Dan Thompson. http://www.microsoft.com/windows2000/techinfo/howitworks/activedirectory/lda p.asp It explains the whole area of LDAP referrals very clearly (well, as clear as anything can be with LDAP). Tony ---------- Original Message ---------------------------------- From: "Fugleberg, David A" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Date: Wed, 23 Oct 2002 15:25:09 -0500 It's running on Solaris. I don't know what LDAP libraries they use. Dave -----Original Message----- From: Gil Kirkpatrick [mailto:gilk@;netpro.com] Sent: Wednesday, October 23, 2002 11:10 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] LDAP referral during subtree search David, Glad to help... Is the app server running on W2K or some Unix variant? If its running on W2K, I'd be amazed if they were using their own LDAP client instead of the MSFT-supplied client. You could check to see if the server loads the WLDAP32.DLL. -g -----Original Message----- From: Fugleberg, David A [mailto:david.fugleberg@;nwa.com] Sent: Wednesday, October 23, 2002 7:13 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] LDAP referral during subtree search I'm curious too. The app server is WebLogic 7.0, configured to use AD/LDAP as the authentication provider. When the search base is the Users container, it binds to AD (using an account created for that purpose), searches for the user, and binds as that user with the credentials the user supplied. If the bind is successful, it then rebinds with its own account and searches for groups which contain the user in the members attribute. It then recursively searches to find any groups that group might be nested under. WebLogic can then use that information to make access control decisions (i.e., only members of groupABC can access a particular URL). The group info is also mapped to 'roles' which can be referenced within applications for finer grained control (i.e., if user is in RoleA, enable this option programmatically). When the search base is DC=xyz,DC=com, the network trace shows that it does all the same queries, and gets all the expected results, but it denies access to the URL even though the user is part of the requisite group. The only difference I see is that referral, so I surmise that's what is confusing WebLogic. I don't see WebLogic attempting to chase the referral, nor does it seem to have any option to turn referral chasing on or off. I suspect that its LDAP client implementation is simply not very robust and is not equipped to handle exceptions gracefully. We've been using their LDAP support since version 6.1, and it has been steadily improving, but it has room to grow. Everything works OK if I do the same thing on port 3268, though, so I think that's where we'll go, at least for now. Thanks for your insight - very helpful, as always :) Dave -----Original Message----- From: Gil Kirkpatrick [mailto:gilk@;netpro.com] Sent: Tuesday, October 22, 2002 6:28 PM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] LDAP referral during subtree search David, Yeah, if the app servers are just searching for a CN that might be anywhere in the forest, searching the GC is the better strategy. I'm curious as to why the app was choking on the referral... -g -----Original Message----- From: Fugleberg, David A [mailto:david.fugleberg@;nwa.com] Sent: Tuesday, October 22, 2002 3:59 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] LDAP referral during subtree search Thanks Gil - I knew you would know <g> Am I correct in assuming that it's an all-around better practice to point those app servers at the GC (port 3268) anyhow ? Right now, the only issue is that the app server seems to choke on the referral, but in the future if I should add a domain to the forest, I imagine I'd want to go to the GC anyhow so I wouldn't need to be concerned about which domain the user was in. I should point out that we use a unique ID for user CNs, so there's no issue of duplicate RDNs to be concerned with... Dave -----Original Message----- From: Gil Kirkpatrick [mailto:gilk@;netpro.com] Sent: Tuesday, October 22, 2002 5:46 PM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] LDAP referral during subtree search David, Not quite correct... >From a logical perspective, your tree has a root NC (DC=XYZ,DC=com) and >that NC contains a subordinate config NC (CN=Configuration,DC=XYZ,DC=com), which itself contains a subordinate schema NC (CN=Schema,CN=Configuration,DC=XYZ,DC=com). When you search the root domain, and you don't use the LDAP_SERVER_DOMAIN_SCOPE_OID (1.2.840.113556.1.4.1339) control, AD generates referrals to the subordinate NCs that were included in the scope of your search so that you can chase the referrals appropriately *even though there is a replica of that NC on the DC you are searching*. In your case, you get the referral to the only NC subordinate to the root: CN=Configuration. The GC is effectively a separate NC that includes the entire scope of the forest, so there are no subordinate referrals to be had. -gil -----Original Message----- From: Fugleberg, David A [mailto:david.fugleberg@;nwa.com] Sent: Tuesday, October 22, 2002 3:27 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] LDAP referral during subtree search I noticed something while doing LDAP searches against AD that I'd like to understand. Take the example of a single-domain forest called xyz.com. User objects are stored in various OUs, and the OUs exist directly under the domain (OU=orgunit1,DC=xyz,DC=com, OU=orgunit2,DC=xyz,DC=com, etc.) Let's say you want to look for a user object with CN=joeuser, and it might be anywhere in the OU structure. You try two different methods: 1. Bind to a Domain Controller on port 389. Issue a subtree search with a base DN of DC=xyz,DC=com and a filter of (&(cn=joeuser)(objectclass=user)). 2. Bind to a Global Catalog server on port 3268. Issue a subtree search with a base DN of DC=xyz,DC=com and a filter of (&(cn=joeuser)(objectclass=user)). If you do option 1, joeuser is found, and his full DN is returned. The DC also returns an LDAP referral to ldap://xyz.com/CN=Configuration,Dc=xyz,DC=com. If you do option 2, you still get the DN you wanted but no referral is returned. I'm thinking that this is because in option 1, the DC doesn't know whether a user with CN=joeuser exists in some other domain so it refers you to the configuration container which should know about other partitions. The GC, on the other hand, has full knowledge of the forest so does not need to return a referral. Am I on the right track here ? Is there more to it than that ? The reason I care is that we have some Java application servers that currently authenticate against our single-domain AD forest via LDAP. At first, all the relevant users were in the Users container, and the app server was configured like option 1 (using port 389 on a DC) with the search base at the CN=users level. That worked fine. Now we have users in other OUs not under the Users container, and they obviously are never found. The app server seems to choke when I make the search base DC=xyz,DC=com, but if I use Option 2 (against the GC on 3268) it's happy. The only difference I see is the absence of that referral. I think the right thing to do is go ahead and point them at the GC anyhow, but I just wondered if I'm understanding this correctly. Comments ? Dave List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
