Controlling/Limiting impact of LDAP Referrals / remote sites down

[Robert A]

We have a misbehaving non-Microsoft LDAP web application. It does not know
how to "not" chase LDAP Referrals. (We're working on that, but a fix is not
imminent.) (A similar case is referenced in a thread called "Bizarre LDAP
referral behavior" [referenced below].)

Here is our situation. When a network link goes down without warning, the
domain controller there is out-of-touch with the rest of the AD domain.

Trouble is, there are seven (7) _ldap SRV records still in DNS, so AD/LDAP
keeps trying to contact the down site when it following LDAP Referrals.
This causes a delay of up to 90 seconds in the application.

We workaround this issue by deleting the 7 _ldap SRV records from the
central site. This allows the application to not experience a delay. When
the site eventually comes back online, it's domain controller re-registers
those 7 _ldap SRV records.

Here are my questions:
- Under normal conditions, if a domain controller is gracefully shutdown,
does it de-register those _ldap records? (I think we only have an issue
when the link goes down without warning.)
- Are there any controlling mechanisms to reduce the 90-second delay when
chasing LDAP referrals to the down site?
- Can I somehow "automatically" have AD remove those SRV records at the
central site, if it know the remote domain controller is unreachable?
- Is there a way that from the central site, we don't see those _ldap SRV
records in DNS? I'm thinking that would stop the LDAP referrals. I
believe I can tell the remote domain controller to NOT register its _ldap
records, but that seems like it would break local applications such as
Outlook.

LDAP SRV records:

mydom.net\_msdcs\dc\_sites\RemoteSite1\_tcp\
SRV record: _ldap

mydom.net\_sites\RemoteSite1\_tcp\
SRV record: _ldap

mydom.net\_tcp\
SRV record: _ldap

mydom.net\_sites\RemoteSite1\_tcp\
SRV record: _ldap

mydom.net\DomainDnsZones\_sites\RemoteSite1\_tcp\
SRV record: _ldap

mydom.net\_sites\RemoteSite1\_tcp\
SRV record: _ldap

mydom.net\DomainDnsZones\_tcp\
SRV record: _ldap

Reference thread:
Bizarre LDAP referral behavior in Windows 2003 AD
microsoft.public.windows.server.active_directory

http://www.servernewsgroups.net/group/microsoft.public.windows.server.active_directory/topic961.aspx

[Michael Ströder]

Robert A wrote:
> We have a misbehaving non-Microsoft LDAP web application. It does not know
> how to "not" chase LDAP Referrals.

Well, if the application simply implements generic LDAPv3 support the term
"misbehaving" is too strong. Letting the LDAP client chase referrals is a
fundamentally broken concept in LDAPv3 anyway because there is no clear
definition at all which credentials the client should use when chasing the
referral.

Speaking of AD as a LDAPv3 implementation with a certain profile or
additional assumptions the client could use the same credentials he used to
bind to the originating server. I think that's the way the AD developers
thought about it in the light of domain trusts etc. But again that's not a
valid assumption in general for a LDAP client application. In general the
application has to be configured with a-priori knowledge how to bind to the
referral's target.

> Reference thread:
> Bizarre LDAP referral behavior in Windows 2003 AD
> microsoft.public.windows.server.active_directory
>
> http://www.servernewsgroups.net/group/microsoft.public.windows.server.active_directory/topic961.aspx

Reading through this your Java developers should not be scared of querying
the GC for searching user entries. It's simply standard LDAPv3. And that's
what the GC is for.

Ciao, Michael.

P.S.: JNDI has a slightly different default behaviour regarding search
continuations (referrals in a search result list) being returned because
with the default options JNDI's LDAP provider trys to use the ManageDsaIT
Control. Not sure if that's supported by AD though.

[Robert A]

I believe the application is still using LDAPv2 libraries; that is part of
the problem.

[Michael Ströder]

Robert A wrote:
> I believe the application is still using LDAPv2 libraries; that is part of
> the problem.

Today this seems very unlikely to me. If this is a Java application it uses
probably JNDI whose LDAP provider speaks LDAPv3. But the application has to
implement a handler for search continuations (referrals) returned if really
needed. You can verify whether LDAPv2 or LDAPv3 is on the wire by looking at
the network trace (e.g. with wireshark's excellent LDAP dissector).

But that's all a wild guess. Without further details about which programming
language and version and which LDAP libs and version I can't say much more.

Ciao, Michael.

[Miles Li [MSFT]]

Hello,

Thanks for your post.

From your description, you have a problem of LDAP SRV record resolve in DNS
server and would like to know if the LDAP SRV record can de-register when
the DC is offline normally or accidently.

1. Under normal conditions, if a domain controller is gracefully shutdown,

does it de-register those _ldap records?

DNS server has a dynamic update feature that allows all records to be
updated (for SRV record, update the HOST's FQDN that holds the service).
However it will never be de-registered (deleted) no matter whether the host
is gracefully or accidently shutdown.

2. Are there any controlling mechanisms to reduce the 90-second delay when

chasing LDAP referrals to the down site?

I am pretty sure that the 90 seconds retry interval is program-specific.

3. Can I somehow "automatically" have AD remove those SRV records at the

central site, if it know the remote domain controller is unreachable?

Windows Server operating system has not such functions. However, you can
develop a script to test the availability of domain controller and delete
the related SRV records while the DC is unreachable. You may configure it
to run as a Scheduled Task. If you need any assistance on developing such a
script, you can post to the MSDN forum at:
http://msdn.microsoft.com/newsgroups/default.asp

4. Is there a way that from the central site, we don't see those _ldap SRV

records in DNS? I'm thinking that would stop the LDAP referrals. I
believe I can tell the remote domain controller to NOT register its _ldap
records, but that seems like it would break local applications such as
Outlook.

Yes, there is a group policy setting 'DC Locator DNS records not registered
by the DCs' in 'Computer Configuration--->Administrative
Templates--->System--->Net Logon--->DC Locator DNS Records' that can
prevent the DC from register SRV records when DC starts up. If you do not
want to register the _ldap records, you may configure this group policy.

The LDAP SRV record is registered by Net Logon including:
---------------
_ldap._tcp.DnsDomainName.

_ldap._tcp.SiteName._sites.DnsDomainName.

_ldap._tcp.dc._msdcs.DnsDomainName.

_ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName.

_ldap._tcp.pdc._msdcs.DnsDomainName.

_ldap._tcp.gc._msdcs.DnsForestName.

_ldap._tcp.SiteName._sites.gc._msdcs.DnsForestName.
---------------

And only _ldap._tcp.DnsDomainName. record is used in LDAP service host
referrals through domain name. So you can enable this setting with 'Ldap'
mnemonic.

More detailed information about SRV record used in Active Directory:

SRV Resource Records
http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/
dsbc_nar_sdns.mspx?mfr=true

Hope this helps.

Sincerely,
Miles Li

Microsoft Online Partner Support
Microsoft Global Technical Support Center

Get Secure! - www.microsoft.com/security
=====================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[Robert A]

Thank you -- I will look into your suggestions.

"Miles Li [MSFT]" wrote:

...

[Robert A]

Miles,

A follow-up question. If I configure domain controllers at certain sites so
that the LDAP SRV records are not defined -- what impact would there be on
Outlook users at that site?

Would the Outlook 2003/2007 client still be able to "find" the Exchange
server [which may be located at the same remote site, or may be located in a
central site] ?

> "Miles Li [MSFT]" wrote:
> ...Yes, there is a group policy setting 'DC Locator DNS records not registered

[Miles Li [MSFT]]

Hello,

Thanks for your reply.

As far as I know, 'DSAccess' in Exchange server queries (SRV) resource
records in Domain Name System (DNS) for the domain zone to determine which
server the client should prefer. So your Exchange Server may be affected
due to the missing SRV records for that domain.

For more information about Exchange Server and Active Directory, you may
refer to:

Exchange Server 2003 Active Directory Integration
http://technet.microsoft.com/zh-cn/library/aa996247(EXCHG.65).aspx

By the way, may I know whether the practice provided in the last post
works? If necessary, we can make further investigation about it.

Also the new question is a Exchange server related issue. Therefore, if the
above information is not sufficient, I would like to suggest that you post
a new thread in Exchange Server Newsgroup to get more information.

Microsoft.public.exchange

Hope it helps.

[Robert A]

Thank you for the additional answers. I will post to
Microsoft.public.exchange regarding the SRV records and affect on
Exchange/Outlook.

I will not know the results of testing the changes you recommended.

I am trying to encourage the application team to update their application
for LDAPV3 --- or to use a dedicated LDAP server -- ADAM -- for their
application purpose.

[Jorge de Almeida Pinto [MVP - DS]]

from what I know DSACCESS uses DNS to retrieve a DC to read the directory
from. After that DSACCESS creates an in-site list and an out-site list based
upon the information of the directory itself. Depending on the service pack
(e2k3 pre-sp2 or e2k3 sp2 and later) it will use a certain algorithm to hand
out a DC/GC to the outlook client. for more info on this algorithm see the
EHLO blog

(I did not read the post from the OP (using offline stuff here))

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services #

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test ANY suggestion in a test environment before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
"Miles Li [MSFT]" <v-mi...@online.microsoft.com> wrote in message
news:MHINNojl...@TK2MSFTNGHUB02.phx.gbl...