Tuesday, 29 April 2014

Windows Security “Opening these files might be harmful...”

Thought this might be of a curious interest - worth a quick post...

I have two mappings to a share, one is mapped using the FQDN, the other mapped using just the HOSTNAME.

C:\Users\labrat>net use X: \\NASVM1-LOADBALANCER.lab.priv\testshare01
C:\Users\labrat>net use Y: \\NASVM1-LOADBALANCER\testshare01

I’ve got a few files in this share. Two of these files - a new ‘Briefcase’ and a new ‘Compressed (zipped) Folder’ exhibit an interesting behaviour.

In the share mapped using the FQDN, trying to open these files gives the:

Windows Security
Opening these files might be harmful to your computer

In the share mapped with the HOSTNAME, we don’t get any warning.

Image: FQDN mapped share and Windows Security warning
Image: HOSTNAME mapped share and no Windows Security warning

A fix is easy and covered in so many other forums and posts, so I’ll sign off for (April) now.

Cheers!

Sunday, 27 April 2014

Configuring IIS 7.5 for File Upload of CDOT System Configuration Backups

At the end of the Cluster Setup Wizard for a Single Node Cluster, it prompts for:

Enter the system config backup destination address (or press enter to skip this step):

If you’ve skipped this step, to configure the system config backup, either re-run “cluster setup” (pressing enter to everything except the ‘enter system config backup destination’) or run the following commands:

::> set -privilege advanced
::*> system configuration backup settings modify -destination URL -username USERNAME

{Where URL is an HTTP/HTTPS/FTP/SFTP address, and USERNAME is a user account with permissions to log into the web server}

First though, we might want a webserver to send the backups to, hence this post. And since most corporate customers aren’t going to accept freeware webservers in their environment, we’ll use IIS 7.5 that’s in Windows Server 2008 R2.

Setting up IIS 7.5 for Uploading Files

Log into your Windows Server 2008 R2 with a domain account that has administrative privileges...

Part 1: Configuring the Web Server (IIS) Role

Start > Administrative Tools > Server Manager > Roles > Add Roles

Add Roles Wizard: Select Server Roles
Select ‘Web Server (IIS)
Click Next >

Image 1: Add Server Roles ‘Web Server (IIS)’
Add Roles Wizard: Web Server (IIS)
Click Next >

Add Roles Wizard: Select Role Services
Leave the default selections checked, additionally tick:
WebDAV Publishing
Basic Authentication
URL Authorization
Click Next >

Image 2: Web Server Role Services section 1
Image 3: Web Server Role Services section 2
Add Roles Wizard: Confirm Installation Selections
Click Install

Add Roles Wizard: Installation Results
Click Close

Part 2) Configuring IIS 7.5 for File Uploads

Start > Administrative Tools > Internet Information Services (IIS) Manager

Right-click Sites and click Add Web Site...

Image 4: IIS 7.5 Add Web Site...
Note: We could instead have reconfigured the ‘Default Web Site’

Add Web Site
Site name = cdotbackup
Physical path = \\lab.priv\NA\backup {coincidentally, this is on a different NetApp CDOT cluster}
Connect as = LAB\netappadmin
Click Test Settings... to verify
Binding: Type = http / IP address = All Unassigned / Port = 80
Host name (optional) = cdotbackup.lab.priv
Leave ‘Start Web site immediately’ ticked
Click OK

Image 5: IIS 7.5 Configure new Web Site
Image 6: IIS 7.5 New Web Site Test Connection
Note: A DNS A-Record for cdotbackup.lab.priv will need to be created pointing to the IP Address of the Web Server.

Select the cdotbackup website and click the Authentication icon

Image 7: IIS 7.5 Web Site Icons
Authentication
Click ‘Anonymous Authentication’ and then click Disable in the right-hand ‘Actions’ pane
Click ‘Basic Authentication’ and then click Enable in the right-hand ‘Actions’ pane

Select the cdotbackup website and click the Authoritzation Rules icon

Authorization Rules
If there is not already an ‘Authorization Rule’ to ‘Allow’ ‘All Users’ -
Click ‘Add Allow Rule...’ in the right-hand ‘Actions’ pane

Authorization Rules: Edit Allow Authorization Rules
Leave ‘All users’ selected
Click OK

Image 8: IIS 7.5 Authorization Rules
Select the cdotbackup website and click the WebDAV Authoring Rules icon

WebDAV Authoring Rules
Click ‘Enable WebDAV’ in the right-hand ‘Actions’ pane
Click ‘Add Authoring Rule’ in the right-hand ‘Actions’ pane

WebDAV Authoring Rules: Add Authoring Rule
Allow access to: All content
Allow access to this content to: All users
Permissions: Read, Source, and Write
Click OK

Image 9: IIS 7.5 WebDAV Authoring Rules
Part 3) Testing System Configuration Backup Upload

From the Clustered ONTAP Single Node Cluster, type:

set -privilege advanced
system configuration backup show

Select a backup file to upload, then run:

system configuration backup upload -node NACLU01N1 -backup NACLU01.8hour.2014-04-27.18_15_00.7z -destination http://cdotbackup.lab.priv

And if all is good, you’ll be rewarded with ‘Configuration backup file uploaded successfully.’

NACLU01::> set -privilege advanced
NACLU01::*> system configuration backup show

Node       Backup Name                               Time               Size
---------  ----------------------------------------- ------------------ -----
NACLU01N1  NACLU01.8hour.2014-04-27.10_15_00.7z      04/27 11:15:00     1.04MB
NACLU01N1  NACLU01.8hour.2014-04-27.18_15_00.7z      04/27 19:15:00     1.24MB
NACLU01N1  NACLU01.daily.2014-04-27.07_23_48.7z      04/27 08:23:48     957.4KB
NACLU01N1  NACLU01.weekly.2014-04-27.07_23_48.7z     04/27 08:23:48     957.5KB

NACLU01::*> system configuration backup upload -node NACLU01N1 -backup NACLU01.8hour.2014-0-27.18_15_00.7z -destination http://cdotbackup.lab.priv

Enter the username: LAB\netappadmin
Enter the password:
Uploading the configuration backup file.
100% uploaded
Configuration backup file uploaded successfully.

Configure the backup settings to automatically use the URL and USERNAME tested previously for scheduled backups of the system configuration:

system configuration backup settings modify -destination URL -username USERNAME
system configuration backup settings set-password

To Do Next

If we were doing this in a production environment:
1) Lock down IIS.
2) Configure SSL on the website.
3) Append the SPNs required for Kerberos to function with the website.

(Possibly) To be continued...

Did you know you can Cascade DFS Namespaces?

This is one thing I didn’t know until today and I think it’s pretty cool! Why?

For example, we have a global corporate DFS namespace:

\\lab.priv\DFS

With a folder:

\\lab.priv\DFS\testshare that points to \\NASVM01-DATA1.lab.priv\testshare

But we want to give delegated permissions to a subset of this namespace (specifically, in this example, anything on NetApp) without changing the original DFS path, so we create a new namespace:

\\lab.priv\NA

And create a folder:

\\lab.priv\NA\testshare that points to \\NASVM01-DATA1.lab.priv\testshare

Then we simply change our original DFS folder:

\\lab.priv\DFS\testshare to point to \\lab.priv\NA\testshare instead!

Image 1: \\lab.priv\DFS\testshare pointing to \\lab.priv\NA\testshare
Image 2: \\lab.priv\NA\testshare pointing to \\NASVM01-DATA1.lab.priv\testshare
And test our \\lab.priv\DFS\testshare works via \\lab.priv\NA\testshare to get to \\NASVM01-DATA1.lab.priv\testshare and it does:

C:\Users\netappadmin>net use Z: \\lab.priv\DFS\testshare
The command completed successfully.

Then our DFS Administrator can delegate permissions for \\lab.priv\NA to a NetApp Administrator to control updating DFS links (such as adding a disabled secondary DR path, and/or flipping from a primary path to secondary path in the event of a DR failover situation.)

Image 3: DFS Delegate Management Permissions...

Is Kerberos Dependent on Reverse DNS Working?

I’m going to answer this question using a lab setup.

Part 1: The Lab Setup

Networks

10.0.0.0/16 used by Windows Servers
10.2.0.0/16 used by Windows Workstations
10.4.0.0/16 used by NetApp Clustered ONTAP Storage

Systems

ROUTER (Standalone in a workgroup)
O/S: Windows 2003 R2 SP1 Server
Roles: Routing and Remote Access, DHCP

Note: DHCP server Active Directory domain authorization has been overridden using the registry hack HKLM\SYSTEM\CurrentControlSet\Service\DHCP\Parameters and the REG_DWORD DisableRogueDetection = 0x01.

Image 1: Overriding DHCP server AD authorization requirements in Win. Server 2003
MSDMC01.lab.priv
O/S: Windows Server 2008 R2 SP1
Roles: Domain Controller, DNS
IP Address: 10.0.1.11
Forward DNS (ping MSDMC01.lab.priv): CONFIGURED (Automatically)

NASVM01.lab.priv
O/S: NetApp Clustered Data ONTAP 8.2.1 SVM
Roles: CIFS File Server
IP Address (Data LIF 1): 10.4.9.21
Forward DNS (ping NASVM01-DATA1.lab.priv): CONFIGURED (Manually)

MSW7W01.lab.priv
O/S: Windows 7
Roles: Workstation
IP Address: 10.2.1.101 (DHCP provisioned from ROUTER)
Forward DNS (ping MSW7W01.lab.priv): CONFIGURED (Automatically)

Note 1: Ensure the Windows Firewall is either turned off or ICMP echo is allowed to get ping response from Windows systems.
Note 2: Windows clients automatically ‘register this connection’s addresses in DNS’

Image 2: ‘Register this connection’s addresses in DNS’ (taken from MSW7W01)
DNS Reverse Lookup Zones

No DNS Reverse Lookup Zones have been configured!

Image 3: No DNS Reverse Lookup Zones
Note: When testing reverse DNS, you must do the ping -a not on the system that’s got that address. A localhost will always be able to ‘ping -a’ its own IP Address!

Reverse DNS ‘Ping -A’ Results

From MSW7W01.lab.priv:

C:\Users\labuser>ping -a 10.0.1.11

Pinging MSDMC01 [10.0.1.11] with 32 bytes of data:
Reply from 10.0.1.11: bytes=32

C:\Users\labuser>ping -a 10.4.9.21

Pinging NASVM01 [10.4.9.21] with 32 bytes of data:
Reply from 10.4.9.21: bytes=32

From MSDMC01.lab.priv:

C:\Users\Administrator>ping -a 10.2.1.101

Pinging MSW7W01 [10.2.1.101] with 32 bytes of data:
Reply from 10.2.1.101: bytes=32

We see that in the absence of DNS Reverse Lookup Zones being configured, a ping -a returns the NETBIOS name of the system.

Part 2: Testing

Testing without Kerberos

Firstly, we test access without Kerberos by accessing the CIFS file server and a share called ‘testshare’ from our Windows 7 workstation using the DNS name:

NASVM01-DATA1.lab.priv

Kerberos will not work since a Kerberos ticket is going to be requested for NASVM01-DATA1.lab.priv, and no machine account currently has that SPN (Service Principal Name) configured.

C:\Users\labuser>setspn -q HOST/NASVM01
Checking domain DC=lab,DC=priv
CN=NASVM01,OU=NA-CDOT,OU=~LAB-SYSTEMS,DC=lab,DC=priv
        HOST/nasvm01.lab.priv
        HOST/NASVM01

Existing SPN found!

C:\Users\labuser>setspn -q HOST/NASVM01-DATA1.lab.priv
Checking domain DC=lab,DC=priv

No such SPN found.

The following output shows successfully connecting to the testshare (and then deleting the connection):

C:\Users\labuser>net use Z: \\NASVM01-DATA1.lab.priv\testshare
The command completed successfully.

C:\Users\labuser>net use
Status       Local     Remote                    Network
-------------------------------------------------------------------------
             Z:        \\NASVM01-DATA1.lab.priv\testshare
                                                Microsoft Windows Network

C:\Users\labuser>net use Z: /delete
Z: was deleted successfully.

Re-Testing with NTLM Disabled (Restricted) on the Domain

We disable NTLM on our domain by editing the ‘Default Domain Controllers Policy’ as below:

Start -> Administrative Tools -> Group Policy Management
Default Domain Controllers Policy -> Edit
Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options
Network Security: Restrict NTLM: NTLM authentication in this domain
Define this policy setting
Deny all

Image 4: Restrict NTLM authentication in this domain - Deny all
Run gpupdate on the domain controller to ensure the GPO is applied:

C:\Users\Administrator>gpupdate
Updating Policy...

User Policy update has completed successfully.
Computer Policy update has completed successfully.

Test access to \\NASVM01-DATA1.lab.priv\testshare from our Windows 7 workstation (I’ve rebooted it and re-logged in before doing the test, which I do before every test), and it fails as we’d expect:

C:\Users\labuser>net use Z: \\NASVM01-DATA1.lab.priv\testshare
System error 59 has occurred.

An unexpected network error occurred.

From the DC, we add in the SPN for NASVM01-DATA1.lab.priv:

C:\Users\Administrator>setspn -a HOST/NASVM01-DATA1.lab.priv NASVM01

And the from the Windows 7 workstation (after reboot) test access to \\NASVM01-DATA1.lab.priv\testshare again, and it works:

C:\Users\labuser>net use Z: \\NASVM01-DATA1.lab.priv\testshare
The command completed successfully.

C:\Users\labuser>net use
Status       Local     Remote                    Network
-------------------------------------------------------------------------
             Z:        \\NASVM01-DATA1.lab.priv\testshare
                                                Microsoft Windows Network

These are the SPNs as seen from the workstation:

C:\Users\labuser>setspn -q HOST/NASVM01
Checking domain DC=lab,DC=priv
CN=NASVM01,OU=NA-CDOT,OU=~LAB-SYSTEMS,DC=lab,DC=priv
        HOST/NASVM01-DATA1.lab.priv
        HOST/nasvm01.lab.priv
        HOST/NASVM01

And at no time did we have Reverse DNS configured (we didn’t even have the Reverse DNS zones on our DNS server) as seen from the workstation ‘pinging -a’ to the CIFS server (just returns its NETBIOS name):

C:\Users\labuser>ping -a 10.4.9.21
Pinging NASVM01 [10.4.9.21] with 32 bytes of data:
Reply from 10.4.9.21: bytes=32

And from the domain controller to the workstation (again, just returns its NETBIOS name):

C:\Users\Administrator>ping -a 10.2.1.101
Pinging MSW7W01 [10.2.1.101] with 32 bytes of data:
Reply from 10.2.1.101: bytes=32

We’ve answered the question:

Kerberos - at least with Windows 2008 R2 SP1, Windows 7 SP1, and Clustered Data ONTAP 8.2.1 - is not dependent on Reverse DNS being configured!

Note: Being thorough, I powered off the workstation, then powered it up a few minutes later, and logged in with a different user to test, and it continues to work.

APPENDIX A: An Interesting Registry Option

I found in this article http://support.microsoft.com/kb/837361 the following:

Entry: ClientIpAddress
Type: REG_DWORD
Default Value: 0 (This setting is 0 because of Dynamic Host Configuration Protocol and network address translation issues.)
Possible values: 0 (false) or any non-zero value (true)

This value indicates whether a client IP address will be added in AS_REQ to force the Caddr field to contain IP addresses in all tickets.

Checking on my Windows 7 Workstation, and Windows 2008 R2 Domain Controller, this DWORD does not exist, so we’re using the default value of 0. Infact HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters is pretty empty.

Image 5: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
The article was for Windows Server 2003, but it left me thinking that if reverse DNS checks were a requirement, this registry option would need to be set to true, or at least that the default behaviour in Windows Operating systems since Windows Server 2003 (and perhaps earlier) is not to do reverse DNS checks. And NetApp Clustered ONTAP 8.2.1 is not configured out of the box to do these reverse DNS checks for Kerberos either.

APPENDIX B: Further Reading

Kerberos protocol registry entries and KDC configuration keys in Windows Server 2003

MIT Kerberos Documentation

Appendix D: Kerberos and LDAP Troubleshooting Tips

Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability
“The Microsoft Windows 2000 operating system implementation of the Kerberos version 5 protocol ...”

Kerberos (protocol)

Saturday, 26 April 2014

Configuring On-Box DNS Load-Balancing in Clustered ONTAP

The following post runs though configuring On-Box DNS Load-Balancing in Clustered ONTAP in 2 steps:

Step 1 - Configuration of the DNS Zone on the SVM (using a simple example to demonstrate this)
Step 2 - Configuring a DNS Delegation in Windows Server 2008 R2 DNS

Step 1 of 2: Configuration of the DNS Zone on the SVM

We have a SVM (Storage Virtual Machine) NASVM01.lab.priv with two data LIFs. Currently the LIFs are not configured with a DNS zone as below:

NACLU01::> net int show -fields dns-zone,listen-for-dns-query -vserver NASVM01.lab.priv
 vserver          lif  dns-zone listen-for-dns-query
---------------- ---- -------- --------------------
NASVM01.lab.priv lif1 none     false
NASVM01.lab.priv lif2 none     false

We configure a DNS zone NASVM01-LB.lab.priv with the commands:

NACLU01::> net int modify -vserver NASVM01.lab.priv -lif lif1 -dns-zone NASVM01-LB.lab.priv
NACLU01::> net int modify -vserver NASVM01.lab.priv -lif lif2 -dns-zone NASVM01-LB.lab.priv

And that’s that, super simple - one command per LIF and we’ve configured DNS Load-Balancing on the SVM!

NACLU01::> net int show -fields dns-zone,listen-for-dns-query -vserver NASVM01.lab.priv
vserver          lif  dns-zone            listen-for-dns-query
---------------- ---- ------------------- --------------------
NASVM01.lab.priv lif1 NASVM01-LB.lab.priv true
NASVM01.lab.priv lif2 NASVM01-LB.lab.priv true

Step 2 of 2: Configuring a DNS Delegation for CDOT On-Box Load-Balancing

Our DNS domain is called lab.priv and we want to create a delegation for NASVM01-LB.lab.priv.

Note: We cannot use conditional forwarders in this instance since our NASVM01-LB.lab.priv is effectively a child DNS domain of lab.priv.

In DNS Manager (using Windows Server 2008 R2), right-click the lab.priv Forward Lookup Zone and select ‘New Delegation...

Image 1: DNS Manager in Windows Server 2008 R2
New Delegation Wizard: Welcome...
Click Next >

New Delegation Wizard: Delegated Domain Name
Specify NASVM01-LB as the delegated domain
Click Next >

Image 2: NDW - Delegated Domain Name
New Delegation Wizard: Name Servers
Add... the IP Addresses of the two data LIFs as name servers for the delegated zone (can use the IP address for ‘Server fully qualified domain name (FQDN)’ and ‘IP Addresses of this NS record’)
Click Next >

Image 3: NDW - Name Servers
New Delegation Wizard: Completing...
Click Finish

Image 4: NDW - Complete
The DNS delegation of NASVM01-LB.lab.priv in the DNS domain lab.priv is complete.

Image 5: DNS Manager and the Delegated Zone NASVM01-LB.lab.priv

Testing

Test by pinging NASVM01-LB.lab.priv multiple times:

C:\Users\netappadmin2>ping NASVM01-LB.lab.priv

Pinging NASVM01-LB.lab.priv [10.0.9.21] with 32 bytes of data:
Reply from 10.0.9.21 ...

C:\Users\netappadmin2>ping NASVM01-LB.lab.priv

Pinging NASVM01-LB.lab.priv [10.0.9.22] with 32 bytes of data:
Reply from 10.0.9.22 ...

Minimal Active Directory Permission for Domain Join (+ Bonus Material)

In the following post, we allow a NetApp administrator (called “netappadmin”) to join a system to Active Directory with the minimal permissions to do so. The scenario is for a NetApp administrator, but the theory can be applied to any situation where you want to give an administrator/user the minimum permissions to join a system to AD.

Step By Step Guide

Note: Steps 1 to 11 are all done in Active Directory Users and Computers (ADUC)

Step 1) Being tidy AD administrators, first we create a new Global Security group called “naadmins”.

Image 1: Global Security group “naadmins”
Step 2) Then we add this group to our “netappadmin” user account.

Image 2: netappadmin in naadmins group
Step 3) Next, create an OU for our NetApp systems - here we call it “NA-CDOT”
Step 4) And in our OU “NA-CDOT”, create a new AD Machine account with the name of the CIFS server that’s going to be joined - here we call in “NASVM01”.

Image 3: NASVM01 AD Computer account in the OU “NA-CDOT”
Step 5) Right-click on the OU “NA-CDOT” and select ‘Delegate Control...

Image 4: Delegate Control of the OU “NA-CDOT”
Step 6) Delegation of Control Wizard: Welcome ...
Click Next >

Step 7) Delegation of Control Wizard: Users or Groups
Add the “naadmins” group
Click Next >

Image 5: DoCW - adding the naadmins group
Step 8) Delegation of Control Wizard: Tasks to Delegate
Select the ‘Create a custom task to delegate
Click Next >

Image 6: DoCW - Tasks to Delegate
Step 9) Delegation of Control Wizard: Active Directory Object Type
Select the ‘Only the following objects in the folder
Tick the ‘Computer objects’ check box
Click Next >

Image 7:DoCW - Active Directory Object Type
Step 10) Delegation of Control Wizard: Permissions
Tick the ‘Creation/deletion of specific child objects’ check box
And from the ‘Permissions‘ list:
Tick ‘Reset password
Tick ‘Read and write account restrictions
Tick ‘Validated write to DNS host name
Tick ‘Validated write to service principal name
Click Next >

Image 8: DoCW - Permissions (‘Reset password’ is not on screen)
Step 11) Delegation of Control Wizard: Completing...
Click Finish

Step 12) Test it works!

NACLU01::> cifs server create -cifs-server NASVM01 -domain lab.priv -vserver NASVM01.lab.priv       
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...

Enter the user name: netappadmin

Enter the password:

Warning: An account by this name already exists in Active Directory at
         CN=NASVM01,OU=NA-CDOT,OU=~LAB-SYSTEMS,DC=lab,DC=priv
         Ok to reuse this account? {y|n}: y

NACLU01::> cifs server show
            Server          Status    Domain/Workgroup Authentication
Vserver     Name            Admin     Name             Style
----------- --------------- --------- ---------------- --------------
NASVM01.lab.priv NASVM01    up        LAB              domain

BONUS 1: Allowing NetApp administrators to update their system’s Service Principal Names (SPNs)

In ‘Delegation of Control Wizard: Permissions’ (Step 10 above) there is an additional permission that could be really useful for your NetApp administrator to have (if you’ve been reading some of my recent posts on Kerberos, SPNs, and site failover.) In the ‘Property-specific’ section, there is the permission ‘Write servicePrincipalName’ which will allow your NetApp administrator to delete and append SPNs to their NetApp CIFS Server’s machine account.

Image 9: DoCW - Add the permission ‘Write servicePrincipalName’
BONUS 2: Active Directory Permissions to allow AD Computer Account Domain Join

The following security options cannot be specified on an OU, but, if you’re Active Directory administrator does not want to delegate permission of an OU, they could just assign the following permissions on the AD computer account for the NetApp Administrator:

Reset password = Allow
Validated write to DNS host name = Allow
Validated write to service principal name = Allow
Read account restrictions = Allow
Write account restrictions = Allow

Note: For allowing a NetApp Administrator to update SPNs (as in BONUS 1), there are no options under the AD Computer Accounts security settings to allow this, it needs to be done using Delegation of Control.

THE END

Enabling LDAP over SSL with Windows Server 2008 R2 SP1


The following takes you through setting up LDAP over SSL from the server side of a Windows 2008 R2 SP1 Domain Controller.

Note: It just happens to be the minimum required to force a NetApp CDOT 8.2.1 SVM to have to have LDAP over SSL properly configured before it can join the Active Directory Domain.

My Lab Setup

My lab setup is simply a single Windows Server 2008 R2 SP1 Domain Controller - called MSDMC01 - in the domain LAB.PRIV. And we start with a pretty much out of the box Domain Controller setup.

Step 1 of 3: Enablement in the Default Domain Controllers Policy

Start > Administrative Tools > Group Policy Management
Find the ‘Default Domain Controllers Policy’, right-click and click Edit...

Image 1: Group Policy Management
In the ‘Group Policy Management Editor: Default Domain Controllers Policy’
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
Find the policy ‘Domain controller: LDAP server signing requirements’, right-click and click Properties

Image 2: Group Policy Management Editor
Domain controller: LDAP server signing requirements
Ensure that the ‘Define this policy setting’ box is ticked
Change the drop-down menu to ‘Require signing
Click OK
Click Yes to the ‘Confirm Settings Change’ box

Image 3: Domain controller - LDAP server signing requirements Properties
Close the ‘Group Policy Management Editor’ window.
Close the ‘Group Policy Management’ window.

Then, from the Domain Controller, open a DOS Command Prompt and type the following command to update the policy on the Domain Controller.

gpupdate

Note: The GPO setting isn’t applied until the registry setting - HKLM\SYSTEM\CurrentControlSet\services\NTDS\Parameters and DWORD ‘ldapserverintegrity’ has changed from the default 1 to the new setting of 2. If you manually change in the registry without updating the Default Domain Controllers GPO, it will go back to 1 after every gpupdate.

Image 4: Registry Editor
Step 2 of 3: Setting up an Enterprise Root CA

Server Manager > Roles > Add Roles

Add Roles Wizard: Select Server Roles
Tick the ‘Active Directory Certificate Services’ box and click Next >

Image 5: Add Roles Wizard
Add Roles Wizard: Introduction to Active Directory Certificate Services
Click Next >

Add Roles Wizard: Select Role Services
Tick the ‘Certification Authority’ box only
Click Next >

Image 6: AD CS - Select Role Services
Note: Later on - but not required for what we want to achieve here - I will install ‘Certification Authority Web Enrollment’ so I can request certificates from the domain certification authority.

Add Roles Wizard: Specify Setup Type
Choose ‘Enterprise’ to set up an Enterprise CA
Click Next >

Image 7: AD CS - Specify Setup Type
Add Roles Wizard: Specify CA Type
Choose ‘Root CA
Click Next >

Image 8: AD CS - Specify CA Type
Add Roles Wizard: Set Up Private Key
Choose ‘Create a new private key’ (since this is a new CA)
Click Next >

Image 9: AD CS - Set Up Private Key
Add Roles Wizard: Configure Cryptography for CA
Leave as the default settings which are sufficient for our requirements:
Cryptographic service provide (CSP) = RSA#Microsoft Software Key Storage Provider
Key character length = 2048
Hash algorithm for signing certificates issued by this CA = SHA1
‘Allow administrator interaction when the private key is accessed by the CA’ = unticked
Click Next >

Image 10: AD CS - Configure Cryptography for CA
Add Roles Wizard: Configure CA Name
Leave as the default populated settings which are sufficient for our requirements:
Common name for this CA = lab-MSDMC01-CA
Distinguished name suffix = DC=lab,DC=priv
Preview of distinguished name = CN=lab-MSDMC01-CA,DC=lab,DC=priv
Click Next >

Image 11: AD CS - Configure CA Name
Add Roles Wizard: Set Validity Period
Leave as the default settings which are sufficient for our requirements:
Validity period for certificate generated for this CA = 5 years
Click Next >

Image 12: AD CS - Set Validity Period

Add Roles Wizard: Configure Certificate Database
Leave as the default settings which are sufficient for our requirements:
Certificate database location = C:\Windows\system32\CertLog
Certificate database log location = C:\Windows\system32\CertLog
Click Next >

Image 13: AD CS - Configure Certificate Database
Add Roles Wizard: Confirm Installation Selections
Click Install

Image 14: AD CS - Confirm Installation Selections
Add Roles Wizard: Installation Results
Click Close

Step 3 of 3: Obtaining the Root CA Certificate

On our Enterprise Root CA Domain Controller, 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 a simple text document. This will need to be provided to the clients wanting to establish LDAP over SSL connections, so they can install the root CA certificate first.

certutil
certutil -ca.cert CA_root_cert

And that’s it!

Example of the output using certutil and certutil -ca.cert:

C:\Users\Administrator>certutil
Entry 0: (Local)
  Name:                         `lab-MSDMC01-CA'
  Organizational Unit:          `'
  Organization:                 `'
  Locality:                     `'
  State:                        `'
  Country/region:               `'
  Config:                       `MSDMC01.lab.priv\lab-MSDMC01-CA'
  Exchange Certificate:         `'
  Signature Certificate:        `MSDMC01.lab.priv_lab-MSDMC01-CA.crt'
  Description:                  `'
  Server:                       `MSDMC01.lab.priv'
  Authority:                    `lab-MSDMC01-CA'
  Sanitized Name:               `lab-MSDMC01-CA'
  Short Name:                   `lab-MSDMC01-CA'
  Sanitized Short Name:         `lab-MSDMC01-CA'
  Flags:                        `13'
  Web Enrollment Servers:       `'
CertUtil: -dump command completed successfully.

C:\Users\Administrator>certutil -ca.cert CA_root_cert
CA cert[0]: 3 -- Valid
CA cert[0]:
-----BEGIN CERTIFICATE-----
MIIDYzCCAkugAwIBAgIQbkWjIrQBqr9MYH6LuvOa7jANBgkqhkiG9w0BAQUFADBE
MRQwEgYKCZImiZPyLGQBGRYEcHJpdjETMBEGCgmSJomT8ixkARkWA2xhYjEXMBUG
A1UEAxMObGFiLU1TRE1DMDEtQ0EwHhcNMTQwNDI2MTYwNjE3WhcNMTkwNDI2MTYx
NjE2WjBEMRQwEgYKCZImiZPyLGQBGRYEcHJpdjETMBEGCgmSJomT8ixkARkWA2xh
YjEXMBUGA1UEAxMObGFiLU1TRE1DMDEtQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQDVR1jxp1Sazi88OXWECAPZAdcUdaaXOIlquSV/2vZGz548zeVX
GxJmV2MIte0IPe+q7RMcjgCW9espkGG1LjkZdKtxA9zAvZJY3zhpZzCbAinP9aIO
CnopICoQ5OPK5wWpJvn18yWfOJiJOeIG/TK71YPzE2yxRNZv0ouSlflq2522Gutr
EAW+KrSsXs03G2KVY6iVZ9A+k/cfZN/G1v4DRElwqmXuCMxRcdQWkd8FNHJ4dYx6
Nvq1DmroWxn/zicBkUHz0aKbuQSM0P1M/LFTA7lGCosbjT+q8Bc37oGlci2vVTOS
JXv+Qxx/y/epOmkBJilf112uch+npWViMnPPAgMBAAGjUTBPMAsGA1UdDwQEAwIB
hjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSVo87stQ2puh0s37snZtHOC0SN
BTAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQUFAAOCAQEACVC9UENQQuy+
OuC7M/pHns+d233j7PofbkFZ/a87WdePGUWEAfnYJYhXAWcV4HoM1WHZhqG408tV
CsfYS5NXCXrqIM5hNF+I+qnqA5aS0aPICIfBspOFDJqvcgj0bBPwKXRbRmBdizHe
pdNgzxR7RZgoDdorjNeAfmdkXEPoHKN4B9nQjtKSZGyXJxg0RUFUmGBadoNRSiGp
KNzmNQLsTLWszKarzqAjkfO5gN9oIOrVt1GFhkgxEfd6pUkTznm48CfrKSV62SMw
/b6Lqx0o/3mkuUUgMgJLUB21Os6z8XBtLFwA847vJNoi3SoLpjZE9+b+rf1r163C
qO2+O6CqYw==
-----END CERTIFICATE-----

CertUtil: -ca.cert command completed successfully.