Server Tangents

Step-by-Step–Configuring VirtualBox for Server 2008 R2 on Windows 7

Posted on December 9, 2013. Filed under: Server Tangents, Software Tangents |

By: Brenton Blawat

This article came about when we were attempting to install a free virtualization client on our Windows 7 systems. For what otherwise should seem like an easy installation, we had a variety of issues getting this running. It took a culmination of multiple blogs, forums, and vendor instructions to get this functioning properly.

Below are the step-by-step instructions on how to get VirtualBox working with Server 2008 R2.

Prerequisites

  1. Your processor must be 64-bit capable. Most modern CPUs (after 2010) should support 64-bit architecture.
  2. You must have downloaded the Server 2008 R2 ISO and have a valid product key.
  3. You must have administrator access on the Host Machine, inclusive of the BIOS.

Step 1 – Download and Install

Download and Install VirtualBox from the Official Oracle VirtualBox Website.

Step 2 – Setup the Host Machine’s BIOS

Each Hardware manufacturer will have different settings. The below screen shots are for the Lenovo BIOS.

Enable – Hardware Virtualization

  1. Arrow to the Security Tab
  2. Select Virtualization > Press Enter
  3. Enable Intel ® Virtualization Technology
  4. Save Bios Settings

Step 3 – Creating VirtualBox Guest OS for Server 2008 R2

Stepsub1

1. Select New

step1

2. Enter a Server Name > Select Windows 2008 (64-bit) > Select Next

step2

3. Increase the memory to a minimum of 1024 > Select Next (Note: This step is extremely important. Setup will fail if you keep the default of 512 MB of RAM usage.)

step3

4. Select Create a Virtual hard Disk Drive Now > Select Next

step4

5. Select VDI (VirtualBox Disk Image) > Select Next

step5

6. Select Dynamically Allocated > Select Next

step6

7. Select Disk Size (Default 25GB) > Select Create

Step 4 – Configuring VirtualBox Guest OS for Server 2008 R2

1. Select the New Guest > Select Settings

step7

2. Select the System Category and Motherboard Tab > Check Enable I/O APIC

step8

3. Select the System Category and Processor Tab > Check Enable PAE/NX

step9

4. Select the System Category and Acceleration Tab > Check Enable VT-x/AMD-V. Uncheck Enable Nested Paging (Note: The Nested Paging setting caused issues with the MSDN media. It may work with other media.)

5. Select the Storage Category > Right-click Controller: IDE > Select Add CD/DVD Device

step10

6. Select Choose Disk

step11

7. Select the Windows Server 2008 R2 ISO Media to mount. > Select Open

step12

8. Select the ISO Media Drive > Select Live CD/DVD > Select OK

Start the Operating System and You should be on your way.

Happy coding!

Read Full Post | Make a Comment ( None so far )

Nested User Groups (Groups in Groups) / Built-in Local Groups Issue

Posted on July 13, 2010. Filed under: Server Tangents |

By: Brenton Blawat

“Broken By Design”

UPDATED! After hours of conference calls with Microsoft, and multiple tiers of support, we come to the conclusion that Nested Local Groups in Built-in Groups are “broken by design”. What does this really mean? When you nest a Local Group into a Built-in Local Group, the effective permission set for the Users within that Local Group is reduced to Guest. This remains true unless the Users are specifically added into the Built-in Local Groups, which will result in proper permissions being passed to the Users.

 

Nesting Issue Explained

coregroups_small

Lets take the above graphic, where we created a new local group called ‘Geeks’ which contains users named “Brenton B” and “Jason P”. From there, we added the ‘Geeks’ local to the Built-in ‘Administrators’ local group. From that hierarchy, we should assume any users in the ‘Geeks’ Local Group, should obtain Administrative privileges by traversing through the security pathway. Unfortunately, this is not the case.

Note: This issue is for all of the Built-in Groups on the system including, but not limited to, Administrators, Backup Operators, Power Users, and Users. I used the Administrators Group, as it’s easiest to work with.

 

coregroupserr_fulljpg

The issue has to do with second level security traversing with Built-in Groups. While the first level traversing is a trusted security relationship in the operating system, the second security relationship is not trusted. This means that the ’Geeks’ Local Group object is effectively a member of the ‘Administrators’ Group and it also means that Brenton B. and Jason P. are members of the ‘Geeks’ Local Group. It will not, however, traverse to the second level and grant Brenton B. and Jason P. group membership to Administrators.

 

What About Restricted Groups in Group Policies?

 

RestrictedLocation

groupadded 

 

 

 

 

 

This issue unfortunately is also present when you have Restricted Groups. Restricted Groups within Group Policies force group associations to the local groups in the Operating System. While you mandate the ‘TestAdmin’ Group as part of the Built-in Administrators Local Group, the permission lookup occurs on the Windows Operating System; thus the Nested Groups do not traverse.

Can You Still Add Groups To Built-in Groups?

groups

Yes, as shown above! While the GUI of Windows does not provide a method to directly add Groups within Built-in Groups, you can execute two commands that would provide for adding Groups in Groups.

Method 1 – Powershell

   1: # Obtain the Current Computer Name

   2: $cmpName = [System.Net.DNS]::GetHostName()

   3:  

   4: # Make the ADSI Call into the Computer

   5: $adsiCall = [ADSI] ("WinNT://$cmpName,computer")

   6:  

   7: # Create the worker variable

   8: $objworker = $adsiCall.Create("group","Geeks")

   9: $objworker.put("description","Geeks Local Group")

  10:  

  11: # Create Object from worker variable

  12: $objworker.setinfo()

  13:  

  14: # Create the Group Association

  15: $adsistring = "$cmpName/Administrators,group"

  16:  

  17: # Create the worker variable

  18: $group = [adsi] ("WinNT://$adsistring")

  19:  

  20: # Add the group

  21: $group.add("WinNT://$cmpName/Geeks")

Method 2 – NET Commands in BAT File

   1: net localgroup "Geeks" /Add

   2: net localgroup "Administrators" "Geeks" /Add

* The above Methods add the ‘Geeks’ local Group, then add the ‘Geeks’ Local Group to the ‘Administrators’ Group

 

Resolution to the Issue

The following can be performed to resolve the issue:

#1 Add the Users of the Geeks Group directly to the Built-in Administrators Group.

#2 Create a Domain Global Group named ‘Geeks’ and place the Domain Global Group ‘Geeks’ in the Local Administrators Restricted Group.

Supporting documents: According to Microsoft’s knowledge Base articles

http://technet.microsoft.com/en-us/library/ee681621(WS.10).aspx … “This is the expected behavior of the Computer Management snap-in.”

and

http://support.microsoft.com/kb/974815 … where we can quote directly “This behavior is by design. Windows does not support the nesting of local groups on domain clients or on workgroup clients.”

 

UPDATED! Let me explain this one a bit more – I received an email From Microsoft that explained the nesting functionality as follows:

“The process of determining the security-groups a user belongs to is called group expansion, which is an integral part of user authentication. It is necessary that the group expansion accurately generates a list containing the groups that the user is a member of (directly or indirectly) in order to allow the user accesses to various resources. It is by design that group membership does not expand nested local groups.

Microsoft’s intention was to disallow nesting groups in group authoring experience (as in the case of the UI) to accurately reflect group expansion constraints. As your examples point out, there are several ways of nesting local groups, contrary to our intention. Our suggestion is to never nest local groups even when it is allowed by a group authoring tool like “net local group” because such nesting doesn’t reflect the group expansion constraints and the end results would be different from the expected results.”

What Microsoft is saying in a formal way – Their design for group expansion model does not include the ability to look through multiple levels of local Nested Groups. It only provides the ability to look one level deep due to the way it was developed by Microsoft. By not knowing how large of an impact it would be to add the ability to nest local groups, I can only assume that Microsoft does not think it is advantageous to add this functionality due to the number of users that will be using the system in this way – which makes sense.

We were able to get the Local Groups to Accept “Global” and “Domain Local”* active directory groups. While this doesn’t help a stand alone system for nesting of groups, it does provide a work around for authentication. This means that if you were to make the ‘Geeks’ Group, from the first example above, a Active Directory Group, the local system will pass the authentication query to Active Directory which then has the mechanisms to traverse through nested groups.

** Be cautious when adding Domain Local Groups to the system as if you have any forests, or trusts, the security will not traverse through the forest or any trusts. **

A special thanks to Jim Tan, Richard Leung, and Sunil Naik from Microsoft with their help on my issue!

Read Full Post | Make a Comment ( 2 so far )

Default Domain Policies Windows Server 2003 SP2 / Windows server 2008 R2

Posted on February 3, 2010. Filed under: Server Tangents |

By: Brenton Blawat

What would seem like a quick reference item to find on Google, seems to have been lost in the billions of web pages. This article is intended as a quick reference to what the Default Domain Policies are for Windows Server 2003 SP2 and Windows Server 2008 R2. Please note that while some of the policies appear to be identical, the hierarchical structure behind the policies are different.

Default Domain Policies: Windows Server 2003 SP2

+ Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy

– Enforce Password History = 24 Passwords

– Maximum Password Age = 42 Days

– Minimum Password Age = 1 Days

– Minimum Password Length = 7 Characters

– Password must meet complexity requirements = Enabled

– Store Passwords using reversible encryption = Disabled

+ Computer Configuration > Windows Settings > Security Settings > Account Policies > Account Lockout Policy

– Account lockout threshold = 0 invalid logon attempts

+ Computer Configuration > Windows Settings > Security Settings > Account Policies > Kerberos Policy

– Enforce user logon restrictions = Enabled

– Maximum lifetime for service ticket = 600 minutes

– Maximum lifetime for user ticket = 10 hours

– Maximum lifetime for user ticket renewal = 7 days

– Maximum tolerance for computer clock synchronization = 5 minutes

+ Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options

– Network Security: Force Logoff when logon hours expire = Disabled

+ Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Encrypting File System

– Administrator Issued File Recovery Certificate

+ User Settings > Windows Settings > Security Settings > Public Key Policies > Autoenrollment Settings

– Enroll Certificates Automatically

 

Default Domain Policies: Windows Server 2008 R2 64-bit

+ Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy

– Enforce Password History = 24 Passwords

– Maximum Password Age = 42 Days

– Minimum Password Age = 1 Days

– Minimum Password Length = 7 Characters

– Password must meet complexity requirements = Enabled

– Store Passwords using reversible encryption = Disabled

+ Computer Configuration > Policy > Windows Settings > Security Settings > Account Policies > Account Lockout Policy

– Account lockout threshold = 0 invalid logon attempts

+ Computer Configuration > Policy > Windows Settings > Security Settings > Account Policies > Kerberos Policy

– Enforce user logon restrictions = Enabled

– Maximum lifetime for service ticket = 600 minutes

– Maximum lifetime for user ticket = 10 hours

– Maximum lifetime for user ticket renewal = 7 days

– Maximum tolerance for computer clock synchronization = 5 minutes

+ Computer Configuration > Policy > Windows Settings > Security Settings > Local Policies > Security Options

– Network access: Allow anonymous SID/Name translation = Disabled

– Network security: Do not store LAN Manager hash value on next password change = Enabled

– Network Security: Force Logoff when logon hours expire = Disabled

+ Computer Configuration > Policy > Windows Settings > Security Settings > Public Key Policies > Encrypting File System

– Administrator Issued File Recovery Certificate

+ Computer Configuration > Policy > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities

– Allow users to select new root certification authorities (CAs) to trust = Enable

– Client computers can trust the following certificate stores = Third-Party Root Certification Authorities and Enterprise Root Certification Authorities

– To perform certificate-based authentication of users and computers, CAs must meet the criteria = Registered in Active Directory only

 

Default Domain Policy Differences: Windows Server 2003 / Windows Server 2008

Default Domain Policies added to Windows Server 2008

+ Computer Configuration > Policy > Windows Settings > Security Settings > Local Policies > Security Options

– Network access: Allow anonymous SID/Name translation = Disabled

– Network security: Do not store LAN Manager hash value on next password change = Enabled

+ Computer Configuration > Policy > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities

– Allow users to select new root certification authorities (CAs) to trust = Enable

– Client computers can trust the following certificate stores = Third-Party Root Certification Authorities and Enterprise Root Certification Authorities

– To perform certificate-based authentication of users and computers, CAs must meet the criteria = Registered in Active Directory only

Removed from Windows Server 2008

+ User Settings > Windows Settings > Security Settings > Public Key Policies > Autoenrollment Settings

– Autoenrollment Settings: Enroll Certificates Automatically

** NOTE: All re-productions / digital copies of this content must be approved in writing by an authorized representative of BIT Tangents.**

Read Full Post | Make a Comment ( 4 so far )

    About

    Business and Information Technology Tangents is dedicated to providing quality content while informing the world about technology.

    RSS

    Subscribe Via RSS

    • Subscribe with Bloglines
    • Add your feed to Newsburst from CNET News.com
    • Subscribe in Google Reader
    • Add to My Yahoo!
    • Subscribe in NewsGator Online
    • The latest comments to all posts in RSS

    Meta

Liked it here?
Why not try sites on the blogroll...