Home → Questions →

LDAP Catalog cannot be setup properly

• Edit

pberkowitz

03 Feb, 2014 09:37 PM

I have setup LDAP to many similar systems without much trouble. For some reason, I cannot get this to work with my server. I am using active directory on windows 2008. The log file is not really helping me narrow the problem.

Here is a sample of my error:

13:22:00.0263 - Warn - - HgLab.Core.Framework.Security.LdapAuthenticationModule - could not find user by identitySystem.DirectoryServices.AccountManagement.PrincipalOperationException: A local error has occurred.
---> System.DirectoryServices.DirectoryServicesCOMException: A local error has occurred.

at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) at System.DirectoryServices.DirectoryEntry.Bind() at System.DirectoryServices.DirectoryEntry.get_SchemaEntry() at System.DirectoryServices.AccountManagement.ADStoreCtx.IsContainer(DirectoryEntry de) at System.DirectoryServices.AccountManagement.ADStoreCtx..ctor(DirectoryEntry ctxBase, Boolean ownCtxBase, String username, String password, ContextOptions options) at System.DirectoryServices.AccountManagement.PrincipalContext.CreateContextFromDirectoryEntry(DirectoryEntry entry) at System.DirectoryServices.AccountManagement.PrincipalContext.DoLDAPDirectoryInit() --- End of inner exception stack trace --- at System.DirectoryServices.AccountManagement.PrincipalContext.DoLDAPDirectoryInit() at System.DirectoryServices.AccountManagement.PrincipalContext.DoDomainInit() at System.DirectoryServices.AccountManagement.PrincipalContext.Initialize() at System.DirectoryServices.AccountManagement.PrincipalContext.get_QueryCtx() at System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithTypeHelper(PrincipalContext context, Type principalType, Nullable1 identityType, String identityValue, DateTime refDate) at System.DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity(PrincipalContext context, String identityValue) at HgLab.Core.Framework.Security.LdapAuthenticationModule.Authenticate(String login, String password, AuthenticationSettings authenticationSettings) in d:\projects\hglab\src\HgLab.Core\Framework\Security\LdapAuthenticationModule.cs:line 108 at System.DirectoryServices.AccountManagement.PrincipalContext.DoLDAPDirectoryInit() at System.DirectoryServices.AccountManagement.PrincipalContext.DoDomainInit() at System.DirectoryServices.AccountManagement.PrincipalContext.Initialize() at System.DirectoryServices.AccountManagement.PrincipalContext.get_QueryCtx() at System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithTypeHelper(PrincipalContext context, Type principalType, Nullable1 identityType, String identityValue, DateTime refDate) at System.DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity(PrincipalContext context, String identityValue) at HgLab.Core.Framework.Security.LdapAuthenticationModule.Authenticate(String login, String password, AuthenticationSettings authenticationSettings) in d:\projects\hglab\src\HgLab.Core\Framework\Security\LdapAuthenticationModule.cs:line 108

As there some sample C# code that I can run to try to play with the exception handling and narrow in where the problem is? If not, do you have any recommendations? I have been using trial and error and feel like I am banging my head into the desk.

Thanks

1. Support Staff 1 Posted by Anton Gogolev on 03 Feb, 2014 11:02 PM

   

   Unfortunately, LDAP causes a lot of grief. To start off, could you please check the Event Log on your Domain Controller to see if there's something fishy?

   • Edit

2. 2 Posted by pberkowitz on 04 Feb, 2014 03:20 AM

   

   I found this in the log.

   Seems like there maybe some security risk in the way you are using the LDAP API?

   Have you encountered this before?

   Regards,

   During the previous 24 hour period, some clients attempted to perform LDAP binds that were either:
   (1) A SASL (Negotiate, Kerberos, NTLM, or Digest) LDAP bind that did not request signing (integrity validation), or
   (2) A LDAP simple bind that was performed on a cleartext (non-SSL/TLS-encrypted) connection

   This directory server is not currently configured to reject such binds. The security of this directory server can be significantly enhanced by configuring the server to reject such binds. For more details and information on how to make this configuration change to the server, please seehttp://go.microsoft.com/fwlink/?LinkID=87923.

   Summary information on the number of these binds received within the past 24 hours is below.

   You can enable additional logging to log an event each time a client makes such a bind, including information on which client made the bind. To do so, please raise the setting for the "LDAP Interface Events" event logging category to level 2 or higher.

   Number of simple binds performed without SSL/TLS: 2
   Number of Negotiate/Kerberos/NTLM/Digest binds performed without signing: 0

   Phillip Berkowitz
   Manager, Advanced Technology
   DRS Technologies – Integrated Defense Systems & Services (IDSS)
   400 Professional Drive STE 400<x-apple-data-detectors://0>
   Gaithersburg MD 20879<x-apple-data-detectors://0>

   Email: [email blocked]<mailto:[email blocked]>
   tel: 301-258-7912<tel:301-258-7912>
   cel: 240-252-0818<tel:240-252-0818>
   lab: 301-921-8083<tel:301-921-8083>

   • Edit

3. Support Staff 3 Posted by Anton Gogolev on 04 Feb, 2014 09:53 AM

   

   Phillip,

   I'm told by our System Administrators that binding over port 636 can sometimes help. Otherwise, here's an example of how HgLab connects to an LDAP server:

   using System;
   // Requires a reference to System.DirectoryServices.AccountManagement
   using System.DirectoryServices.AccountManagement; 
   
   namespace LdapTroubleshooter
   {
       class Program
       {
           static void Main(string[] args)
           {
               var serverAddress = "";
               var serverPort = "";
               var baseContainer = "";
               var bindLogin = "";
               var bindPassword = "";
   
               var serverQualifiedAddress = serverAddress;
               if(!string.IsNullOrWhiteSpace(serverPort))
                   serverQualifiedAddress =  serverQualifiedAddress + ":" + serverPort;
   
               using(var domainContext = new PrincipalContext(ContextType.Domain, serverQualifiedAddress, baseContainer, ContextOptions.Negotiate, bindLogin, bindPassword))
               {
                   var principal = UserPrincipal.FindByIdentity(domainContext, "your-login");
                   Console.WriteLine(principal.DistinguishedName);
               } // using
           }
       }
   }
   

   It would be great if you could run this snippet locally.

   Thanks a lot!

   • Edit

4. 4 Posted by pberkowitz on 04 Feb, 2014 04:38 PM

   

   I was able to figure it out with your sample code.

   Your instructions are misleading.

   Under bind login it says full distinguished name, this is not true.

   I needed to just put the username here, nut full distinguished name.

   I am in business now, thanks for your help!!!

   Phillip Berkowitz
   Manager, Advanced Technology
   DRS Technologies – Integrated Defense Systems & Services (IDSS)
   400 Professional Drive STE 400<x-apple-data-detectors://0>
   Gaithersburg MD 20879<x-apple-data-detectors://0>

   Email: [email blocked]<mailto:[email blocked]>
   tel: 301-258-7912<tel:301-258-7912>
   cel: 240-252-0818<tel:240-252-0818>
   lab: 301-921-8083<tel:301-921-8083>

   • Edit

5. Support Staff 5 Posted by Anton Gogolev on 05 Feb, 2014 06:53 AM

   

   Phillip,

   Nice catch, will update instructions accordingly. Thanks for seeing this through!

   • Edit

6. Anton Gogolev closed this discussion on 05 Feb, 2014 06:53 AM.