Add identity source

To be able to authenticate to vCenter with Active Directory, you have to add an identity source. To add an identity source, navigate to Administration | Single Sign-On | Configuration. Click on the add button.

Then select Active Directory (Integrated Windows Authentication).

In the next screen, the wizard tells you that you cannot add this identity source because the vCenter Single Sign-On server is not joined to a domain. So, click on Go to Active Directory Management to join the vCenter SSO server to the domain.

Next, click on join.

Then specify a domain, an OU and credentials to join the vCenter to the domain.

Next restart the vCenter server. When it is online again, you should be joined to the Active Directory Domain.

Next go back to to Administration | Single Sign-On | Configuration. Click on the add button. Then select Active Directory (Integrated Windows Authentication). Now the wizard sets automatically the domain name. Just click on next.

After you have reviewed the settings, you can click on finish to add the identity source.

Once you have added the identity source, you should have its information in the table as below.

Use Active Directory users and groups in vCenter

Now that vCenter can use Active Directory accounts to authenticate, you can browser users and groups. Navigate to Users and Groups tab. In domain menu, select your domain. You should get all the user of the domain.

In the Active Directory console, I have created a group called GG-VMwareAdmins. The account Romain Serre is a member of this group.

Next go back to vCenter and select groups tab. Select the Administrators group and click on add member.

Then select your domain and specify the name of the group in search field. Once you have found your group, just click on Add and OK.

Now the GG-VMwareAdmins Active Directory group is member of Administrators vCenter group.

From the authentication page, specify an account member of the Active Directory group.

If the configuration is good, you should be logged into vCenter as below.

Activate Windows Session Authentication

VMware provides an authentication plugin to use the Windows session login to authenticate to vCenter. The below screenshots come from Firefox. Open the browser and navigate to the vCenter authentication page. Then in the footer of the page, click on Download Enhanced Authentication plugin.

Once you run the installer, you have a warning saying that all other plug-in instances will be stopped. Just click on OK.

Next the wizard says to you that two plug-ins will be installed: the VMware Enhanced Authentication Plug-in and VMware Plug-in Service installers. Click on OK.

Foreach plug-in, follow the process to install it.

When both plug-ins are installed, close and open the web browser. Next, open again the vCenter authentication page. You should have the below popup. Click on Remember my choice for vmware-plugin links and click on Open link.

Next, you are able to check Use Windows session authentication. When you check the box, the below pop-up appears. Click on Allow.

Now you can use the Windows session credentials to authenticate to vCenter.

Conclusion

The authentication from Active Directory brings a valuable way to manage and segregate rights. Almost all companies have an Active Directory to manage authentication and authorization centrally. Thanks to Active Directory, vCenter authentication and authorization can also be managed from this service. This enables to increase the security level because vCenter is not managed alone anymore and it is integrated into the overall company security policies (such as password length, expiration and so on).

The post Authenticate to vCenter from Active Directory credentials appeared first on Tech-Coffee.

In the last topic, I have implemented the 5-Nine Cloud Security in a Windows Azure Pack environment. Now I will configure 5-Nine Cloud Security to work with the Windows Azure Pack.

• Part 1: Implement 5-Nine Cloud Security 5.1
• Part 2: Configure 5-Nine Cloud Security for Windows Azure Pack
• Part 3: Protect tenant VMs

Permissions Management

First of all we have to configure the service account with the right permissions. If you don’t configure the service account permissions, the Cloud Security service in the Windows Azure Pack will be Out-Of-Sync. Remember the part 1 of this series. When I have installed the Windows Azure Pack extension, I have used a service account to connect to the Management Service as below. This is this account that I will add to the permissions management.

So open a 5-Nine Cloud Security console and click on Settings and select Permissions Management.

Next click on Add and click on Select. Now select Global Group and Windows User. Then specify the service account (mine is called home\sa-sec-svc01). To finish select the Security Administrator role for this account.

Now in the Permissions Management you should have the service account as below. I have also added my account to manage the solution from the console.

Add Hyper-V hosts to 5-Nine Cloud Security

Now that the service account permissions are set, connect to your administrative portal of the Windows Azure Pack. Open the 5-Nine Cloud Security tab. In the Hosts tab, click on add as below.

Then specify the host name and if needed, the credential to connect to the Host Management Service. Repeat this operation for each Hyper-V host.

Now your Hyper-V hosts should be listed in the Hosts tab.

If you come back to the 5-Nine Cloud Security Console, the Hyper-V hosts should be added as below.

Now you should have all VMs listed in the 5-Nine Cloud Security as below.

And you have the same result in the 5-Nine Cloud Security console J.

Add the Cloud Security Service to a hosting plan

Now we can add the 5-Nine Cloud Security service to a hosting plan. So, navigate to your hosting plan and click on Add Service.

Select the Cloud Security Service and click on validate.

If all is well configured, you should have a new plan service called Cloud Security and Active. If your service is Out-Of-Sync, verify the permissions in 5-Nine Cloud Security console.

Check on the tenant portal

To verify if the tenants can access to the Cloud Security service, I’m connecting to to the tenant portal with Jason Bourne account (fabrikam\jbourne). First be sure that at least one VM is created by the tenant.

Now click on New, select Cloud Security and Add VM.

N.B: I have an issue at this moment. When I click on Add VM, the list of virtual machines is empty. Currently I’m asking to 5-Nine support how to resolve this issue. When I have the solution, I will edit this topic. For this example, I have linked the VM to the tenant from the 5-Nine Cloud Security Console.

Select the VM and validate. Now if you navigate to the 5Nine Cloud Security tab, you should have your VM listed.

If I come back to the admin portal, I have the tenant associated to the Virtual Machine.

And to finish, if I open the 5-Nine Cloud Security Console, I have a Virtual Machine member of the jbourne@fabrikam.com tenant.

Conclusion

In this part we have seen how to manage the 5-Nine Cloud Security from Windows Azure Pack. We have added the Hyper-V hosts from WAP and we have delivered the Cloud Security to our tenants to provide Security as a Service. In the next part, I will protect tenant VMs  with this solution.

The post Configure 5-Nine Cloud Security for Windows Azure Pack appeared first on Tech-Coffee.

In this topic, I will implement the 5-Nine Cloud Security in a Windows Azure Pack environment. This topic is the first of a series.

• Part 1: Implement 5-Nine Cloud Security 5.1
  
• Part 2: Configure 5-Nine Cloud Security for Windows Azure Pack
• Part 3: Protect tenant VMs

5-Nine Cloud Security 5.1 overview

5-Nine Cloud Security is composed of 5 features that have to be deployed on specific servers:

• Management Service: this feature should be deployed on a dedicated VM. This is the management server of the solution;
• Management Console: this feature enables to configure and manage the 5-Nine Cloud Security solution. This feature should be installed on the Management Service server and on console servers;
• Host Management Service: this component should be installed on Hyper-V hosts to have the visibility on Virtual Machines
• SC VMM compliance extension: this component should be installed on Virtual Machine Manager servers. Thanks to this feature, a configuration provider is added to Virtual Machine Manager. This enables to add a Cloud Security Network Service and extensions to logical switch.
• Extension for Windows Azure Pack: This feature should be installed on Windows Azure Pack servers. This enables to add 5-Nine Cloud Security tab on admin and tenant portals to make the configuration.

Below you can find a schema of the deployment that I have made in my lab.

You can download and request a trial license key of 5-Nine Cloud Security 5.1 here. For this topic, I have downloaded the Standalone with Kaspersky Antivirus version.

Management Service and Management Console installation

First, I have deployed a new virtual machine called vmsec01. On this server I have run 5nineCloudSecurityKAV.exe. Next I select Management Service and I have clicked on Install.

Next click on next many times and choose a destination folder.

Specify a domain service account and click on next.

Next specify a database server and credential. I have specified a SQL Server AlwaysOn endpoint based on SQL Server 2012 SP1.

When the installation is finished, you can select the Management Console and click on install.

Next I choose a destination folder and I click on next.

Then specify the management server address. Because I install the management console on the same server where is the management server, I specify localhost. If you install the management console on another server, you have to specify the FQDN of the management server.

When the management console is installed, you can open the console. You should have something like this.

To finish, I recommend you to create a firewall exception based on this program: D:\<InstallPath>\5nine\5nine Cloud Security for Hyper-V Management Service\5nine.VirtualFirewall.ManagementService.exe

Host Management Service installation

Local installation

Connect to a Hyper-V host and run 5nineCloudSecurityKAV.exe. Select Host Management Service and click on Install.

Click on next, choose a destination folder and specify a service account for the Host Management Service.

Then specify the management server FQDN.

Remote installation

You can also install the Host Management Service remotely. For that, run 5nineCloudSecurityKAV.exe, select Host Management Service and click on Remote Install.

Next specify the management server FQDN.

Next add each Hyper-V hosts where you want to install the service and the service account.

Click on next and the installation should be launched on each Hyper-V.

Virtual Machine Manager extension

Install SC VMM Compliance extension

Connect on each Virtual Machine Manager server and run 5nineCloudSecurityKAV.exe. Select SC VMM compliance extension and click on next.

Select a destination folder and click on next.

Once you have finished to install this feature, reboot the Virtual Machine Manager service.

Configure Virtual Machine Manager

Connect to your Virtual Machine Manager and navigate to settings. Click on Configuration Providers and verify that 5-nine Cloud Security Network Management Provider is active.

Next navigate to the fabric and add a network service. Give a name to the network service and click on next.

Select 5nine Software, Inc as Manufacturer and CloudSecurity Manager as Model.

Specify a RunAs account. I have created a RunAs account called CloudSecurity based on management server service account credential.

Then specify the Management Server FQDN and click on next.

Next validate the network service configuration provider by clicking on Test and if the test result is good, click on next.

Select the host groups where the network service will be available.

To finish, edit each logical switch and select 5nine Cloud Security Filter extension.

Now connect to Hyper-V Manager and verify if extensions are in the same order as VMM configuration:

To finish verifying if the related interface are compliances as below:

Windows Azure Pack extension installation

Now connect to your Windows Azure Pack servers and run 5nineCloudSecurityKAV.exe. Select Extension for Azure Pack and click on install.

Select the features to install regarding the Windows Azure Pack server roles.

Next specify the hostname and the credentials to connect to Management Server.

Next specify credentials for communication between the Windows Azure Pack and Cloud Security API web service.

Once you have finished installation of Windows Azure Pack extension, you should have a new tab in the Admin Portal.

In this next part, I will explain you how to configure 5-Nine Cloud Security in Windows Azure Pack.

The post Implement 5-Nine Cloud Security 5.1 in Windows Azure Pack appeared first on Tech-Coffee.

Password Settings Object

A Password Settings Object (PSO) is an Active Directory object. This object contains all password settings that you can find in the Default Domain Policy GPO (password history, complexity, length etc.). A PSO can be applied to users or groups. When PSO is applied on some users, there are no longer using password policy from Default Policy Settings GPO. Instead they use the PSO settings.

Because PSO can be applied to a group, a user can be linked to two PSO. However only one PSO can be applied to users. So in this case an RSoP (Resultant Set of Policy) must be calculated to apply one PSO. The RSoP calculation is based on a PSO parameter called Precedence which is a number. The PSO with the lowest number win and is applied. So the lowest Precedence number is always applied.

By default only domain administrators can create and read PSO because only these accounts can create and write object in the Password Settings Container. However only write delegation on users and groups enables to apply PSO.

Deploy Fine-Grained Password Policy

Mock-up Presentation

I have created three users in my Active Directory:

• Glen Moray that belongs no group;
• John Jameson that belongs PSO-Standard Users group;
• Jack Daniel that belongs to PSO-Standard-Users and PSO-PasswordOfTheDeath groups.

 Password Settings Object creation

First open ADAC from Server Manager and Tools menu.

Click on your Domain (mine is called Fabrikam.com) to list containers in your domain. Click on System Container.

In System container, you should have the Password Settings Container. Click on it and select New on the right.

On the PSO creation screen, you can see the password policy parameter such as password length, password history, maximum age, complexity etc. There is also the Precedence parameter. As you can see on below screenshot, I have applied PSO to PSO-Standard Users group. For these examples, I have removed the minimum password age to validate just after account creation my PSO. If I leave this setting to 1 day, I have to wait tomorrow to change password …

Next I create a stronger password policy that I applied to the PSO-PasswordOfTheDeath group.

After PSO creation you can double click on the Password Settings Container to view your PSO. On the below screenshot, you can see that my SuperSecure Password PSO has a stronger precedence.

To view the RSOP and so the PSO that will be applied to users, open your OU where are stored your users object and select an account as below. Click on View Resultant Password Settings on right.

Remove default password policy on Active Directory

To validate my test, I remove the default password policy managed by the Default Domain Policy GPO. Open Group Policy management console, and edit the Default Domain Policy.

Open Software Settings, Windows Settings, Security Settings, Account Policies and Password Policies. Set these policies as below.

First test: user without password policy

My First user called Glen Moray belong no group. So no password policy is applied to this account. To test that, I change the password to aaa as below:

Because no password policy is applied to this account, the password has been changed successfully.

Second test: User with standard users PSO

The user John Jameson is linked to the Standard Users PSO. A 8 chars complex password is required. So I try the aaa password:

Because the PSO is applied, the password can’t be applied because it does not meet the requirement related to the PSO.

So I try a complex password more than 8 chars:

The password meets the PSO requirement so it has been changed successfully.

Third test: User with SuperSecure Password PSO

Now I try Jack Daniel user. This user is a member of all my PSO group. But because SuperSecure Password PSO has the strongest precedence, this is this last that will be applied. Let’s try to validate this assumption. I try the same password than John Jameson user:

Because this password doesn’t meet the SuperSecure Password PSO requirement, the password can’t be changed.

So I generate a strong password with this tool.

Next I Past it to the reset password wizard:

And it is work !

Conclusion

Fine-Grained Password Policy is a great feature that enables to apply different password policies in your domain. For example you can apply a different password policy to administrator, to standard user and to service account. You are no longer forced to use only one password policy. Now that Microsoft has introduced the Active Directory Administrative Console (ADAC), Password Settings Object can be managed easily. So why continue to live without?

The post Fine-Grained Password Policy in Active Directory appeared first on Tech-Coffee.