Thursday, 3 April 2014

Troubleshooting CDOT CIFS Server Create Failed “Strong(er) authentication required”

Scenario

Running through vserver setup for a multiprotocol NFS and CIFS vserver on a Clustered ONTAP 8.2.1RC2 Cluster, we encounter the following error “Error: Strong(er) authentication required” at “Step 6: Configure CIFS” as in the example below:

Step 6: Configure CIFS.

Do you want to configure CIFS? yes
Enter the CIFS server name: CIFSV1
Enter the Active Directory domain name: DOMAIN.COM

In order to create an Active Directory machine account for the CIFS server, you must supply the name and password of a Windows account with sufficient privileges to add computers to the "CN=Computers" container within the "DOMAIN.COM" domain.

Enter the user name: USERNAME
Enter the password: XXXXXXXX
Error: Failed to create CIFS server. Reason: Failed to create the Active Directory machine account "CIFSV1". Reason: SecD Error: Cannot find an appropriate domain controller.

Error: Machine account creation procedure failed
[0 ms] Trying to create machine account 'CIFSV1' in domain 'DOMAIN.COM' for virtual server 'CIFSV1'
[2] Found 1 domain controllers through DNS
[3] Connecting to LDAP (Active Directory) server DMC.DOMAIN.COM (128.209.1.10) as USERNAME@DOMAIN.COM
**[4] FAILURE: 'CifsServer' configuration not available
[6] Unable to connect to DMC.DOMAIN.COM through the X.X.X.X interface (Error: Strong(er) authentication required)
[6] No servers available for MS_LDAP_AD, vserver: 8, domain: DOMAIN.COM.
[6] Cannot connect to any domain controllers

We’ve checked on http://support.netapp.com/matrix that our domain controllers are using a qualified version of Windows Server (for reference, the list for 8.2.1RC2 is: 2003 SP2, 2003R2 SP2, 2008 SP2, 2008R2 SP1, 2012, 2012R2 and all x86/x64 varieties and better SP’d versions in between.)

Trying to Recreate the Error

So, in a lab with a Windows 2008R2 SP1 Domain Controller (fresh build) and Data ONTAP 8.2.1RC2 single node cluster, I set about trying to recreate the error. And it quickly became apparent that this might be something to do with LDAP signing. So, I enable all the following in the Default Domain Policy GPO and I still have absolutely no problem joining to the domain…

Default Domain Policy GPO >

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options>

Domain controller: LDAP server signing requirements = Require signing
Microsoft network client: Digitally sign communications (always) = Enabled
Microsoft network server: Digitally sign communications (always) = Enabled
Network security: LDAP client signing requirements = Require signing

Recreating the Error

It finally turned out to be the following registry setting on the domain controller that needed to be changed, and after that I was getting the same “Error: Strong(er) authentication required” as in the original scenario:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
In the left pane, right-click ldapserverintegrity, and then click Modify
Type 2 for Value data to configure the server to reject simple or unsigned LDAP bind requests, and then click OK.

CORRECTION: It should have been in the Default Domain Controllers GPO to which I was applying 'Domain controller: LDAP server signing requirements = Require signing'. When the GPO is applied this sets ldapserverintegrity to 2. If you manually set it to 2 without the policy being set, it goes back to 1 after the GPO refreshes. See this updated post for more information: Enabling LDAP over SSL with Windows Server 2008 R2 SP1

How to Fix

1. Change the registry option on the domain controller back to 1

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
ldapserverintegrity = 1

Note: Even turning off all the GPOs previously listed above did not make the CDOT CIFS server join happen!

2: Configuring LDAP over SSL/TLS (see the File Access Management Guide for CIFS for more detail)

2.1 Enabling LDAP over SSL/TLS on the CIFS server

vserver cifs security show -vserver SVM
vserver cifs security modify -vserver SVM -use-start-tls-for-ad-ldap true

2.2 Exporting a copy of the self-signed root CA certificate

Note: The role “Active Directory Certificate Services*” must already be installed and configured for the domain to which the CIFS server belongs.

On a Domain Controller which has ADCS and the self-signed root CA certificate, run the following commands from the DOS prompt (>) to obtain the self-signed root CA certificate, and copy all the output between and including the BEGIN CERTIFICATE and END CERTIFICATE lines into notepad or your clipboard (we use this output in the next step):

> certutil
> certutil -ca.cert CA_root_cert

-----BEGIN CERTIFICATE-----
MIIDjzCCAnegAwIBAgIQOf515hzAc45FRjjdCposkTANBgkqhkiG9w0BAQUFADBa
MRQwEgYKCZImiZPyLGQBGRYEaHNiYzEWMBQGCgmSJomT8ixkARkWBmFkcm9vdDEU
… output abridged …
fM1UTs2dkVWlc9ZX+mU09HdoY9F4DxbHjFeoJFfqt3tMmidtXBqrQeyaEChnPE+b
HvZ+K9iqWM/7q6jaXD6RzZbBNJdNIWFKGgcdMKQiVEi+GbJd3fai805v9bXRWVvZ
S7Wx
-----END CERTIFICATE-----

*If you’re installing ADCS on a DC in a test lab, the following options will work (2008R2 SP1) fine in the ‘Add Roles Wizard’: Certification Authority (select only) > Enterprise > Root CA > Create a new private key > RSA 2048 SHA1 (Default) > CA Name (Default) > 5 year validity (Default) > Certificate Database Location (Default) > Install!

Note i: The name after “certutil -ca.cert” doesn't matter one jot, you can call it anything you like, we only care about the output.
Note ii: Another option to obtain the self-signed root CA instead of using certutil, would be to download it from http://IP_Address_Of_Certification_Authority_Server/certsrv

2.3 Installing the self-signed root CA certificate on the SVM

Via the clustershell (::>), enter the following command, and paste in the content obtained in part 2.2 as below:

::> security certificate install -vserver SVM -type server-ca

Please enter Certificate: Press when done
-----BEGIN CERTIFICATE-----
MIIDjzCCAnegAwIBAgIQOf515hzAc45FRjjdCposkTANBgkqhkiG9w0BAQUFADBa
MRQwEgYKCZImiZPyLGQBGRYEaHNiYzEWMBQGCgmSJomT8ixkARkWBmFkcm9vdDEU
… output abridged …
fM1UTs2dkVWlc9ZX+mU09HdoY9F4DxbHjFeoJFfqt3tMmidtXBqrQeyaEChnPE+b
HvZ+K9iqWM/7q6jaXD6RzZbBNJdNIWFKGgcdMKQiVEi+GbJd3fai805v9bXRWVvZ
S7Wx
-----END CERTIFICATE-----

You should keep a copy of the CA-signed digital certificate for future reference.

::> security certificate show -vserver SVM
Vserver    Serial Number   Common Name                            Type
---------- --------------- -------------------------------------- ------------
SVM     533D621A        SVM.cert                            server
    Certificate Authority: SVM.cert
          Expiration Date: Fri Apr 03 13:28:58 2015

SVM     39FE75E61CC0738E454638DD0A9A2C91
                           domain-DC1-CA                            server-ca
    Certificate Authority: domain-DC1-CA
          Expiration Date: Thu Apr 04 00:05:35 2019

Then try the CIFS domain join and it will work! Hurray!

Why 7-Mode Seems Unaffected

Interestingly, 7-Mode seems unaffected by the about GPOs and registry setting - it connects regardless, even with options ldap.ssl.enable off and …

“As for 7-Mode vs CDOT and the GPO settings - remember that 7-mode will use LDAP Signing if it is asked, that is what the option ldap.security.level setting of 1 is - it basically says ‘if signing is needed then use it.’  So 7-Mode would work regardless of the DC setting.  However, if CDOT encounters a DC that requires it then you must have it configured.”

option ldap.security.level
Level 0: No signing. SASL bind is used
Level 1: Use LDAP signing (Default)
Level 2: Use LDAP signing and sealing

An Aside: Minimal Permission for Active Directory Join

Trying to simulate the original environment most closely, I discovered how to delegate to an OU the minimal permissions for a user/group, to enable them to join a pre-created machine account to AD.

Permission for add computer accounts to a Domain
The permissions required to join a computer to the domain are:
Reset Password
Validated write to DNS host name
Validated write to service principal name
(Read and) Write Account Restrictions

Right-click the OU and choose Delegate Control:

Image: Delegating Control to an OU

Delegation of Control Wizard:
- Choose your users/groups
- Create a custom task to delegate
- Only the following objects in this folder: Computer objects
- The from the Permissions General selections, choose the 4 items above

Ideas for AD Information Requests

If you don’t have access to AD but you want to find out the GPO settings that are applied to a machine and its user, use the following command -


C:DOS> gpresult /v |more

- or Group Policy Modeling Wizard in GPMC (Group Policy Management Console) - this produces a report that can be saved as an HTML file!

Image: GPMC Modelling - Save Report

An alternative would be to run RSOP (Resultant Set of Policy) Planning from ADUC (Active Directory Users and Computer), but this does not produce a nice report!

Collected Research

cDOT 8.2p4 problems joining AD - (Error: Strong(er) authentication required)

Microsoft LDAP Error Codes
LDAP_STRONG_AUTH_REQUIRED 0x08 (Strong authentication is required)

Event ID 2886 — LDAP signing
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
ldapserverintegrity = 2

ldapserverintegrity resets from 2 to 1 - Solved
“I solved this by changing the following setting in Default Domain Controllers Policy (as opposed to Default Domain Policy) -
Security Options > Domain controller: LDAP server signing requirements
- make sure this policy setting is Defined, and change it from None to Require Signing.”

Require SMB Security Signatures (2008R2 / 2012)
HKLM\System\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature

Overview of Server Message Block signing

Error: "Strong(er) authentication required" - Unable to connect to AD Server
LDAP supports two kinds of bind calls, Simple_Bind and SASL (Simple Authentication and Security Layer).
Simple_Bind calls can either be anonymous over port 389, or a user/pass can be passed to the Domain Controller/LDAP Server to obtain more information (such as user/group membership).
SASL is a much stronger authentication method that can require a signed certificate or other method of authenticating the user.

No comments:

Post a Comment