Re: Blocking LDAP at Domain Controller to protect sensitive inform
- From: "Joe Kaplan \(MVP - ADSI\)" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 15 Mar 2006 14:23:33 -0600
I'm more of an applications guy than an infrastructure guy. I was mainly
trying to point out that:
- Applications using AD can request encryption on port 389 if they use
Windows authentication; SSL is not the only way to get it
- You may break some applications that you need for using or managing AD if
you do block port 389
For example, the domain controller locator service that workstations and
servers use for finding the correct domain controller to use will do an LDAP
"ping" of the domain controllers (on UDP 389) to find the one to talk to.
If you block all port 389 access to your DCs, machines that are domain
members may not be able to find a domain controller anymore. You might not
want that. Exchange might not work anymore either (assuming that you use
it). These are just a few examples.
That said, if you want to block it and you already have firewalls, why not
just use those to block it? You could even use the built in Windows
firewall in 2003 to block inbound 389.
I don't think AD provides a mechanism to disable it though.
Joe K.
"doc pisapati" <docpisapati@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:4688E04B-6BB5-42C4-8748-4A617F162441@xxxxxxxxxxxxxxxx
We have a couple of firewalls around DCs. IPSEC is not accepted by
firewalls
guys. Secondly, yes, the application access over LDAP should fail as we
are
making SSL/LDAP as corportate standard for external DCs. Hence we should
be
able to block LDAP on DCs like any other LDAP servers.
"Joe Kaplan (MVP - ADSI)" wrote:
Todd's recommendation is the way to go then. Use IPSEC.
AD does support SSL/LDAP for both regular and GC calls. It also supports
SSPI-based encryption and signing of LDAP traffic if the user
authenticates
using SSPI with LDAP. Many Windows clients use that feature, as it
generally means that the user does not need to be prompted for
credentials.
The problem is that it difficult to enforce that clients will use either
SSL
or SSPI-based encryption as that is initiated by the client.
Blocking port 389 may break a lot of apps that use LDAP, so it may not be
viable to do that either. IPSEC seems like the way to go there.
Joe K.
"doc pisapati" <docpisapati@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:38639CB1-0256-48C0-AF5B-7D0504195C41@xxxxxxxxxxxxxxxx
Per Regulatory Compliance such as ISO17799, the sensitive information
should
be encrypted on the wire. LDAP is a clear text protocol. LDAPS does
provide
encryption. Other LDAP services such as Oracle Internet Directory
(OID),
eDirectory, etc provide LDAPS/LDAP on any port that we choose to add
more
security.
"Paul Williams [MVP]" wrote:
I don't know how you can do this unless you sit your DCs the other
side
of a
firewall. Why is this a requirement?
--
Paul Williams
Microsoft MVP - Windows Server - Directory Services
http://www.msresource.net | http://forums.msresource.net
.
- Follow-Ups:
- Re: Blocking LDAP at Domain Controller to protect sensitive inform
- From: doc pisapati
- Re: Blocking LDAP at Domain Controller to protect sensitive inform
- References:
- Re: Blocking LDAP at Domain Controller to protect sensitive informatio
- From: Paul Williams [MVP]
- Re: Blocking LDAP at Domain Controller to protect sensitive inform
- From: Joe Kaplan \(MVP - ADSI\)
- Re: Blocking LDAP at Domain Controller to protect sensitive informatio
- Prev by Date: Re: Blocking LDAP at Domain Controller to protect sensitive inform
- Next by Date: Re: Blocking LDAP at Domain Controller to protect sensitive inform
- Previous by thread: Re: Blocking LDAP at Domain Controller to protect sensitive inform
- Next by thread: Re: Blocking LDAP at Domain Controller to protect sensitive inform
- Index(es):
Relevant Pages
|