Monthly Archives: May 2012

Windows

What’s special about the builtin Administrator account?

2 Comments

Every installation of Windows based on the Windows NT code base has a builtin admin account called Administrator. Every installation of Active Directory Directoy Services also has a builtin admin account called Administrator. (If you are running a version of Windows other than English, your accounts may be named something else.) This account provides complete access to files, directories, services, and other facilities. But are there other things that make these account special?

  • The Relative Identifier (RID) is always 500
    In Windows each Security Principal is identified with a Security Identifier or SID. The SIDs have two parts; the machine or domain component and the Relative Identifier (RID). The RID is simply a whole number incremented with one (1) each time a new Security Principal, typically a group or user, is created. The builtin Administrator accounts, whether they are in a local SAM database or in Active Directory, always have the RID 500. This means that if you know the domain or machine component of the SID, you also know the full SID of the builtin Administrator. From there it is easy to do a “reverse lookup” and find the actual username of the builtin Administrator, and then to start trying to break into it. (Some older code even lets you authenticate with the SID directly, as opposed to a username.) See next bullet.
  • The account cannot be locked out
    The builtin Administrator account cannot be locked out of the system no matter how many failed logon attempts it accumulates. This makes it a prime target for brute force attacks. Auditing can help you find out if someone is trying to do a brute force attack using the builtin Administrator account. Other, manually created, administrator accounts can be locked out, and therefore do not present a similar threat. Renaming your builtin Administrator account will afford you some protection, but be aware of the limitations of this; see previous bullet.
  • The account cannot be deleted
    At least not using the default Windows tools.
  • The account is disabled on client OSs as of Windows XP
    In Windows XP and onwards, the builtin Administrator account does not have a password and is disabled. During setup you are required to create at least one new account, and this account becomes an administrator.
Active Directory

Letting go of Windows NT 4.0…

Leave a comment

Windows Server 2008 R2 Domain Controllers have left Windows NT 4.0 behind. Windows Server 2008 would still let the old guy play along, but no more. This fact is not apparant until you start to look closer:

  • DCPromo in Windows Server 2008 R2 will not let you select Windows 2000 mixed mode for your domain functional level.
    This in turn makes it impossible to add a Windows NT 4.0 BDC to your domain.
  • A trust cannot be created between a Windows NT 4.0 domain and a Windows Server 2008 R2 domain.
    The security changes introduced in Windows Server 2008 R2 prevent this. (http://support.microsoft.com/?id=942564)
  • Windows NT 4.0 compatible cryptographic algorithms are not enabled in a Windows Server 2008 R2 domain.
    They can be enabled, but this, still, will not let you create a trust between Windows NT 4.0 and Windows Server 2008 R2. (http://support.microsoft.com/?id=942564)

I guess it  was finally time to move along…

Virtualization

Working with differencing disks in VirtualBox

1 Comment

For some time now I have been trying to make persistent differencing disks work in VirtualBox. The idea is to have one base disk with all the software that all the VMs you want to deploy needs. Typically the OS, all patches up until the time you created the base disk, common apps like Flash etc. You then generalize this disk. In the Windows world this means running the System Preparation Tool (sysprep.exe) to remove all machine specific data from a VM. Now you can use this disk as the starting point for several new VMs and save a lot of disk space. Typically all virtualization software is able to use a differencing disk, or delta disk, for each VM. This disk only stores the changes made to the base disk in a new disk file, without making any changes to the base disk itself.

In VirtualBox the immutable disk type is what you use for the base disk. Once it is generalized you change its type from normal to immutable. Whenever you create a new VM and connect the immutable disk to it; VirtualBox will create a differencing disk with the VMs changes. This is where I have been having problems. In my scenario I want to keep the VM state in the differencing disk file between reboots, but VirtualBox, by default, will reset the differencing disk on every power cycle of the VM if the VM is running with an immutable base disk. According to the documentation you can modify this behaviour with the VBoxManage.exe tool. Here’s how:

VBoxManage.exe modifyhd <differencing disk file or disk uuid> –autoreset off

This is what I have been doing with my differencing disks. When I later inspected the disk with VBoxManage.exe, it correctly stated that autoreset was indeed off. But whenever the VM power cycled the disk was reset and the autoreset flag was set back to on.

Initially I thought that maybe this was a bug in VirtualBox regarding the VHD disk format, which is what I use for all my VMs, but the same problem exists with VirtualBox’s own virtual disk format VDI. I also read several posts from other people struggelig with this functionality, but their problems were related to the actual use of VBoxManage.exe, were for different host OSs (I use Windows 7/8), or something else. The reason I kept on trying, though, was that some people were actually able to make it work.

At some point I found another disk type in VirtualBox, the multiattach type. I really had not used it before since all the documentation on how use persistent differencing disks in VirtualBox used immutable disks. This is what the VirtualBox documentation online has to say about the multiattach disk type:

An image in multiattach mode can be attached to more than one virtual machine at the same time, even if these machines are running simultaneously. For each virtual machine to which such an image is attached, a differencing image is created. As a result, data that is written to such a virtual disk by one machine is not seen by the other machines to which the image is attached; each machine creates its own write history of the multiattach image.

Technically, a “multiattach” image behaves identically to an “immutable” image except the differencing image is not reset every time the machine starts.

So there it was! The multiattach disk type is the one to use! I changed by base disk from immutable to multiattach and now my VMs keep their differencing disks across power cycles. It seems that even though VBoxManage.exe can change the autoreset type of a differencing disk that is running off an immutable disk; the flag is not honored and is reset on every power cycle. The question now is why you can actually change that flag when it will not be honored? Would be very simple to just inform the user that immutable disks will always reset, and that multiattach should be used if you want to keep the VM state.

Anyway, VirtualBox is a great product, and also free!

Here is the link regarding the disk types in VirtualBox: http://www.virtualbox.org/manual/ch05.html#hdimagewrites

Until next time!

Active Directory

Poor-man’s Active Directory backups (export really)

Leave a comment

Sometimes I need a “copy” of an Active Directory domain, partition or LDS instance. Usually this is when I remove decomissioned domains in a multi-domain forest and want to keep a record of what was left when I deleted it. You can do this With LDIFDE.EXE. Here is an example command to make a full export of a domain partition:

ldifde.exe -f <path and name of export file>.ldf -d “<DN of partition” -p subtree -x -l * -j <path to log folder>

I mean; you can never be too sure right?