31 October 2012

How to add a file share ISO to a Hyper-V VM

When one start using more than one Hyper-V server you start running into things that may not have been an issue before.  One of these things is being able to properly share an ISO image that is located on the file system of one Hyper-V server with another.  This same procedure will also allow you to use ISO files located on any file share server.  This avoids the alternative of having to copy the file to each Hyper-V server.

Error Messages:
If you simply try to attach a network share ISO file to your virtual machine you will get an error.  It can be either of these depending on when you attempt to attach the ISO.

Error applying DVD drive changes

Failed to modify device 'Virtual CD/DVD Disk'
User Account does not have sufficient privilege to open attachment <iso location>
Error:  'General access denied error'



The server encountered an error while configuring the devices on < New virtual Machine Name >
Failed to add device 'Virtual CD/DVD Disk'
User Account does not have permission to open attachment



Resolving the problem
To get this to work properly there are a few steps to follow:

  • Configure the file share
  • Configure delegated authentication
  • Attach the file share ISO  


Step 1  - Configure the File Share
When dealing with the Hyper-V connection it is important to note that the user account being referred to is actually the Hyper-V server computer account.  It has nothing to do with the logged in user.


  • On the server that will host the file share
  • Create a folder for the share such as d:\ISO
  • Copy all the ISO files to this folder
  • Right click the folder - Properties
  • Select the Sharing Tab
  • Click Advanced Sharing
  • Check "Share this folder"
  • Click on Permissions
  • Click Add
  • Click Object Types
  • Check only Computers
  • Enter the computer name of the Hyper-V server 
  • Click Check Names
  • Click OK
  • You should now see that the computer account has been added it will be Hyper-VServerName$
  • Only read access is required
  • Click OK twice and close the file share options


Next up you will need to configure the NTFS permissions for the folder.


  • Form the folder properties screen select the Security Tab
  • Click Edit
  • Click Add
  • Click Object Types
  • Check only Computers
  • Enter the computer name of the Hyper-V server 
  • Click Check Names
  • Click OK


You should now see that the computer account has been added with Read access

Step 2 - Configure Delegated Authentication
The following is performed in Active Directory Users and Computers

  • Open the AD Users and Computers MMC
  • Find the computer account of the Hyper-V server
  • Open the properties and select the delegation tab
  • select Trust this computer for delegation to specific services only
  • Use any authentication protocol
  • Click Add
  • Click users or Computers
  • Enter the name of the server hosting the file share
  • Scroll through the list of service types and select cifs
  • Click OK


Once all of this is done we can start working on the Hyper-V server

Step 3 - Attach theFile Share ISO
Reboot the Hyper-V server for the setting to take affect
  • Select your virtual Machine
  • Select Settings
  • Select the DVD Drive
  • Choose Image file as the media
  • Click Browse
  • Specify the path to the file share eg. \\fileserver\share\install.iso
  • Click Apply


If everything is working properly it will successfully attach the network ISO file as the local DVD for the virtual machine

As you can see the steps will have to be repeated for all the Hyper-V server that need to access the file shared ISO.


26 October 2012

F5 BIG-IP Reset to factory defaults

Sometimes you may want to clear all configuration from your BIG-IP.  This is often the case for a lab or test VE device.  The following procedure will help you backup and keep your existing configuration then to reset your BIG-IP with almost no configuration. This procedure is tmos V11 onwards

Backing up your existing config
It is always a good idea to keep a backup archive of your configuration.  It is a quick and painless procedure so there is no reason to just go through it before you start.  You never know if you need to "go back to check something."

From the main management GUI

  • Select System - Archives +
  • Specify a name such as "Pre_Factory_reset"
  • Ensure Private Keys is set to Include
  • Click Finish
  • Once the archive is complete click OK

You should now see the Archive list.

  • Click on you archive you just created
  • Click the Download <Archive Name> button
  • This will allow you to save the .ucs file on your local machine.


Preparing to reset the BIG-IP
The following procedure will reset the device.  However it will keep certain setting that you would probably want to keep.  The following will be retained:

  • Management IP
  • Admin and root accounts
  • License file
  • Files in the /shared partition
  • Manually modified bigdb variables
  • Previous Archives


Resetting your device
Now that you have a safe backup archive and you know what will be lost you can safely start.

  • open you SSH client
  • connect to the management IP
  • log in as root
  • Execute the following commands 
  • tmsh
  • load sys config default
  • y (Reset configuration to factory default)
  • save sys config


Once the reset has been done you will be able to connect back to the management IP with management GUI.  Your machine will be fresh and clean but would have retained the above mentioned objects.

At this point I would suggest making another Archive to take you back to this "pre_config" state.


25 October 2012

F5 BIG-IP LTM User delegation Part III - Users and Roles

To be able to delegate control over certain portions of your BIG-IP LTM environment you need to create additional users and additional partitions.  Part I of this series covered how to configure your BIG-IP to query Active Directory.  Part II covered how to create additional administrative partitions and create object inside those.

Before proceeding with this article check out the preceding articles on the topic
http://fixmyitsystem.com/2012/10/f5-big-ip-ltm-user-delegation-part-i-ad.html
http://fixmyitsystem.com/2012/10/f5-big-ip-ltm-user-delegation-part-ii.html

BIG-IP has two kinds of user accounts. The admin accounts that was originally configured with the setup utility.  These accounts are root and admin.

The second type of accounts are "other accounts."  These are setup and configured in the GUI.  Other users can also be either local or remote.  We will cover using remote users from Active Directory.

Step 1 Identify which User Roles

There are various user roles and they have various different rights to perform specified functions.  The diffrerent user roles are as follows:

  • Administrator
  • Resource Administrator
  • User Manager
  • Manager
  • Certificate Manager
  • iRule Manager
  • Application Editor
  • Acceleration Policy Editor
  • Web Application Security Administrator
  • Web Application Security Editor
  • Operator
  • Auditor
  • Guest
  • No Access

In large deployments all of these can come in handy, but in smaller deployment you would probably only use a few of these such as Administrator, Application Editor and Operator.  Keeping a consistent  limited user role allocation across partitions will keep administration simple and straight forward.

A User account can therefore be assigned a user role but they are also assigned an administrative partition.  The combination of these provides a very granular level of access control.

For a a detailed list of the different user roles and what the permissions are check out http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/tmos-concepts-11-2-0/tmos_users.html#1006923

Step 2 Identify Active Directory Groups

When we assign a user account or group to a role and a partition there is a limitation.  A single active directory users can only be assigned one role and one partition.  If a users needs access to multiple partition you would have to grant him universal access (the All partitions)  the user role that the user is assigned would then apply to all the partitions. 

Using the line order field can assit with this but more on that later.

Step 3 LDAP strings

As in Part I of this series you will need to get the correct LDAP string for each active directory group you want to use.


  • Open ADSI edit
  • Connect to your domain
  • Browse the directory structure till you find the right group (or user)
  • Open the properites and find and copy the distinguishedName  field
  • Paste this into notepad
  • Prefix the string with memberOF= 


Your string you now look something like this:
memberOF=CN=WebOperators,OU=Security Groups,OU=EnterpriseConfiguration,DC=mycomapny,DC=co,DC=za


Step 4   Assign remote Role Groups

The following will work correctly if the User Authentication is set up as detailed in Part I 

Open the BIG-IP management GUI
Select System - Users - Remote Role Group
Click Create
Group name:  Specify a relevant name 
Line order:  1000
Attribute string: (Your LDAP string from notepad)
Remote Access: Enabled
Assigned Role: Pick relevant role
Partition Access: Pick relevant partition or "All"
Terminal Access: Disabled



Line order refers to the line in the local file being read by Active Directory, the recommendation is to start at line 1000 and use a new line for every group.  The lines are read one by one so if a user belongs to two groups that are listed the group that has a lower line value will be used.


Step 5 Testing

Using a user that you have configured as a non administrative account that belongs to a specified partition is the easiest way to test.


  • Open the BIG-IP GUI
  • Log in using the domain credentials (no need to specify the domain)
  • Once logged on there will be a few indicators showing the users access.



When looking at a list of nodes you will still see all the nodes form the common partition but not the ones form other partitions.  The operator will also only have read access to the common partition objects.



Conclusion
After following the series you should now have all the understanding and building blocks to effectively partition resources and allocate the correct users the correct level of access.

F5 BIG-IP LTM User delegation Part II - Administrative Partitions

To be able to delegate control over certain portions of your BIG-IP LTM environment you need to create additional users and additional partitions.  Part I of this series covered how to configure your BIG-IP to query Active Directory.

http://fixmyitsystem.com/2012/10/f5-big-ip-ltm-user-delegation-part-i-ad.html

The logical units into which you can break up the administrative boundaries are called administrative partitions.  By default everything will belong to the Common partition.  When assigning users you will be able to bind them to a partition.

Note: Every item that belongs to the Common will be visible to all users regardless of the user assigned partition.

Step 1 Plan Partitions

Partitions are very useful boundaries but they are not very flexible.  If an object is created in a partition it cannot be moved to another.  In the same way existing objects cannot be "added" to a new partition.
Non administrative users will also only be able to access a single partition.  If a user needs access to more than one partition he would have to be escalated to have access to all partitions.  Resources cannot generally be shared across partitions.  A resource can also not exist in to partitions at the same time.

Because of these limitations it pays to think things through and come up with a sustainable partition strategy.

Step 2 Create Partitions

You will notice that there really is not much to configuring a partition.

  • From the Main screen select System - Users - Partition List +
  • Specify a name 
  • Add a description 
  • Click finish



One thing to note is that when doing this you are in the Common partition .

Step 3 Create objects in the Partitions

The only way to get object in and out of partitions is to create them and and delete them while the partition is selected. As an administrator you would have access to all the partitions.


  • Once logged onto the BIG-IP select the relevant partition (top right)




  • Select Local Traffic
  • Nodes - Node List
  • Create a new node

If you look at the node list you should now see the new node has been assigned to the new partition
You also see node that belong to the common partition.
If you change the partition you have selected to All you will see all the objects.




  • Select the relevant partition
  • Select Local Traffic
  • Pools - Pool List
  • Create a new pool


When adding members from the node list you should again only see nodes form the common and specified partitions.




Now that you have a few partitions and a few objects in these you can start giving users access to these.


For Authorising users check out part III http://fixmyitsystem.com/2012/10/f5-big-ip-ltm-user-delegation-part-iii.html



For more reading on administrative partitions check the F5 Manual
 http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/tmos-concepts-11-2-0/tmos_partitions_and_folders.html?sr=24830254

24 October 2012

F5 BIG-IP LTM User delegation Part I - AD authentication

To be able to delegate control over certain portions of your BIG-IP LTM environment you need to create additional users and additional partitions.  Being able to use existing Active Directory users and groups makes this much simpler.

Step 1 Service Account

For the BIG-IP to bind to Active Directory you need to provide a valid domain account. I suggest creating a service account for this before proceeding.

Step 2 LDAP strings

Before you start the configuration you will need some info that you will most probably have to look up using ADSI edit on a domain controller


  • Start the ADSI Edit application
  • Right ADSI Edit and select connect to
  • Click OK

You Should now be able to browse the directory


  • Locate the service account created earlier
  • Right click the account - Properties
  • In the Attribute Editor scroll until you find the field distinguishedName
  • Copy the whole string and paste it into notepad.  This is your user string to be used later.

It should look something like this:
CN=Etienne Liebetrau,OU=Division,OU=ITS,DC=mydomain,DC=co,DC=za

  • Select the top domain level
  • Right click - properties
  • In the Attribute Editor scroll until you find the field distinguishedName
  • Copy the whole string and paste it into notepad.  This is your Directory Tree string to be used later.

It should look something like this:
DC=mydomain,DC=co,DC=za


Step 3 Set Authentication type

From the main screen select
System - Users - Authentication

For user Directory:  Remote - Active Directory
Host is one of your domain controllers
Port:   389
Remote Directory Tree:   this is your domain string from notepad
Scope:  Sub
Bind: DN: is the user string form notepad

User template: can be left blank
Check Member Attribute in Group: needs to be checked
SSL Disabled

External Users
Role: No Access
Partition Access: Disabled

That's all there is to it.  This section cover authentication but you have not yet specified any authorisation.

Next step is to create administrative partitions - check out Part II http://fixmyitsystem.com/2012/10/f5-big-ip-ltm-user-delegation-part-ii.html

02 October 2012

WiFi Certificate Based Authentication

To secure a WiFi network it is important to authenticate the users or device.  This article will cover the components and  configuration required to authenticate and allow WiFi access based on either the User certificate or the computer certificate.  You will need the following:

  • Internal CA
  • WiFi Controller
  • NPS (RADIUS Server)
  • Client computer

Internal CA
To have a certificate based WiFi authentication method you need to have an internal Certificate Authority (CA)  Because of the sheer number of certificates that will be issued it is generally not feasible to use a public CA

You will need to define two templates.  One template will be used for user validation while the second will be used for computer validation.   The Certificate should have the following Application Policies specified in the certificate template Extensions tab.  These will show up in the Certificate's Enhanced key Usage.
User certificate
  Client Authentication (1.3.6.1.5.5.7.3.2)
Computer Certificate 
  Client Authentication (1.3.6.1.5.5.7.3.2)
  Server Authentication (1.3.6.1.5.5.7.3.1)

Deciding on how to deploy the certificate does not affect how the rest of the implementation fits together.  It is however a great streamline option to allow Auto Enroll and Auto Renew for either or both of the certificate templates.  Controlling access on AD groups is much simpler than manually enrolling users and machines on demand.

WiFi Controller
Since the client machines will be connecting to the WiFi network these requests will get handled by a Wireless Network controller or router.  There are various options here but the common factor that we will be using is the ability to authenticate using RADIUS.
Remote Authentication Dial In User Service (RADIUS) is a networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA) management for computers to connect and use a network service
Essentially what happens is that the WiFi controller hands off the authentication to the RADIUS server and only gets back a Yes or No answer as to grant or deny access. Since this is a two step authentication we need to configure both the Wifi Controller and the RADIUS Server.

The steps below are for a Cisco 5500 Controller but should have similar corresponding setting to any other.

Configure Wifi Controller as RADIUS Client

  • Select Security
  • Expand AAA
  • Expand RADIUS - Authnetication
  • Click New to add and additional RADIUS server
  • Specify the IP address
  • Specify a shared secret (password that has to be configured on the RADIUS server too)
  • All the other default values can be used




Configure WLAN

  • Select the WLAN or SSID you want to configure to use RADIUS
  • Select the security TAB
  • Select Layer 2
  • Security Type  should be WPA+WPA2



  • Select AAA Servers
  • Under the RADIUS servers section select the server added earlier
  • Apply to save the configuration
  • Click Save Configuration




NPS RADIUS Server
The Network Policy Server role in Windows Server allows it to be a RADIUS server.  This role needs to be added to the server.

Configure the WifiController as RADIUS Client
  • From the Network Policy Server Console
  • Expand RADIUS Clients and servers
  • Select RADIUS Clients
  • Right Click  - New
  • Specify the details of the WiFi Controllers including the shared secret defined earlier.  



Configure Connection Request Policies
  • From the Network Policy Server Console
  • Expand Policies
  • Right Click Connection Request Policies - New
  • Name: Secure Wireless Connections
  • Type of Server : Unspecified
  • Add Conditions : NAS Port Type = Wireless - IEEE 802.11

Configure Network Policy (User certificate) 
  • From the Network Policy Server Console
  • Expand Policies
  • Right Click Network Policies - New
  • Name: Secure Wireless User Certificate
  • Type of server:  Unspecified
  • Add Condition : User Groups (the users group you want to allow to authenticate)
  • Access Granted
  • EAP Types: Add Microsoft:  Smart Card or other certificate
  • Uncheck all the less secure methods

Configure Network Policy (Computer certificate) 
  • From the Network Policy Server Console
  • Expand Policies
  • Right Click Network Policies - New
  • Name: Secure Wireless Compouter Certificate
  • Type of server:  Unspecified
  • Add Condition : Machine Groups (the users group you want to allow to authenticate)
  • Access Granted
  • EAP Types: Add Microsoft:  Smart Card or other certificate
  • Uncheck all the less secure methods

These policies should now be processed first.  If you prefer the computer certificate then specify the computer certificate policy first.


This will accept either a user certificate or a computer certificate.  Once a policy is matched no further rules are processed. If you specified both constraints in a single policy then both certificates would be required to authenticate.

WiFi Client Computer
All the back end infrastructure should now be set up and configured correctly.  The configuration below allows you to test your deployment.  In practice these setting can be globally deployed using group policy.
  • Open the network and Sharing  Centre
  • Click Manage Wireless Networks
  • Select the SSID of your WifiNetwork and open properties
  • Select the Security Tab
These settings will now be configured to match the WiFi controller and NPS to ensure the authentcatio process works.
  • Security Type: WPA2-Enterprise
  • Encryption type AES
  • Authnetication Method: Microsoft Smart card oe other certificate
  • Click Advanced
  • Check Specify authentication mode
  • To use the user certificate select User Authentication OR
  • To use the computer certificate select Computer Authentication 

When connecting to the WiFi network you should now be able to authenticate and connect.

Logging
All the authnetication attempt and result are logged by the NPS.  To view the authentication open the Event Viewer - Windows Logs - Security  Successfull connection are logg with Event ID 6278 and 6272.  Check the Event message you will be able to see if the user certificate or the computer certificate was used.