ONTAP Discussions
ONTAP Discussions
Hello,
In January Microsoft will force "LDAP Signing" (LDAPS) and "channel binding" which will make all unencrypted connections impossible to the ActiveDirectory Domain Controllers.
We are running several SVMs (NetApp Release 9.6P3) which currently still do unencrypted LDAP queries on our Active Directory infrastructure domain controllers. These connections generate an MS "event id 2889".
The security style of those SVMs are NTFS only and only accessed from Windows clients.
From what I understood, there are 2 ways of switching to the ldap "sign and sealing mode". The first and simpliest method is changing the session-security-for-ad-ldap setting to "seal", which I did for all SVMs, and to be sure, I also restarted all CIFS Server of the SVMs.
Unfortunately, this doesn't seam to work or at least not always, because SVMs still query in clear (no SSL/TLS) as we still log some "event id 2889" on our Domain Controllers from all SVMs. All connections that are logged are made from the SVM computer account like: "DOMAIN\SVMCITEST2103$"
I would really appreciate some help, ideas or any hint to fix this issue?
Is there some log file (I could view or inspect) and/or any additional ontap commands we could use in Ontap to troubleshoot this kind of issues?
Thank you very much for any help!
Kind regards,
Didier
Solved! See The Solution
I'm being told there is a fast track RFE on this. I would suggest your company enable the gpo from MS that bypass enforcement of this setting after the patch come out until all vendors are inline with this setting
Hi - you mentioned a RFE concerning continued 2889 messages indicating insecure LDAP connections even after enabling the sign/seal options in ontap. Did you get any further response from Netapp concerning this? We're seeing the same disquieting issue.
Thanks
Thanks, I was looking for that event ID that gets triggered b/c our vulnerability team is still getting them upon implementing this.
Some registry changes need to be made on the DCs to enable this eventid otherwise you just get a daily summary message. Once the logging level is increased for LDAP you can get 2889 errors containing the IPs of each attempted connection. We're seeing occasional insecure LDAP connections on our test SVM - even after applying the recommended settings. We can disasble them entirely by fiddling with some of the other cifs security options - but we'd like proper advice on what's appropriate to change
Yes, I think i'm in the same boat
@DaveFord wrote:
Some registry changes need to be made on the DCs to enable this eventid otherwise you just get a daily summary message. Once the logging level is increased for LDAP you can get 2889 errors containing the IPs of each attempted connection. We're seeing occasional insecure LDAP connections on our test SVM - even after applying the recommended settings. We can disasble them entirely by fiddling with some of the other cifs security options - but we'd like proper advice on what's appropriate to change
Quick Question, where did you see that RFE
I haven't seen any RFE - you mentioned an RFE in your post in December. We've raised a support ticket with NetApp to get an answer to this.
Dave
Ok, I see what you mean now, sorry for the confusion.. they released the notice in the thread, but they have not addressed your concern
I've got the same issue after configuring both LDAP over TLS and LDAP sealing.
NetApp support acknowledge this issue and there is an internal bug:
Bug ID | 1300585 |
---|---|
Title | Event ID 2889 generated on Windows Domain Controller when LDAP sealing is used |
Duplicate of | |
Bug Severity | 3 - Serious inconvenience |
Bug Status | Not Fixed |
Product | Data ONTAP |
Bug Type | Unknown |
Description Formatted |
The following event is generated on the Windows Domain Controller when LDAP sealing is configured in ONTAP, and the Windows LDAP server enforces signing: Log Name: Directory Service Source: Microsoft-Windows-ActiveDirectory_DomainService Date: <Date and Time> Event ID: 2889 Task Category: LDAP Interface Level: Information Keywords: Classic User: ANONYMOUS LOGON Computer: <DC Name> Description: A client (Negotiate/Kerberos/NTLM/Digest) performs a SASL LDAP bind without requesting signing (integrity verification), or performs a simple bind over a clear text (non-SSL/TLS-encrypted) LDAP connection. This event is seen even though ONTAP is using a secure mechanism for binding to the LDAP server. In fact, the LDAP bind succeeds in this case and this event can be treated as a false positive. |
Workaround Formatted |
Use LDAP signing instead of sealing using the following commands: ::cluster> vserver cifs security modify -vserver <vserver> -session-security-for-ad-ldap sign ::cluster> vserver services name-service ldap client modify -vserver <vserver> -session-security sign |
Notes Formatted |
To confirm that ONTAP uses a secure LDAP mechanism, the network packet capture between the ONTAP LDAP client and the Windows LDAP server shows the following message as part of the binding process: GSS-API Generic Security Service Application Program Interface krb5_blob: 050406ff00000000000000002efb9660d29f1b1da2a94519... krb5_tok_id: KRB_TOKEN_CFX_WRAP (0x0405) krb5_cfx_flags: 0x06, AcceptorSubkey, Sealed <<<<<<<<<<<<<<< .... .1.. = AcceptorSubkey: Set .... ..1. = Sealed: Set <<<<<<<<<<<<<<< .... ...0 = SendByAcceptor: Not set krb5_filler: ff krb5_cfx_ec: 0 krb5_cfx_rrc: 0 krb5_cfx_seq: 788239968 krb5_sgn_cksum: d29f1b1da2a94519d08805bd9a38a94590c86f2bcc416d4c... <<<<<<<<<<<<<<< |
We managed to stop the LDAP warnings from the Domain Controllers by enabling 'seal' and 'use LDAPS for AD LDAP' - unfortunately, that triggered 'emergency' error alerts at the netapp end indicating that occasionally the netapp is unable to connect to any of our DCs at all... These were definitely not true, and the NetApp performed perfect well - apart from regular dire warnings in the event log.
So far, our support partners have been unable to establish what might be causing the emergency error warnings, or why they're occurring on an apparent regular schedule.
We're in the process of experimenting with various combinations of settings to get rid of the errors from both ends and still allow the netapp to work.
Does anyone know if this issue has been fixed? If so, which release?
Have you seen any additional guidance about this issue or determined the appropriate course of action? This deadline is fast approaching