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
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.
Comments
Post a Comment