How to prevent LDAP simple bind?

  • Thread starter Thread starter Boris Lokhvitsky
  • Start date Start date
B

Boris Lokhvitsky

Hello All,
Simple LDAP bind, as everybody knows, uses plaintext username and password
transmitted over the network. In case I am not using port 636 (LDAP-SSL),
and just plain old 389, how can I prevent users from performing simple bind
to my domain controller and only allow them to use secure SSPI bind?
The best I could find was KB 823659 which advises to use GPO setting "LDAP
server signing requirements". I am still not sure if this might help here.
Some other articles mention that ADSI is restricted to SSL port (636) when
it makes a bind call to the LDAP server. However, there might be different
LDAP clients (Linux flavored indeed) that use various methods. I would like
to prevent any possibility of a simple bind to happen.
Please advise.
Thanks,
Boris
 
Yes I believe this will accomplish your goal as it has a requirement, strong
authentiation and a simple bind isn't.

ADSI can use 389, as does normal LDAP and that has nothing to do with the bind
type. You can do a sasl bind to 389 just fine. Blocking 389 would break a ton of
stuff.

joe
 
Just a note - once the client has attempted the simple bind the cat's out of
the bag. The client has issued the simple bind request and put the password
on the wire and then the server rejects the request. This may result in a
call to your helpdesk indicating application XYZ failed and then you can
deal with the app. But the simple bind, and thus the password, was still
put on the wire.

Using a simple bind is an application design choice. We control some
aspects of clients written with Microsoft's APIs using
http://www.microsoft.com/resources/...dowsServ/2003/standard/proddocs/en-us/638.asp.
Per the doc we don't override a programmer's design choice to explicitly
request a simple bind. Since a simple bind w/o SSL/TLS can't provide
integrity protection the policy in 823659 effectively disables them.

If this threat warrants it, one way to raise the bar against this threat is
to use ipsec.


Jason
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
 
Thanks Joe,

Yeah I understand that. What I meant was - actually there are two
alternatives, you can either allow simple bind but require to use SSL for
it, or you can require secure bind over plain 389. Both ways are secure, I
am just wondering how to prevent the NON secure way which is simple bind
over port 389.

Thanks,
Boris
 
Thanks Jason, Joe,

Yes indeed if the client wants to put his/her password on the wire, and the
client is non-Microsoft and in no relation to the AD domain, there is
nothing I can do to prevent it. This is obvious. I just want to ensure that
our AD server will NEVER accept the simple bind connection over the
non-secure port such as 389.

Is there a way how I can test if the policy specified in KB 823659 does
actually work?
I tried to use LDP utility, but it doesn't do a simple bind even without the
policy applied. I am not sure if I'm using it correctly, though. Here is
what I get, no difference if the policy was applied or not:
===========
res = ldap_bind_s(ld, NULL, &NtAuthIdentity, 1158); // v.3
{NtAuthIdentity: User='borisl'; Pwd= <unavailable>; domain = 'sib'.}
Authenticated as dn:'borisl'.
res = ldap_simple_bind(ld, 'borisl', <unavailable>); // v.3
===========
For me, it looks like the simple bind still works - otherwise it should say
"server rejected connection" or something, shouldn't it?

Any comments here?

Thanks a lot,
Boris
 
Joe... By the way, this is KB 817583 that refers to what I mentioned. Here's
the quote:

While you are using a program that uses ADSI to communicate to any
Lightweight Directory Access Protocol (LDAP) server that is listening on a
port other than the SSL port 636 ... the program cannot bind to the LDAP
server by using the ADS_USE_SSL/ADS_USE_ENCRYPTION options in the
ADSOpenObject method. ... This problem occurs because ADSI is restricted to
SSL port number 636 when it makes a bind call to the LDAP server.

It doesn't seem to get along with what you said ("ADSI can use 389, as does
normal LDAP and that has nothing to do with the bind type"), or perhaps I am
missing the logic here... Not relevant to my problem, though :)

Regards,
Boris
 
Cool! I have tested it with the home-grown Java client performing the simpla
bind - and this policy is working fine.

Thanks Joe, thanks Jason, for your help.

Best regards,
Boris


Boris Lokhvitsky said:
Thanks Joe,

Yeah I understand that. What I meant was - actually there are two
alternatives, you can either allow simple bind but require to use SSL for
it, or you can require secure bind over plain 389. Both ways are secure, I
am just wondering how to prevent the NON secure way which is simple bind
over port 389.

Thanks,
Boris


Joe Richards said:
Yes I believe this will accomplish your goal as it has a requirement, strong
authentiation and a simple bind isn't.

ADSI can use 389, as does normal LDAP and that has nothing to do with
Click to expand...
the
bind
type. You can do a sasl bind to 389 just fine. Blocking 389 would break
Click to expand...
a
ton of
Click to expand...
 
Inline below...
I tried to use LDP utility, but it doesn't do a simple bind even without
the
policy applied. I am not sure if I'm using it correctly, though. Here is
what I get, no difference if the policy was applied or not:
===========
res = ldap_bind_s(ld, NULL, &NtAuthIdentity, 1158); // v.3
{NtAuthIdentity: User='borisl'; Pwd= <unavailable>; domain = 'sib'.}
Authenticated as dn:'borisl'.
res = ldap_simple_bind(ld, 'borisl', <unavailable>); // v.3
===========
Click to expand...

You need to clear the Domain check box in the Bind dialog in ldp.exe to
force
a simple bind, you will then need to use either the user DN or UPN in the
user field
of that dialog box.

Lee Flight
 
Inline below...
... This problem occurs because ADSI is restricted to
SSL port number 636 when it makes a bind call to the LDAP server.
Click to expand...

This was certainly a problem for the WinXP ADSI client, I think the above
reads
as "if you are specifying ADS_USE_SSL as an ADSI option then the WinXP
ADSI client will only attempt to use port 636 and so if you are running your
LDAP
server SSL port on something other than 636 it will not work without the
hotfix".

The problem that makes that hotfix important for ADAM ADSI clients on
Windows XP
prior to WinXP SP2 is the "When ADSI calls to bind to ADAM by using a
Windows security
principal over a SSL connection with the ADS_SECURE_AUTHENTICATION option,
ADSI
then uses a simple bind call instead of a secure bind call."

Lee Flight
 
You can force adfind to do a simple bind...

adfind -default -s base -simple -u "<user dn or name>" -up "<password>"


for example

adfind -default -s base -simple -u "joehome\testuser" -up "passwd1"


You can get adfind on the free win32 tools page of my website.

Obviously you can do a net trace with netmon or ethereal to doublecheck.
 
Back
Top