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



Herb Martin wrote:

--
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.



Hi,

Mystery solved!!

First, I need to correct something that I said earlier. I took at look
at my Solaris machine, and the short hostname (ct3) is NOT in
/etc/hosts.

I think that this answers the puzzle, and it was a stupid assumption on
my part :(... Let me explain...


I am using the ldapsearch command line:

ldapsearch -h ct3 ......

where "ct3" is suppose to be the name of the AD machine (again, "ct3" is
NOT in /etc/hosts on the Solaris machine.

When I command line that, I get a prompt for the bind password. My
ASSUMPTION was that ldapsearch got that far (to the point that it gave
me the prompt for the bind password) because it at least was able to
connect to the AD machine :(...

I think that what's actually happening is that ldapsearch is prompting
for the bind password AND THEN it tries to connect to the AD machine.
Since it can't resolve the short hostname, then it (ldapsearch) fails.

The other misleading thing about all of this was that when it failed,
ldapsearch gave me a "ldap_simple bind" error, which seemed to indicate
that the problem was the bind, and not necessarily the connect :(...

Thanks all!

Jim
.

Relevant Pages

  • Re: Possibly slightly O.T.: Why FQDN required to do simple bind with "ldapsearch"?
    ... I was doing some testing, using ldapsearch from a Solaris machine, to ... fully-qualified domain name (FQDN) for the hostname parameter. ... Any ldap search is FQDN ... based to 'find' the ldap server. ...
    (microsoft.public.win2000.active_directory)
  • Possibly slightly O.T.: Why FQDN required to do simple bind with "ldapsearch"?
    ... 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 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? ...
    (microsoft.public.win2000.active_directory)
  • Problem reading userpassword with JNDI
    ... has anybody managed to read a user's password from an LDAP? ... ldapsearch, it's retrieved in clear text (the server is cinfigured with ... IBM Directory Server 4.1. ...
    (comp.lang.java.programmer)
  • Re: Query LDAP from Linux??
    ... the LDAP Java stuff was ... This means he will need a server name to bind too. ... He will need a port, if he wants to do a standard LDAP bind he will want 389. ...
    (microsoft.public.windows.server.active_directory)
  • Re: LDAP Lookup failure
    ... bind but LDP can, then that should clear ldap for you. ... ldap to bind to the server. ... When it fails can you also do a forward and reverse lookup of the host name ...
    (microsoft.public.windows.server.active_directory)
Loading