[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
?
Solved

LDAP Bind was unsuccessful on directory

Posted on 2007-08-10
29
Medium Priority
?
1,610 Views
Last Modified: 2008-06-01
We have a 2003 Exchange Server (Enterprise) and one Windows 2003 Std Server domain controller.  We just started finding this error in the logs (EVENT ID 8026):

LDAP Bind was unsuccessful on directory main.internal.network for distinguished name. Directory returned error:[0x51] Server Down.  DC=main,DC=network

I have been looking through the postings, but cannot seem to resolve the issue.  Some postings have been leaning towards a DNS issue.  The domain controller is up and running, with no visible errors and can be pinged.

Does anyone have a solution to this problem?  I don't want it to interfere with incoming/outgoing mail.

Thanks in advance for any help you can offer.
0
Comment
Question by:segalian
  • 21
  • 4
  • 3
  • +1
29 Comments
 
LVL 5

Expert Comment

by:RightNL
ID: 19671223
have a look at RPC...

have you installed SP1?
0
 

Author Comment

by:segalian
ID: 19671252
The mail server is running Exchange 2003 SP2.

Look at RPC?  Could you elaborate?
0
 

Author Comment

by:segalian
ID: 19671267
We just go this error too:

SOURCE: MSExchangeDSAccess
CATEGORY: Topology
EVENT ID: 2114

Process MAD.EXE (PID=1908). Topology Discovery failed, error 0xffffffff.
0
Veeam Disaster Recovery in Microsoft Azure

Veeam PN for Microsoft Azure is a FREE solution designed to simplify and automate the setup of a DR site in Microsoft Azure using lightweight software-defined networking. It reduces the complexity of VPN deployments and is designed for businesses of ALL sizes.

 

Author Comment

by:segalian
ID: 19671338
And now we noticed that when we send emails to someone outside, when that person replies, we are finding on occassion, the file winmail.dat attached to some of these emails, and the email is no longer in rich text - it's now in plain text.

Could all of this be somehow related?
0
 
LVL 35

Expert Comment

by:rakeshmiglani
ID: 19671352
it appears to be some sort of communication issue between the exchange server and DC/GC
install and run the following MS tool and see if it reports anything
Microsoft Exchange Best Practices Analyzer v2.8
http://www.microsoft.com/downloads/details.aspx?familyid=DBAB201F-4BEE-4943-AC22-E2DDBD258DF3&displaylang=en
0
 

Author Comment

by:segalian
ID: 19671370
any idea about the WINMAIL.DAT file attachment?
0
 
LVL 35

Expert Comment

by:rakeshmiglani
ID: 19671407
0
 

Author Comment

by:segalian
ID: 19671479
Now I am getting an error when trying to open ESM - the server is not operational.  When the ESM window finally opens, nothing is listed!!!

I feel like blowing away this whole mail server - I do not understand why all of a sudden out of nowhere this machine started acting like this.
0
 
LVL 35

Expert Comment

by:rakeshmiglani
ID: 19671495
try to reboot the server.
were any changes made?
0
 

Author Comment

by:segalian
ID: 19671531
The only thing that was done recently was that a trial version of GFI Mail Essentials was installed, then uninstalled... it seems like the strange behaviors have been occurring after that.

On another note, it also seems like we almost get no more spam just using MS Exch's internal spam prevention tools like the Sender ID filtering and IMF from Exch 2003 SP2.

We're still getting mail in, but cannot get ESM to populate after it opens.  We may have to reboot the mail server now.
0
 

Author Comment

by:segalian
ID: 19671652
I rebooted the mail server, logs are clean now.  I also attempted updating RUS from ESM.
0
 

Author Comment

by:segalian
ID: 19671687
After running the analyzer tool:

CRITICAL: database backup
Recipient update service did not process all changes
DNS host record appears to be missing
SMTP configuration warning
0
 
LVL 104

Expert Comment

by:Sembee
ID: 19671743
The winmail.dat is another issue completely, so you should ask that separately.
The critical backup error, that is something you need to resolve by backing up the server.
The rest looks like a DNS issue. Ping means squat.
You need to look at what server the Exchange server is connecting to for DNS. If you have other servers that it can be changed to then try that.
I don't think this is an Exchange issue, more to do with the underlying connection to the AD.

Simon.
0
 

Author Comment

by:segalian
ID: 19671767
Simon,

Thanks for helping me narrow down the possibilities here... can you point me in a direction to resolve the alleged internal DNS issue that you are indicating?

Ian
0
 

Author Comment

by:segalian
ID: 19671857
Also, the last time we had that LDAP error was about 40 minutes ago (it was continuously repeating prior to the mail server reboot, but we were still able to send/receive mail).
0
 

Author Comment

by:segalian
ID: 19671869
Is there anything I can do to resolve any connection issues to AD from the exchange box?
0
 

Author Comment

by:segalian
ID: 19671890
Everything checked out fine with regard to AD after running the best practices analyzer
0
 

Author Comment

by:segalian
ID: 19671916
Recipient Update Service did not process all changes

The 'gatewayProxy' attribute for Recipient Update Service 'Recipient Update Service (Enterprise Configuration)' contains old data that was not fully processed. This data has existed since 2007-03-14T08:54:59Z and should be manually removed to avoid accidental changes to user addresses.
0
 

Author Comment

by:segalian
ID: 19671942
This is what I found with regard to correcting the recipient update service's old data issue:
--------------------------------------------------------------------------------------------------------------
To correct this warning
Set the update interval to the Recipient Update Service to Never as follows:

Open Exchange System Manager.

Expand Recipients and expand Recipient Update Services.

Right-click the Recipient Update Service that you want to modify, and then select Properties.

On the General tab, using the Update interval list, set the schedule to Never run.

Wait approximately one to two minutes.

Next, use ADSI Edit or a similar tool to locate the Recipient Update Service object whose gatewayProxy attribute contains old data. Recipient Update Service objects are located at:

CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=Organization,CN=Address Lists Container,CN=Recipient Update Services

Right-click the Recipient Update Service object that contains the old data, and then select Properties.

On the Attribute Editor tab, scroll down and select the gatewayProxy attribute.

Click Edit to edit this attribute.

In the Value(s) box, select the legacy address type to be removed, click Remove, and click OK. Repeat this step until all address types have been removed.

Click OK to save the changes, and then close ADSI Edit.

Force a directory replication to occur after you clear the gatewayProxy attribute. Make sure that replication occurs before you let the domain Recipient Update Service run again.

Reconfigure the Recipient Update Service to its original schedule.

If you have to, reapply the specific recipient policies. Use the Active Directory Sites and Services snap-in to perform a manual Active Directory replication.

0
 
LVL 104

Expert Comment

by:Sembee
ID: 19671960
The best practises tool should have said that needed to be done. Just follow those instructions. I have to do it with most new servers I look at.

Simon.
0
 

Author Comment

by:segalian
ID: 19671978
I'm not familiar with this tool: "use ADSI Edit or a similar tool to locate the Recipient Update Service object "

Do you know how/where I can find/use the ADSI Edit tool?

Ian
0
 

Author Comment

by:segalian
ID: 19671994
DNS host record appears to be missing:

The 'Host' (A) record for server mail.internal.network cannot be retrieved from DNS server '167.206.245.72'. This can cause message routing delays and other service failures. Verify that the DNS server is online and that the 'Host' record is present.

Any ideas for this?  Maybe this is the issue?  I use that IP as a forwarder... it's a DNS server from my ISP.
0
 

Author Comment

by:segalian
ID: 19672018
Just got this error:

MSExchangeTransport
Event ID 7519

The originating IP address of message with ID <MAILleCmu3LOFE4cu00000001@mail.DOMAIN.com> could not be determined based on its Received headers.

>> do you think this has anything to do with the Exchnage 2003 spam filters?
0
 
LVL 104

Accepted Solution

by:
Sembee earned 2000 total points
ID: 19672037
The best practises tool shouldn't have picked up the external DNS server at all.
Are you sure that it is a forwarder and not configured somewhere in the network configuration of the server anywhere, or on the SMTP virtual server?
That would explain the LDAP errors if it is somewhere in the network config.

ADSIEDIT.MSC is part of the Support Tools on the Windows CD. Think of it like a registry editor for your domain. However the warnings about the registry are minor compared to the warnings about adsiedit. One wrong move in there and you can wreck your entire domain. You have to be really careful as it is the heart of the domain configuration. There is no undo.

Simon.
0
 

Author Comment

by:segalian
ID: 19672059
I'll look at DNS on the DC with regard to that external DNS server.

I'll look also at the mail server and try to get back to you.
0
 

Author Comment

by:segalian
ID: 19672085
I found that external DNS server and two others from the ISP listed under:

DEFAULT SMTP VIRTUAL SERVER PROPERTIES
>> then >>
DELIVERY TAB
>> then >>
ADVANCED BUTTON

I removed all three of them, then hit Apply, Ok.

Do you think that was causing this crazy LDAP/DNS/etc issue on the mail server?
0
 

Author Comment

by:segalian
ID: 19672093
And do you think I need to type in a "Masquerade Domain" in the empty field for this area of the Smtp Virtual Server properties?
0
 
LVL 35

Expert Comment

by:rakeshmiglani
ID: 19672484
you can leave that blank.
try running dcdiag and check if that reports any issues with the communication
0
 

Author Comment

by:segalian
ID: 19674433
I removed the external DNS server addresses from the SMTP Virtual Server properties under the Deliver Tab, and that seems to have resolved it.  Unfortunately, enabling the check of Reverse DNS in ESM is essentially good for nothing as MS Exchange won't reject mail if RDNS fails - what a waste.

Rakesh: thanks for the advice on the DCDIAG - I'll definitely use that in the future.

Simon: thanks for bearing with me the entire afternoon through the resolution of this problem... I appreciate all your time and patience with me.

Best,

Ian
0

Featured Post

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Transferring FSMO roles is done when an admin wants to split roles between certain Domain Controllers or the Domain Controller holding the Roles has been forcefully demoted using dcpromo / forceremoval
Mailbox Corruption is a nightmare every Exchange DBA wishes he never has. Recovering from it can be super-hectic if not entirely futile. And though techniques like the New-MailboxRepairRequest cmdlet have been designed to help with fixing minor corr…
The video tutorial explains the basics of the Exchange server Database Availability groups. The components of this video include: 1. Automatic Failover 2. Failover Clustering 3. Active Manager
Exchange organizations may use the Journaling Agent of the Transport Service to archive messages going through Exchange. However, if the Transport Service is integrated with some email content management application (such as an anti-spam), the admin…
Suggested Courses

834 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question