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
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.
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.
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.
"Miles Li [MSFT]" wrote:
...
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
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.
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.
(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...