WindowsXP-SP1/admin/admt/documents/help-ms/conceptdommigsecurityissues.htm
2020-09-30 16:53:49 +02:00

38 lines
3.6 KiB
HTML

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
"http://www.w3.org/TR/REC-html40/strict.dtd">
<HTML DIR="LTR">
<HEAD>
<TITLE>Understanding security</TITLE>
<LINK REL="stylesheet" MEDIA="screen" TYPE="text/css" HREF="coUA.css">
<LINK REL="stylesheet" MEDIA="print" TYPE="text/css" HREF="coUAprint.css">
<SCRIPT LANGUAGE="JScript" SRC="shared.js"></SCRIPT>
<META HTTP-EQUIV="Content-Type" CONTENT="text-html;charset=Windows-1252">
<META HTTP-EQUIV="PICS-Label" CONTENT='(PICS-1.1 "<http://www.rsac.org/ratingsv01.html>" l comment "RSACi North America Server" by "inet@microsoft.com <mailto:inet@microsoft.com>" r (n 0 s 0 v 0 l 0))'>
<META NAME="MS.LOCALE" CONTENT="EN-US">
<META NAME="MS-IT-LOC" Content="Active Directory Migration Tool">
<META NAME="MS-HAID" CONTENT="a_ConceptDomMigSecurityIssues">
</HEAD>
<BODY>
<H1>Understanding security</H1>
<P>In Windows&nbsp;NT and Windows&nbsp;2000, all <A ID="wPopup" HREF="HELP=ADMTGlos.hlp TOPIC=SecurityPrincipal"> security principals</A> (user accounts, groups, and computer accounts) are represented by unique security identifiers (SIDs). For normal security principals, part of each <A ID="wPopup" HREF="HELP=ADMTGlos.hlp TOPIC=SID">SID</A> identifies the domain to which the security principal belongs. The SID is independent of the security principal name and is used by Windows&nbsp;NT and Windows&nbsp;2000 to identify the individual security principals and to control access to resources.</P>
<P>Access to network resources (printers, files, folders, and shares) in Windows&nbsp;NT and Windows&nbsp;2000 is protected by access control lists (ACLs) that list individual SIDs and the rights and permissions that each has been granted.</P>
<H2>Accessing resources</H2>
<P>When users successfully log on to a Windows&nbsp;NT and Windows&nbsp;2000 network, they are assigned an access token that lists their primary SID and also lists the SIDs of all of the groups to which they belong. When a particular user tries to access a resource, the security system compares the SID in the access token and the access sought, with the SID in the ACL and the access granted or denied, then grants the appropriate rights. For example, if the user requests read rights and the ACL can grant the user both read and write rights, the system will only grant the user read rights.</P>
<H2>Migrating security principals</H2>
<P>When you migrate a security principal from domain A to domain B, a new security principal is created (or cloned) in domain B. SIDs contain a component that specifies the domain to which the security principal belongs, so this new security principal has the same name as the original security principal, but it has a different SID.</P>
<P>The new security principal is not a member of the same groups and its SID does not appear in the <A ID="wPopup" HREF="HELP=ADMTGlos.hlp TOPIC=SecurityDescriptor"> security descriptors</A> of the various resources, so the new security principal does not have the same rights and permissions as the original.</P>
<P>In order for these new security principals to keep their existing access to resources, a <A ID="wPopup" HREF="HELP=ADMTGlos.hlp TOPIC=SIDHistory">SID History</A> is created. This SID History contains SIDs previously associated with the original security principal. When the user logs on to the system, the system retrieves the SID History entries and adds them to the user's access token. The access token then contains the SID of the new security principal and the SIDs associated with the original security principal. This provides the new security principal the same access to resources as the original.</P>
</BODY>
</HTML>