The security of this directory server can be significantly enhanced by configuring the server to reject SASL
I am getting this warning in my event logs. When I click on the link for How to make this configuration, the page is no longer available.
Does anybody know how to do the changes?
Thanks,
Paul
Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 12/29/2007 9:18:31 AM
Event ID: 2886
Task Category: LDAP Interface
Level: Warning
Keywords: Classic
User: ANONYMOUS LOGON
Computer: <ServerName>Description:
The security of this directory server can be significantly enhanced by configuring the server to reject SASL (Negotiate, Kerberos, NTLM, or Digest) LDAP binds that do not request signing (integrity verification) and LDAP simple binds that are performed on a cleartext (non-SSL/TLS-encrypted) connection. Even if no clients are using such binds, configuring the server to reject them will improve the security of this server.
Some clients may currently be relying on unsigned SASL binds or LDAP simple binds over a non-SSL/TLS connection, and will stop working if this configuration change is made. To assist in identifying these clients, if such binds occur this directory server will log a summary event once every 24 hours indicating how many such binds occurred. You are encouraged to configure those clients to not use such binds. Once no such events are observed for an extended period, it is recommended that you configure the server to reject such binds.
For more details and information on how to make this configuration change to the server, please see http://go.microsoft.com/fwlink/?LinkID=87923.
You can enable additional logging to log an event each time a client makes such a bind, including information on which client made the bind. To do so, please raise the setting for the "LDAP Interface Events" event logging category to level 2 or higher.
Tutte le risposte
Paul,
I have been looking for a written reason that you are running into this and how to get rid of it, and I cannot find one.
The things I am confident of:
In order to digitally sign an LDAP bind, you are going to need to get a certificate that has the purpose of digital signature.
In order to perform a simple LDAP bind over SSL/TLS you are going to need a cert that allows for network traffic encryption.
You could do this with a single cert and the PKI infrastructure required to do this would be simple. It would also greatly increase the security of your environment -- just like the warning states. But, it is not something that should be undertaken trivially. The PKI infrastructure that would be required to do this, and the best infrastructure for your environment may be different, so plan this carefully to avoid redoing a lot of work in the future!
The things I am spitballing:
Deploying the certificates would ALLOW the server to do these things, but REQUIRING the server to do them is a different matter.
I have not had an opportunity to scour the expanded group policy to find all of the keys, but I am guessing that you can set this policy much like IPsec. The deployment of certificates is most likely going to be a seperate set of tasks than the requiring of secure authentication...
To conclude, as a security nut, I am a fan of machine certificates for authentication and signing. However, they do add an overhead and an associated cost - just think about how much harder it is to clean up an environment if your certs become invalid because your CRLs fall off of the planet
. Although the warning is correct - you could increase your security with the appropirate measures to lock down this DC - I am fairly certain that the associated costs could be allocated toward security initiatives that would give you more bang for your buck.Let me know if you find anything on this!! This is something that I know I will run into often.
Keep us posted,
In Windows Server 2008 we added some additional logging around LDAP security to help customers identify if they have clients connecting to the directory without using LDAP signing or passing credentials in the clear via Simple LDAP binds without TLS/SSL. The link is not live yet telling you how to configure your environment to be more secure and require it with the implications to downlevel or third party clients that may not support this requirement. I expect this content to go live once Windows Server 2008 RTMs. That being said LDAP Signing does not require a certificate, we can use other key material such as Kerberos tickets. Until the documentation for Windows Server 2008 gets published you can find out more about enabling LDAP signing on the Server and Client sides in the following Knowledge Base Article: http://support.microsoft.com/kb/823659.
Thanks,
-Steve
- Thanks to you both. I'll check out the KB.
The KB article number for this changes should be KB935834. And it isn't still there. Even after WS2008 already RTMed.
Could you please publish at least kinda unofficial draft version in some blog?
Thanks in advance.
- Here it is JUNE and just about every link in my event viewer for Server 2008 still comes up with bubkis - any idea when some of these links might go live? I don't like any events in my event viewer unfortunately they all link to non existent KB articles.
- Hello,
the link / KB Article still ain't working. - This is coming from a rule security about non signed client. To resolve this you have to modify the strategy policy on Default Domain Controller Policy.
I found that but excuse my poor english.
So open Gpedit, found Default Domain Controller Policy Strategy.
In Computer Configuration
==>Strategy
==> Windows Parameters
==>Local Strategy
==>Security Options
Here go to the line : Domain Controller : Conditions required for the signature of LDAP Server ( I hope this the exact traduction because i dont know the line on the Windows 2008 server) and modify the rule to accept the signature. (This is for server negociation)
Go also to the line : Network Security : Conditions required for the signature of LDAP Client and modify the rule to negociate the signature (This is for clients negociation)
That will modify the rule and propage this to the clients in the domain. After this only autorized servers and clients integrated before in the domain could connect in the domain, all others will not.
Hope this will be helpfull.
Explanations can be found in : http://support.microsoft.com/kb/823659 but still have to search like always in KB. - I cant find anything about Strategy, are you using some kind of strategy here?
Oh right got it!- ModificatoI installed vista on my bin martedì 5 agosto 2008 15.54I figured it out.
- The two gpo's to configure to remove this warning are:
Computer Configuration>Policies>Windows Settings>Security Settings>Local Policies>Security Options> -- Network Security: LDAP client signing requirements = negotiate signing
Computer Configuration>Policies>Windows Settings>Security Settings>Local Policies>Security Options> -- Domain controller: LDAP server signing requirements = require signing
Hope this helps - You must have a thorough understanding of LDAP certificate management prior to this change as stated previously.
dsloyer - Hello
In my case those two rules are = NONE
And the second one I can not change it? Do you know why?
Delmira - I noticed these posts while working on an issue with some legacy systems.
Basically, I've got some Linux boxes that use Basic LDAP binds to our Windows 2003 servers. I'm trying to raise the functional level to Windows 2008, and I'm noticing that when I point these Linux systems to the new Windows 2008 boxes... the simple LDAP binds no longer work.
Of course, I'm ALSO seeing the Event ID 2886 errors, which is fine for now.
Question: Does anyone know what I need to change to allow SIMPLE LDAP BINDS to work against a Windows 2008 AD DC?
(This would be temporary until we get LDAPS up and running, or something like it... We're using IPSEC anyway... so the risk is minimal...)
GB
Gerhard- ModificatoGBMaryland martedì 9 dicembre 2008 16.11Typo
- The KB has been created and should now be available. You can access it directly at:
http://support.microsoft.com/kb/935834
Thank you and sorry for the delay- Proposto come rispostaHenry Jerez venerdì 13 febbraio 2009 17.57
