a week ago
I have a A200 with ONTAP 9.3 and I need to add it to AD which uses LDAPS. I have enabled the Use start_tls for AD LDAP connection: true and we also imported the certificate. But the CIFS setup process fails
Error: Machine account creation procedure failed [ 7810] Loaded the preliminary configuration. [ 7865] Successfully connected to ip 149.x.x.x, port 88 using TCP [ 8056] Successfully connected to ip 149.x.x.x, port 389 using TCP [ 8134] Unable to start TLS: Connect error [ 8134] Additional info: error:14090086:lib(20):func(144):reason(1 34) [ 8134] Unable to connect to LDAP (Active Directory) service on dc01.ad.neco.com **[ 8134] FAILURE: Unable to make a connection (LDAP (Active ** Directory):AD.NECO.COM), result: 7652 Error: command failed: Failed to create the Active Directory machine account "FILE99". Reason: LDAP Error: Cannot establish a connection to the server.
What could be wrong? The time is in sync.
Solved! SEE THE SOLUTION
check the CIFS security option "Use start_tls for AD LDAP connection"
"cifs security show -vserver <svm>"
If that is enabled, try disabling it and re-running cifs setup. Alternately check the certificate is valid.
Use start_tls for AD LDAP connection was enabled and the certificate is imported. Before the upgrade from 8.3xxx to 9.1P9 it worked without Problems.
Our Workaround was to enable LDAP signing/sealing (Client Session Security = seal) and disable the options "start_tls for AD LDAP connection".
Now the access works, but our DC admins see sometimes following error in the event log:
Event Description: The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing (integrity verification), or performed a simple bind over a clear text (non-SSL/TLS-encrypted) LDAP connection.
So my thoughts was to enable "start_tls for AD LDAP connection" simultaneously to elimate the DC errors, but when I enable this I can't connect to DC anymore.
cifs security modify -vserver svm1 -use-start-tls-for-ad-ldap true
diag secd authentication get-dc-info -node node1 -vserver svm1
Error: command failed: RPC call to SecD failed. RPC: "SecD Error: no server available". Reason: "".
We have found our Problem:
On the DC we seen following Error:
On the DCs more than one certificate is installed. I installed the second certificate on the svm (security certificate install -type server-ca -vserver svm1).
After that i have reenabled the Option "use-start-tls-for-ad-ldap" and voila it worked again.
That makes sense, I looked into some internal KB articles which suggested a mismatched Server CA certificate between what the LDAP servers are using and the one that is installed for the SVM/CIFS server. If TLS is required then check the SVM certificate is correct.
how to check that the certificate is correct? We have deleted and installed the cert again. It didn't help.
If you seatch for error message
Additional info: error:14090086:lib(20):func(144):reason(134)
it is about the cert trust. How to trouble shoot it on both sides - netapp and AD?
yesterday - last edited yesterday
We have following Situation:
In the personal certification store on the DC server we have certificates issued by the company CA, which we have installed also in the svm (security certificate install). With this combination we encountered "Additional info: error:14090086:lib(20):func(144):reason(134)" Errors. Subsequently we installed also the certificate issued by Domain CA in the svm.
security certificate show -vserver svm1
Vserver Serial Number Common Name Type
---------- --------------- -------------------------------------- ------------
svm1 06FFCFFAC88CB9B34454E628858B0FC2 company CA server-ca
Certificate Authority: company CA
svm1 5F4CC1BFA244B7BF4301062863ABF4A2 domain CA server-ca
Certificate Authority: domain CA
After that LDAP over TLS works without problems.
I hope this helps
20 hours ago
it was incorrect certificate. They insisted that the cert is correct and there is no other. Then they found another cert and it worked.
The error "Additional info: error:14090086:lib(20):func(144):reason(134)" means that the cert is not trusted. You can also see in the log above that the Netapp connects successfuly to DC on port 389. The initial connection is in plain text and after that it tries to upgrade to encrypted connection using the cert. And it fails if the cert is wrong.