README for configuring the LDAPUserFolder product for M$ Active Directory

  Micro$oft offers two products that purport to speak LDAP, namely
  "Active Directory" and, to a lesser extent, the Exchange server.

  Just like with all other products their claim to standards-compliance
  does not hold much water. The number of users asking for advice on 
  getting the LDAPUserFolder to work with these directory servers speaks
  volumes.

  My development and testing environment does not contain any Micro$oft
  software, I have no testbed to run their products, and I do not intend
  to go out and change that.
  
  As a service to those unfortunate souls who, for whatever reason, are stuck
  with these sub-par LDAP implementations I am using this file to collect
  advice from users who have been successful. I cannot vouch that any of this
  will work for all M$ users and have no way of verifying. Please treat 
  this information with that in mind.


  In May 2003, Philipp Kutter wrote:

  """
  Problem: connect existing ADS installation of client with your Zope 
  application. ADS users should be used for authentication.
  
  You know: Administrator passwd on the Windows 2000 Server ADS machine, 
  the IP of the ADS. (May work for XP as well.)
  
  Next thing you need is a tree with the full DN-strings of groups and 
  users. The least-cost solution getting them is installing the W2000 Server 
  Support tools, and running the LDAP Administration Tool, called ldp.exe 
  This tool gives you the strings. Typically your Administrator user will be 
  represented as...
  
  CN=Administrator,CN=Users,DC=clientdomain,DC=com
  
  The tricky point is now, that your ldp.exe did accept you to authenticate 
  with the ADS entering "Administrator" as user/ManagerDN and your password 
  as password.  Under LDAPuserfolder and linux LDAP browser such as gq, this 
  does not work. Your Manager DN must be the full string representing the 
  Manager:
  
  CN=Administrator,CN=Users,DC=clientdomain,DC=com
  
  The complete working settings in my case where:
  
  Users Base DN:            CN=Users,DC=cliendomain,DC=com
  Scope:                    SUBTREE
  Group storage:            Groups stored on LDAP server 
  Groups Base DN:           CN=Users,DC=cliendomain,DC=com
  Scope:                    SUBTREE
  Manager DN:               CN=Administrator,CN=Users,DC=cliendomain,DC=com
  Manager DN Usage:         Always
  Read-only:                checked
  User object classes:      top,person
  User password encryption: SHA
  Default User Roles:       Anonymous
  """

  The item that tripped me up when I did some experimenting with AD was the 
  fact that the "Users" container is not a OrganizationalUnit-type container.
  Notice the "cn" as the relative distinguished name element.

  For all those people who still cannot get it to work, Larry Prikockis did
  some great detective work and found something very interesting. Apparently
  AD will serve "unmolested" data from a secondary port which is much more
  standards-compliant than the garbage AD pushes out of the standard LDAP
  port. Here is what he had to say:

  """
  after banging my head against this particular problem for a while, I
  finally stumbled across a solution!
  Apparently, Microsoft AD can be queried via LDAP in two different ways--
  port 389 is your standard LDAP port... and then there's port 3268, which is
  something Microsoft calls the "Global Catalog". For reasons I don't
  really understand (yet, anyhow), if you do an LDAP query against port 389,
  in addition to your results, you end up getting a referral that chokes
  LDAPUserFolder (I think it's a case of M$ playing fast and loose with the
  LDAP standard and issuing some sort of badly formed referral that either
  LDAPUserFolder or the underlying libraries, or both, don't know what to do
  with).

  HOWEVER-- if you issue the same LDAP query against the server at port 3268
  (the "global catalog"), you get a nice, clean result back.

  I've tried this with my servers using LDAPUserFolder and AD and it works
  perfectly!

  For further details, here's a link to the discussion that I stumbled across
  on the web explaining all this:
  http://www.mail-archive.com/activedir@mail.activedir.org/msg03887.html
  """

  "Fast and loose" with the LDAP standard - I think I could not have put it
  any better myself.


