vCenter server appliance AD integration and SSO configurations

Or, How integrate vCenter server appliance 6.0 with Active Directory?

Or, How to configure SSO on vCenter server appliance 6.0?

Or, AD Integration of vCenter server appliance

Descriptions: To be able to sign-in in vCenter server with AD account or to able to use SSO you must enable AD integration with vCenter server and enable SSO. There has been multiple articles where it’s confusing to understand what is difference between SSO and AD integration of vCenter server and what you actually need to be able to use your AD credentials for login in to the vCenter server…

Friends, so far as per my understanding, the difference between AD integration and SSO configuration is as below:

AD integration is just joining your vCenter server appliance in AD domain, as you do for windows machines (joining a workgroup windows machine in domain).

SSO (Single Sign On) configuration is adding your domain in Identify Sources section under SSO configuration of vCenter server to synchronize all AD users in vCenter Users and Group section so that you can add these AD users latter in vCenter Server’s different roles to grant them access of vCenter server.

This way, you can use your single account for login in your windows machine and vCenter server. This where the SSO requirements meets.

Steps: AD integration of vCenter server

Login to vSphere web console with administrator@vsphere.local account > Go to Systems Configurations

Click on Nodes under System Configuration> Select the vCenter Server appearing under Nodes

Click on Manage > Settings > Active Directory

Click on Join

Provide all the required details as reference shown in the below screenshot and Click OK.  As soon as you click OK, the virtual appliance will be reboot to take the changes in effect.

--------------------------------------------------------------------------------------------------------------------------

To know more what details to provide in which field, refer the below notes:

Domain : Active Directory domain name, for example, TechiesSphere.com. Do not provide an IP address in this field.

Organizational unit: The full OU LDAP FQDN, for example, OU=Engineering,DC=TechiesSphere,DC=com. Use this field only if you are familiar with LDAP.

User name: User name in User Principal Name (UPN) format, for example, domainadmin@techiessphere.com. Down-level login name format, for example, DOMAIN\UserName, is unsupported.

Password: Password of the user.

--------------------------------------------------------------------------------------------------------------------------

After reboot, when you will come back to this page again, you would be able to see your domain name, Join button is grayed out, and Leave button is available.

Steps: SSO (Single Sign On) Configuration

Login to vSphere Web Client > Go to Administration

Go to Configuration > Identity Sources > Click on + sign

Select Active Directory (Integrated Windows Authentication) > Provide other required details > OK

To verify if the configuration is completed, Go to Users and Groups > Users > Under Domain section, click on Down arrow to see if your domain name is appearing there > If its appearing there means the configurations is done successfully.

Now you can add any AD users in any vSphere Roles to enable them to login in vSphere with AD credentials.

Cheers, Please write me back if you have any query or feedback.

Windows Server 2008 license activation error 0xC004E002

Or, 0xC004E002 Windows Server 2008 license activation error

Or, Unable to activate Windows Server 2008, error : 0xC004E002

Error Message:

Windows Activation

Windows Must be reinstalled "An unauthorized change was made to windows. Windows must be

reinstalled to activate. Insert the Windows installation DVD or CD into your computer to begin

reinstallation process".

Error Screenshots:

Symptom: Unable to activate Windows Server 2008, error : 0xC004E002.

Possible Reason: Network Service account missing from SoftwareLicensing folder properties

Workaround: We have to assign Network Service Account with full permission at path

C:\windows\serviceprofiles\networkservice\appdata\roaming\microsoft\softwareprotectionplatform

Solution (step by Step):

Browse the path: C:\Windows\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft

Right Click on “SoftwareLicensing” folder > Go to Properties > Security > Edit > Add

Type Network Services > Click OK

Give Full Permission to Network Service on SoftwareLicensing Folder > Click OK

Go to Run > Services.msc > Restart Software Licensing Service

Go to Start > Search CMD > Run as Administrator > Type Slmgr /dlv > Enter > Type Slmgr /rilc > Enter

Now you are done, you can check your Computer Properties, License status should be appearing as windows is activated...

In some environment, Activation shows genuine after a reboot...

Cheers, Please write me back if you have any query or feedback.

VMSA-2017-0006 vulnerability remediation for ESXi hosts

Or, VMware ESXi 6.0 vulnerability VMSA-2017-0006 remediation

Or, VMware ESXi vulnerability VMSA-2017-0006 remediation planning and execution

Descriptions: On Mar 28^th 2017 US-CERT notified it’s users about this vulnerability with VMware ESXi hosts. The remediation of this vulnerability is to update the ESXi hosts with the patch recommended by VMware. In my case the recommended patch was ESXi600-201703003.zip as my VMware ESXi servers are running on version 6.0 U2.

Scenario: As I am using ESXi Server version 6.0 U2, the recommended patches details are as below as per the reported vulnerability security advisory reference KB.

Security advisory reference KB: http://www.vmware.com/security/advisories/VMSA-2017-0006.html

You have to scroll down the page till the end to see these patches details as shown in the below screenshot.

Remediation Procedure/Steps:

Stage-1

As shown and explained in the above screenshot, please go to the VMware KB http://kb.vmware.com/kb/2149673 Or,

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2149673 to verify and check the information about required patch file.

It should be containing following information as highlighted in red in the below screenshot.

Stage-2

Now download the required patch from VMware Site (in my case it’s the below one):

https://my.vmware.com/group/vmware/details?productId=491&downloadGroup=ESXI60U2

This is the same URL which was given in security advisory (can see the very first screenshot in this article for reference).

You must be logged-in in the “My VMware” portal to be able to access this patch download windows.

The download page should be looking like below:

After downloading the path file will be appearing like below in a .Zip file format.

Use this file to update the patches on all affected VMware ESXi servers. You can use either manual method of installing this patch on all affected ESXi servers or you can use the easiest method of doing it by using VMware vSphere update manager.

I am a lazy administrator so don’t expect me to do this patching activity manually. Yes, I used the easiest method of doing it by using Update manager.

I have posted all the steps in my another article How to use Update Manager for patch installation on ESXi servers? . 

You can refer this article if you want to use Update manager for installing these updates on your ESXi hosts.

Cheers, Please write me back if you have any query or feedback on this.

How to use Update Manager for patch installation on ESXi servers?

Or, How to install patches on ESXi servers using VMware vSphere update manager?

Or, Using VMware vSphere update manager for patch installation on ESXi servers

Or, Patching ESXi hosts using Update Manager

Descriptions: Patching operating systems and software is one of the common and day to day task for every administrators, no matter if you are on Windows, VMware or any other platform. Here in this article we will explore VMware vSphere update manager for installing updates/patches on VMware ESXi servers.

Using update manager is for this kind of activities is really cool and easy. Just couple of click and that’s it..

Prerequisites:

1. Already synced updates in the patch repository of update manager or manually downloaded update file. In my case I have a manually downloaded patch file.

2. Good understanding of VMware features like vMotion, HA, Maintenance Mode, Baseline, Compliance check, remediation etc..

3. Administrative privileges for performing this activity.

Steps-1: Preparing patch repository or Importing patch file in update manager’s repository

Download the required patch file from VMware site, in my case it’s the below one:

Go to Update Manager console > Click on Patch Repository Tab > Click on Import Patches

Click on Browse > Select the patch file you downloaded > Click on Next

Click in Finish

Verify if the patch imported successfully, you can search for the patch ID in the search box.

Step-2: Preparing baseline image with the newly imported patch

On the Update Manager admin console, Click on Baselines and Groups > Click on Create > Fill in the Name and Descriptions > Select Host Path under Baseline Type > Click Next

Check on Fixed > Click Next

Search for the patch ID in the search box > Select the Patch > Click on Down Arrow > Click Next

Here you can select one or multiple patches to club in the baseline you are creating.

Click on Finish

The baseline has been created. Now you are ready to go with patch deployment on all ESXi hosts one by one or all at once in sequence…your choice..

Step-3: Applying the patches remediation of each ESXi individually using baseline

Choose any one host > Put it in Maintenance Mode > Go to Update Manager tab > Click on Attach

Select the host patch Baseline and click on Attach

Click on Scan to check if the host is compliant with the Baseline or not..

Click on Remediate, as the host is not yet compliant/patched

Click on Next

Click Next

Fill the required details > Select Immediately > Click on Next

Choose the options as per your requirements and Click Next (in my case, I left these options to Default)

Click Next

Click on Finish to start the remediation

Once the remediation is completed, you will see the compliant status as green… In addition, you may notice that the build version of ESXi host also changed.

You are done with remediation of the ESXi host with the patch baseline you created. To remediate other additional hosts, you need to follow the same process. No, No, No, not all the steps... You need to follow step-3 only for rest of the hosts.

Cheers, please write me back if you have any query of feedback on this.

System startup script to auto unlock BitLocker encrypted drive

Or, Auto unlock BitLocker encrypted drive without login in windows

Or, BitLocker encrypted drive auto unlock at system reboot

Or, How to setup system startup script in windows machines

Description: If the OS disk is encrypted using BitLocker encryption, TPM PIN or password is prompted at the startup screen and once your enter the required authentication details you are in. The problem is when you have other Data drive encrypted with BitLocker encryption and you have set some password to it.

Every time system reboots, you have to enter the BitLocker password for that drive manually or if you have enable auto unlock, the drive gets unlocked as soon as you logged in with your windows credentials.

Imagine the situation where you have enabled BitLocker encryption for Data drive on some servers and those servers got rebooted due to failures or any reason. Friends, even if you have enabled Auto unlock at that drive, it will not, because to get this auto unlock work, someone should login in the windows.

Scenario: I have a Server, Windows Server 2012 R2 and there are two Drives in this server (C:\OS-Disk and D:\Data-Disk). Data Disk is encrypted with BitLocker encryption (with password) and Auto unlock option is enabled on this disk.

Whenever there is a system reboot, I have to login in the server to make sure the drive is auto unlocked and data is accessible. This auto unlock feature is user based and the user for which this drive is not having auto unlock feature enabled, has to enter the BitLocker password manually to unlock the drive after login in to the windows.

Problem: Whenever there is System failure and no one is available to login in the server, the encrypted data drive will not be unlocked and encrypted data will remain inaccessible until someone login in the server.

Solution/Workaround: We can use manage-bde cmdlets to auto unlock the encrypted data drives at system startup. Even if no one login in the server, the drives will be auto unlocked at the startup whether it is system’s expected or unexpected reboot.

Prerequisites:

BitLocker Recover Key (exported at the time of encryption)

Administrative access on the server to edit the local system policy (gpedit.msc)

Basic knowledge of local group policy and .bat script.

Steps: Setting up Data drive auto unlock at system startup

Open the BitLocker Recovery Key file and Copy the 48 digit Recover Key.

Prepare a small .bat script using below command example:

@echooff

manage-bde -unlock D: -RecoveryPassword xxxxxx-xxxxxx- xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx

Copy and paste the above command in a Notepad file and Save as .bat file extension. Replace the XXXXXX 48 digit key with your Encrypted data drive’s Recovery key.

In my case, the script file name is test.bat

Now, on the local server, go to Run and open gpedit.msc

Navigate to Computer Configuration > Windows Settings > Scripts (Startup/Shutdown) > Click on Startup

From the Startup properties, Click on Show Files…

This will take you to the path where startup scripts are kept. Paste your .bat file here. In my case, its test.bat.

Now again go to the Startup Properties > Click on Add

Click Browse

Select the .bat script file > Click on Open > Click OK

Click on Apply > Click on OK

That’s it, you are done with setting up auto unlocking of BitLocker encrypted data drive.

Updated: 07/05/2017

IMP Note: Even if bitlocker is not supported for bootable OS disk of Virtual Machines, you can still encrypt the bootable drives of VMs if you wish to. Startup password prompt and drive unlocking functionalities will be same as hardware based computers.

Cheers, please write me back if you have any query or feedback on this.

Shared folder’s access denied on windows 7 after enabling Protocol Encryption - EMC VNXe3150

Or, Access to shared folders denied after enabling Protocol Encryption in VNXe3150

Or, Shared folder’s access denied after enabling Protocol Encryption EMC VNXe3150

Or, How shared folders Protocol Encryption works – EMC VNXe 3150

Descriptions: Guys if you have enabled protocol encryption on some of your shared folder that are directly shared from your VNXe3150 storage box, it is possible that windows 7 machines may not be able to access those shared folders after enabling protocol encryption on the shared folders from storage side. However, windows 10 machines can access those shared folder without any errors.

How shared folders Protocol Encryption works – EMC VNXe 3150: Enabling Protocol Encryption is not the encryption of data either on client or storage side. Enabling Protocol encryption just encryption the data in transit. Means, the data travelling between client and storage is encrypted only while travelling.

Scenario: I had recently enabled protocol encryption on some of the shared folder of my storage box VNXe3150 to meet organisation security requirement of data encryption.

Soon after enabling Protocol Encryption from storage side, I noticed that windows 7 users are not able to access any of the shared folders, which are having protocol encryption enabled on them. However, users using windows 10 machines are able to access those folders without any error.

IMP Note: Never be confused with management IP and shared folders IP if you are using direct-shared folders from VNXe3150 storage box. Management IP is the one that gives you the ability to manage your storage box (e.g. any administrative tasks, firmware update, health check etc...) whereas, shared folder IP address is the one that you use to access the shared folder’s using \\path etc…

You may be aware of already (that is goodJ) but I would like to let you that, shared folder’s IP address that you use to access the shared folder on your windows machines also have Registry Keys Hierarchy like windows. To resolve the problem all you need to do is you need to fine-tune the registry keys of the shared folders (not the local machine’s regedit keys). 

Solution: modifying the shared folders registry keys

On your local windows machine, go to Run > type regedit > press Enter

Got to File option > Click on ‘Connect Network Registry’ > Type the IP address of the shared folder to connect

After successful connection, the shared folder’s registry should look like below.

Browse the registry key until the path:

“HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters”

Set the following parameters

“Encryptdata” to 1 and "RejectUnencryptedAccess" to 0

Take a reboot of your storage and SPs to make sure these changes are completely applied and in effect.

Note: Please understand the risk of modifying registry keys before modify them.

Cheers, please let me know if you have any query or feedback on this.