Local and domain SIDs -- WAS: Is there any way to change the vm computer name which joined AD

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Dec 24, 2012 at 4:01 AM, Timon Wang <timonwst@xxxxxxxxx> wrote:
> If a vm join AD domain, the name is registered in the AD server, when I copy
> a VM, the name will conflict with the source VM.
> I wanna to know if I can change the VM computer name automaticly.

This is not a hostname issue.  This is a pure AD/NT-SID issue**
(Security Identifiers).  It affects all virtualization solutions, even
Hyper-V.

Two (2) systems must have unique SID enumeration.**  When you have
standalone systems that are not part of a domain, as long as the two
systems never see each other, it's typically not an issue.  But when
they are part of a domain, it is an issue, because there must be an
unique SID enumeration for any domain member.

You should never clone/create/instance/etc... a system once it's been
joined to a domain, unless you use a solution that undoes its SID
enumeration.

Microsoft introduce sysprep years ago so when a system reboots, new
local SIDs** are enumerated.  This is recommended for all systems when
cloned, whether they join an AD domain later or not.

Some virtualization solutions don't bother to sysprep the system
before joining them to a domain.  This is because the SID enumeration
in a domain is domain-wide, and the local SIDs are usually not
utilized.  This drastically reduces issues although there can still be
issues between two nodes that have the same local SID enumeration.**

There is no way around this issue, as it's a core NT issue.  The
recommended solutions are to either ...
 - Always run SysPrep before making a template, regardless whether an
AD member or not
 - Join the domain as part of a local group policy before the system
comes up (e.g., still has duplicate local SIDs)

In oVirt/RHEV, you can join the domain as part of the SysPrep scripts.
 The easiest way to do this is to create an user in your AD domain
that only has the delegation and no other role.  The system is joined
to the AD domain upon first boot of the VM instance using that user.

-- bjs, MCITP/MCSE/MCSA

**NT INTERNALS NOTE:  The local System Accounts Manager (SAM) and
other portions of the local NT systems' Registry, as well as the local
NTFS file systems attributes, are where local SID are stored and
utilized.  The first NT system promoted to a Domain Controller (DC)
has its SAM and SID enumeration because the initial, network-wide SIDs
for the domain (that's an over-simplification, but similar), and it no
longer has its local enumeration (all DCs are like this, there is
still a local SAM/SID enumeration, but it is not referenced, which is
a long and complicated story with some issues).  When a local system
joins a domain, and becomes a domain member, it starts using those SID
references.  The local SAM/SID still exist and are known (unlike a DC,
which stops using them altogether), but are typically not utilized.
So SIDs are usually no longer an issue, unless you have member
workstations/servers directly accessing and managing other member
workstations/servers (e.g., IPC like to C$ or similar).

It is very, very important that anyone managing Windows systems
understand these internals, especially when it comes to domains.
Sadly a lot of MCSEs (especially older ones) don't seem to, among
other NT and AD internals.  Microsoft still doesn't offer a good AD
internals course, although they do have a good NT internals course
as well as set of books.


--
Bryan J Smith - Professional, Technical Annoyance
b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith
----------------------------------------------------------
Computers are precise, but not accurate, and make mistakes
due to lack of input, as lack of awareness and observation

_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users


[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux