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

  • Thread starter Thread starter ohaya
  • Start date Start date
O

ohaya

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
 
In
ohaya said:
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
Click to expand...

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.

--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Having difficulty reading or finding responses to your post?
Instead of the website you're using, I suggest to use OEx (Outlook Express
or any other newsreader), and configure a news account, pointing to
news.microsoft.com. This is a direct link to the Microsoft Public
Newsgroups. It is FREE and requires NO ISP's Usenet account. OEx allows you
to easily find, track threads, cross-post, sort by date, poster's name,
watched threads or subject.

It's easy:
How to Configure OEx for Internet News
http://support.microsoft.com/?id=171164

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft MVP - Directory Services
Microsoft Certified Trainer

Infinite Diversities in Infinite Combinations
Assimilation Imminent. Resistance is Futile
"Very funny Scotty. Now, beam down my clothes."

The only thing in life is change. Anything more is a blackhole consuming
unnecessary energy. - [Me]
 
Ace Fekay said:
In

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.
Click to expand...

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
prescribed naming method for the QUERY itself however.
(Not the computer 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.
 
Herb said:
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
prescribed naming method for the QUERY itself however.
(Not the computer 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.
Click to expand...


Herb,

The machine from which I was running the ldapsearch was a Solaris X86
box, so it wasn't a member of any Windows domain.

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

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?

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

ohaya said:
The machine from which I was running the ldapsearch was a Solaris X86 box,
so it wasn't a member of any Windows domain.
Click to expand...

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).
Click to expand...

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?
Click to expand...

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.


We are discussing the "machine being queried", right?
(That is, the host records point to the LDAP server not
the record being queried.)
 
Herb said:
--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

ohaya said:
The machine from which I was running the ldapsearch was a Solaris X86 box,
so it wasn't a member of any Windows domain.
Click to expand...

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).
Click to expand...

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?
Click to expand...

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.

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



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
 
In
ohaya said:
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
Click to expand...

Thanks for the update. Keep in mind you can also get bind errors just by not
connecting, it doesn't discriminate.

Ace
 
The issue is probably name resolution. Your solaris box wasn't resolving the
short host name.

An alternative is if you are using SSL, you don't specify it, then you need to
use the FQDN because that is what the cert is linked to.

joe


--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm
 
Back
Top