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
Post by Jason Robarts [MSFT]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/documentation/WindowsServ/2003/standard/proddocs/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/638.asp.
Post by Jason Robarts [MSFT]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
Post by Joe Richards [MVP]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
--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net
Post by Boris LokhvitskyHello 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