Re: Possibly slightly O.T.: Why FQDN required to do simple bind with "ldapsearch"?



--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

"ohaya" <ohaya@xxxxxxx> wrote in message
news:O9Qj55tYGHA.4760@xxxxxxxxxxxxxxxxxxxxxxx
Herb Martin wrote:
"Ace Fekay [MVP]" <PleaseAskMe@xxxxxxxxxxxxxx> wrote in message
news:u$3aYrpYGHA.1200@xxxxxxxxxxxxxxxxxxxxxxx
In news:%23njWQ$oYGHA.4836@xxxxxxxxxxxxxxxxxxxx,
ohaya <ohaya@xxxxxxx> stated, which I commented on below:
Hi,

I was doing some testing, using ldapsearch from a Solaris machine, to
access Active Directory. I was trying to use a simple bind, and
initially could not get a successful access, until I started using a
fully-qualified domain name (FQDN) for the hostname parameter.

I'm not sure if this is more of an AD question, or an ldapsearch
question, but I was wondering if anyone might know why I had to use
the FQDN for the ldapsearch hostname parameter in order for the
simple bind to succeed?

Thanks,
Jim
AD is not like NT4 where it works using NetBIOS. Any ldap search is FQDN
based to 'find' the ldap server. AD is DNS based. Server names are
tagged with an SPN (Server Principal Name), which is the machine's
FQDN., and how it finds it to bind to it.

However, since most Windows programs which use DNS
lookups WITH the built-in name resolving would fail over
to NetBIOS lookups if all DNS methods fail.

So one might legitimately wonder why this didn't happen here.
(Notice this is different than apps like IE which might actuall
DO a "NetBIOS resolution" directly under certain conditions.)

Within an LDAP query the DISTINGUISHED name is the
The machine from which I was running the ldapsearch was a Solaris X86 box,
so it wasn't a member of any Windows domain.

Then (since it wasn't a windows box, domain or not) the
lack of fail over to NetBIOS resolution is ENTIRELY
unsurprising.

Also FYI, I'm pretty sure that I had the /etc/hosts entry for the AD
machine with both the FQDN and a short name (ct3.whatever.com and ct3,
respectively) of the AD machine, i.e., I wasn't using DNS to do name
resolution on the Solaris box, so this is still puzzling (to me).

The puzzle returns. Hosts files have NO CONCEPT of an FQDN,
and do this by faking a full DNS name (the dots are just characters,
not separators and their is NO hierarchy with hosts records.)

Given that you had both entries it should be able to SEND the
LDAP request to the LDAP server (both names resolve to SAME
address presumably.)

I'm having a hard time understanding how AD would even be aware of what I
used for the hostname in the ldapsearch command line, unless the LDAP
protocol has the hostname embedded in the protocol somehow?

Me too. Although this is the case with Web servers sometimes
(web servers frequently use Host headers to distinguish multiple
sets of different content) very few services make such distinctions.


prescribed naming method for the QUERY itself however.
(Not the computer being queried.)

We are discussing the "machine being queried", right?
(That is, the host records point to the LDAP server not
the record being queried.)

I am curious. Perhaps his machine doesn't have its domain
name set in the System Control panel or it's set to a different
domain than he was querying.



.

Relevant Pages