No Override as Compared to Block Policy Inheritance
You can set No Override on a specific Group Policy object link so that Group Policy objects linked at a lower-level of Active Directory — closer to the recipient user or computer account — cannot override that policy. If you do this, Group Policy objects linked at the same level, but not as No Override , are also prevented from overriding. If you have several links set to No Override , at the same level of Active Directory, then you need to prioritize them. Links higher in the list have priority on all Configured (that is, Enabled or Disabled ) settings.
If you have linked a specific Group Policy object to a domain, and set the Group Policy object link to No Override , then the configured Group Policy settings that the Group Policy object contains apply to all organizational units under that domain. Group Policy objects linked to organizational units cannot override that domain-linked Group Policy object.
You can also block inheritance of Group Policy from above in Active Directory. This is done by checking Block Policy inheritance on the Group Policy tab of the Properties sheet of the domain or organizational unit. This option does not exist for a site.
Some important facts about No Override and Block Policy are listed below:
• No Override is set on a link, not on a site, domain, organizational unit, or Group Policy object.
• Block Policy Inheritance is set on a domain or organizational unit, and therefore applies to all Group Policy objects linked at that level or higher in Active Directory which can be overridden.
• No Override takes precedence over Block Policy Inheritance if the two are in conflict.
If you want to see what a Group Policy object is linked to, open it in the Group Policy console , right-click the root node, click Properties , and then click the Links tab. Click Find Now after setting the domain on the drop-down menu.
Showing posts with label Active Directory. Show all posts
Showing posts with label Active Directory. Show all posts
Tuesday, April 20, 2010
FSMO Roles
Introduction
In a Windows 2000 domain environment, all of the domain controllers are piers. There are no PDCs and BDCs that you find in a Windows NT domain. All Windows 2000 domain controllers contain a writable replica (or copy) of the Active Directory Database, and unlike the hierarchical server structure in a Windows NT domain (the PDC with subordinate BDCs), all domain controllers are equal.
The ability of all domain controllers in a Windows 2000 domain to update Active Directory, and then replicate it out to the other DCs, is referred to as Multimaster Replication. Compare that to a Windows NT domain which uses Single Master replication - the PDC has the only writable copy of the SAM and all updates can only happen at the PDC.
(The SAM, Security Accounts Database, is replaced by the Active Directory Database in Windows 2000.)
So why are there FSMO server roles? Since each DC in a Windows 2000 domain can update the Active Directory, which then gets replicated to all othe DCs, what happens if more than one person is making the same change to Active Directory at the same time? There are certain rules that are followed to prevent conflicts in updating the AD database, but some changes are to important to the domain to be left to these rules. Because of this, Microsoft came up with the idea of the Flexible Single Master Operations server roles. The servers that hold these FSMO roles are responsible for updating certain aspects of Active Directory. By making designated servers responsible for certain updates, instead of allowing every server to make all updates, you prevent conflicts in Active Directory updates.
In a Windows 2000 Domain environment, there are 5 server roles that are necessary for the proper functioning of the forest/domain (or Active Directory). These 5 server roles are collectively known as the Flexible Single Master Operations Roles or FSMO roles. All FSMO server roles exist on Domain Controllers. They do not exist on member servers. Two of the server roles exist at the Forest level and 3 server roles exist at the Domain level.
For example: If your Active Directory contains one forest and 1 domain, you would have 5 FSMO role holders. If your AD contained one forest and 2 domains, you would have 8 FSMO role holders - two at the forest level and 3 for each domain. Likewise, for an AD with one forest and 3 domains, you would have 11 server roles - two at the forest level and 3 for each domain.
FSMO Roles
The 5 FSMO server roles:
Schema Master Forest Level One per forest
Domain Naming Master Forest Level One per forest
PDC Emulator Domain Level One per domain
RID Master Domain Level One per domain
Infrastructure Master Domain Level One per domain
1. Schema Master (Forest level)
The schema master FSMO role holder is the Domain Controller responsible for performing updates to the active directory schema. It contains the only writable copy of the AD schema. This DC is the only one that can process updates to the directory schema, and once the schema update is complete, it is replicated from the schema master to all other DCs in the forest. There is only one schema master in the forest.
2. Domain Naming Master (Forest level)
The domain naming master FSMO role holder is the DC responsible for making changes to the forest-wide domain name space of the directory. This DC is the only one that can add or remove a domain from the directory, and that is it's major purpose. It can also add or remove cross references to domains in external directories. There is only one domain naming master in the active directory or forest.
3. PDC Emulator (Domain level)
In a Windows 2000 domain, the PDC emulator server role performs the following functions:
Password changes performed by other DCs in the domain are replicated preferentially to the PDC emulator first.
Authentication failures that occur at a given DC in a domain because of an incorrect password are forwarded to the PDC emulator for validation before a bad password failure message is reported to the user.
Account lockout is processed on the PDC emulator.
Time synchronization for the domain.
Group Policy changes are preferentially written to the PDC emulator.
Additionally, if your domain is a mixed mode domain that contains Windows NT 4 BDCs, then the Windows 2000 domain controller, that is the PDC emulator, acts as a Windows NT 4 PDC to the BDCs.
There is only one PDC emulator per domain.
Note: Some consider the PDC emulator to only be relevant in a mixed mode domain. This is not true. Even after you have changed your domain to native mode (no more NT 4 domain controllers), the PDC emulator is still necessary for the reasons above.
4. RID Master (Domain level)
The RID master FSMO role holder is the single DC responsible for processing RID Pool requests from all DCs within a given domain. It is also responsible for removing an object from its domain and putting it in another domain during an object move.
When a DC creates a security principal object such as a user, group or computer account, it attaches a unique Security ID (SID) to the object. This SID consists of a domain SID (the same for all SIDs created in a domain), and a relative ID (RID) that makes the object unique in a domain.
Each Windows 2000 DC in a domain is allocated a pool of RIDs that it assigns to the security principals it creates. When a DC's allocated RID pool falls below a threshold, that DC issues a request for additional RIDs to the domain's RID master. The domain RID master responds to the request by retrieving RIDs from the domain's unallocated RID pool and assigns them to the pool of the requesting DC.
There is one RID master per domain in a directory.
5. Infrastructure Master (Domain level)
The DC that holds the Infrastructure Master FSMO role is responsible for cross domain updates and lookups. When an object in one domain is referenced by another object in another domain, it represents the reference by the GUID, the SID (for references to security principals), and the distinguished name (DN) of the object being referenced. The Infrastructure role holder is the DC responsible for updating an object's SID and distinguished name in a cross-domain object reference.
When a user in DomainA is added to a group in DomainB, then the Infrastructure master is involved. Likewise, if that user in DomainA, who has been added to a group in DomainB, then changes his username in DomainA, the Infrastructure master must update the group membership(s) in DomainB with the name change.
There is only one Infrastructure master per domain.
In a Windows 2000 domain environment, all of the domain controllers are piers. There are no PDCs and BDCs that you find in a Windows NT domain. All Windows 2000 domain controllers contain a writable replica (or copy) of the Active Directory Database, and unlike the hierarchical server structure in a Windows NT domain (the PDC with subordinate BDCs), all domain controllers are equal.
The ability of all domain controllers in a Windows 2000 domain to update Active Directory, and then replicate it out to the other DCs, is referred to as Multimaster Replication. Compare that to a Windows NT domain which uses Single Master replication - the PDC has the only writable copy of the SAM and all updates can only happen at the PDC.
(The SAM, Security Accounts Database, is replaced by the Active Directory Database in Windows 2000.)
So why are there FSMO server roles? Since each DC in a Windows 2000 domain can update the Active Directory, which then gets replicated to all othe DCs, what happens if more than one person is making the same change to Active Directory at the same time? There are certain rules that are followed to prevent conflicts in updating the AD database, but some changes are to important to the domain to be left to these rules. Because of this, Microsoft came up with the idea of the Flexible Single Master Operations server roles. The servers that hold these FSMO roles are responsible for updating certain aspects of Active Directory. By making designated servers responsible for certain updates, instead of allowing every server to make all updates, you prevent conflicts in Active Directory updates.
In a Windows 2000 Domain environment, there are 5 server roles that are necessary for the proper functioning of the forest/domain (or Active Directory). These 5 server roles are collectively known as the Flexible Single Master Operations Roles or FSMO roles. All FSMO server roles exist on Domain Controllers. They do not exist on member servers. Two of the server roles exist at the Forest level and 3 server roles exist at the Domain level.
For example: If your Active Directory contains one forest and 1 domain, you would have 5 FSMO role holders. If your AD contained one forest and 2 domains, you would have 8 FSMO role holders - two at the forest level and 3 for each domain. Likewise, for an AD with one forest and 3 domains, you would have 11 server roles - two at the forest level and 3 for each domain.
FSMO Roles
The 5 FSMO server roles:
Schema Master Forest Level One per forest
Domain Naming Master Forest Level One per forest
PDC Emulator Domain Level One per domain
RID Master Domain Level One per domain
Infrastructure Master Domain Level One per domain
1. Schema Master (Forest level)
The schema master FSMO role holder is the Domain Controller responsible for performing updates to the active directory schema. It contains the only writable copy of the AD schema. This DC is the only one that can process updates to the directory schema, and once the schema update is complete, it is replicated from the schema master to all other DCs in the forest. There is only one schema master in the forest.
2. Domain Naming Master (Forest level)
The domain naming master FSMO role holder is the DC responsible for making changes to the forest-wide domain name space of the directory. This DC is the only one that can add or remove a domain from the directory, and that is it's major purpose. It can also add or remove cross references to domains in external directories. There is only one domain naming master in the active directory or forest.
3. PDC Emulator (Domain level)
In a Windows 2000 domain, the PDC emulator server role performs the following functions:
Password changes performed by other DCs in the domain are replicated preferentially to the PDC emulator first.
Authentication failures that occur at a given DC in a domain because of an incorrect password are forwarded to the PDC emulator for validation before a bad password failure message is reported to the user.
Account lockout is processed on the PDC emulator.
Time synchronization for the domain.
Group Policy changes are preferentially written to the PDC emulator.
Additionally, if your domain is a mixed mode domain that contains Windows NT 4 BDCs, then the Windows 2000 domain controller, that is the PDC emulator, acts as a Windows NT 4 PDC to the BDCs.
There is only one PDC emulator per domain.
Note: Some consider the PDC emulator to only be relevant in a mixed mode domain. This is not true. Even after you have changed your domain to native mode (no more NT 4 domain controllers), the PDC emulator is still necessary for the reasons above.
4. RID Master (Domain level)
The RID master FSMO role holder is the single DC responsible for processing RID Pool requests from all DCs within a given domain. It is also responsible for removing an object from its domain and putting it in another domain during an object move.
When a DC creates a security principal object such as a user, group or computer account, it attaches a unique Security ID (SID) to the object. This SID consists of a domain SID (the same for all SIDs created in a domain), and a relative ID (RID) that makes the object unique in a domain.
Each Windows 2000 DC in a domain is allocated a pool of RIDs that it assigns to the security principals it creates. When a DC's allocated RID pool falls below a threshold, that DC issues a request for additional RIDs to the domain's RID master. The domain RID master responds to the request by retrieving RIDs from the domain's unallocated RID pool and assigns them to the pool of the requesting DC.
There is one RID master per domain in a directory.
5. Infrastructure Master (Domain level)
The DC that holds the Infrastructure Master FSMO role is responsible for cross domain updates and lookups. When an object in one domain is referenced by another object in another domain, it represents the reference by the GUID, the SID (for references to security principals), and the distinguished name (DN) of the object being referenced. The Infrastructure role holder is the DC responsible for updating an object's SID and distinguished name in a cross-domain object reference.
When a user in DomainA is added to a group in DomainB, then the Infrastructure master is involved. Likewise, if that user in DomainA, who has been added to a group in DomainB, then changes his username in DomainA, the Infrastructure master must update the group membership(s) in DomainB with the name change.
There is only one Infrastructure master per domain.
Delegate permission for AD user
To allow an ordinary user, or group, to add a computer to a domain, you can use either of the following:
• Assign rights using the Default Domain Group policy.
• Delegate rights using Active Directory Users and Computers.
Assign rights using the Default Domain Group policy:
1. Open the Default Domain Group policy.
2. Navigate through Computer Configuration / Windows Settings / Security Settings / Local Policies / User Rights Assignment.
3. Expand User Rights Assignment.
4. Double-click Add workstations to Domain.
5. Check the Define these policy settings box.
6. Press the Add User or Group button.
7. Complete the dialog to add the user or group.
8. Press Apply and OK.
Delegate rights using Active Directory Users and Computers:
1. Open the Active Directory Users and Computers snap-in.
2. Right-click the container under which you want the computers added, and press Delegate Control.
3. Press Next.
4. Press Add.
5. After adding all the users and/or groups, press Next.
6. Select Create custom task to delegate and press Next.
7. Select Only the following objects in the folder, check Computer objects, check the Create selected objects in this folder box, and press Next.
8. Check the Create all child object box and press Next.
9. Press Finish.
• Assign rights using the Default Domain Group policy.
• Delegate rights using Active Directory Users and Computers.
Assign rights using the Default Domain Group policy:
1. Open the Default Domain Group policy.
2. Navigate through Computer Configuration / Windows Settings / Security Settings / Local Policies / User Rights Assignment.
3. Expand User Rights Assignment.
4. Double-click Add workstations to Domain.
5. Check the Define these policy settings box.
6. Press the Add User or Group button.
7. Complete the dialog to add the user or group.
8. Press Apply and OK.
Delegate rights using Active Directory Users and Computers:
1. Open the Active Directory Users and Computers snap-in.
2. Right-click the container under which you want the computers added, and press Delegate Control.
3. Press Next.
4. Press Add.
5. After adding all the users and/or groups, press Next.
6. Select Create custom task to delegate and press Next.
7. Select Only the following objects in the folder, check Computer objects, check the Create selected objects in this folder box, and press Next.
8. Check the Create all child object box and press Next.
9. Press Finish.
Active Directory partiotions
The Active Directory database is logically separated into directory partitions:
• Schema partition
• Configuration partition
• Domain partition
• Application partition
Each partition is a unit of replication, and each partition has its own replication topology. Replication occurs between replicas of directory partition. Minimum two directory partitions are common among all domain controllers in the same forest: the schema and configuration partitions. All domain controllers which are in the same domain, in addition, share a common domain partition.
Schema Partition
Only one schema partition exists per forest. The schema partition is stored on all domain controllers in a forest. The schema partition contains definitions of all objects and attributes that you can create in the directory, and the rules for creating and manipulating them. Schema information is replicated to all domain controllers in the attribute definitions.
Configuration Partition
There is only one configuration partition per forest. Second on all domain controllers in a forest, the configuration partition contains information about the forest-wide active directory structure including what domains and sites exist, which domain controllers exist in each forest, and which services are available. Configuration information is replicated to all domain controllers in a forest.
Domain Partition
Many domain partitions can exist per forest. Domain partitions are stored on each domain controller in a given domain. A domain partition contains information about users, groups, computers and organizational units. The domain partition is replicated to all domain controllers of that domain. All objects in every domain partition in a forest are stored in the global catalog with only a subset of their attribute values.
Application Partition
Application partitions store information about application in Active Directory. Each application determines how it stores, categorizes, and uses application specific information. To prevent unnecessary replication to specific application partitions, you can designate which domain controllers in a forest host specific application partitions. Unlike a domain partitions, an application partition cannot store security principal objects, such as user accounts. In addition, the data in an application partition is not stored in the global catalog.
As an example of application partition, if you use a Domain Name System (DNS) that is integrated with Active Directory you have two application partitions for DNS zones -- ForestDNSZones and DomainDNSZones:
• ForestDNSZones is part of a forest. All domain controllers and DNS servers in a forest receive a replica of this partition. A forest-wide application partition stores the forest zone data.
• DomainDNSZones is unique for each domain. All domain controllers that are DNS servers in that domain receive a replica of this partition. The application partitions store the domain DNS zone in the DomainDNSZones.
Each domain has a DomainDNSZones partition, but there is only one ForestDNSZones partition. No DNS data is replicated to the global catalog server.
• Schema partition
• Configuration partition
• Domain partition
• Application partition
Each partition is a unit of replication, and each partition has its own replication topology. Replication occurs between replicas of directory partition. Minimum two directory partitions are common among all domain controllers in the same forest: the schema and configuration partitions. All domain controllers which are in the same domain, in addition, share a common domain partition.
Schema Partition
Only one schema partition exists per forest. The schema partition is stored on all domain controllers in a forest. The schema partition contains definitions of all objects and attributes that you can create in the directory, and the rules for creating and manipulating them. Schema information is replicated to all domain controllers in the attribute definitions.
Configuration Partition
There is only one configuration partition per forest. Second on all domain controllers in a forest, the configuration partition contains information about the forest-wide active directory structure including what domains and sites exist, which domain controllers exist in each forest, and which services are available. Configuration information is replicated to all domain controllers in a forest.
Domain Partition
Many domain partitions can exist per forest. Domain partitions are stored on each domain controller in a given domain. A domain partition contains information about users, groups, computers and organizational units. The domain partition is replicated to all domain controllers of that domain. All objects in every domain partition in a forest are stored in the global catalog with only a subset of their attribute values.
Application Partition
Application partitions store information about application in Active Directory. Each application determines how it stores, categorizes, and uses application specific information. To prevent unnecessary replication to specific application partitions, you can designate which domain controllers in a forest host specific application partitions. Unlike a domain partitions, an application partition cannot store security principal objects, such as user accounts. In addition, the data in an application partition is not stored in the global catalog.
As an example of application partition, if you use a Domain Name System (DNS) that is integrated with Active Directory you have two application partitions for DNS zones -- ForestDNSZones and DomainDNSZones:
• ForestDNSZones is part of a forest. All domain controllers and DNS servers in a forest receive a replica of this partition. A forest-wide application partition stores the forest zone data.
• DomainDNSZones is unique for each domain. All domain controllers that are DNS servers in that domain receive a replica of this partition. The application partitions store the domain DNS zone in the DomainDNSZones.
Each domain has a DomainDNSZones partition, but there is only one ForestDNSZones partition. No DNS data is replicated to the global catalog server.
Active Directory Groups
Active Directory Groups
There are two main groups in Active Directory: Distribution Groups and Security Groups.
• Distribution Groups are used to gather a specific set of users for non-security-related functions. Sending e-mail messages to a distribution group is the primary example of this. You cannot use distribution groups to assign rights and permissions. That is the function of a Security Group.
• Security Groups are used to gather a specific set of users for the specific reason of assigning access rights and permissions via the group rather than individually to each user object.
Active Directory uses a subset of both of these groups, as outlined below.
• Security Domain local groups are where permissions are set to grant user access to network resources, such as files, folders, or printers in a single domain.
• Distribution Domain local groups allow the non-security-related function (e.g., e-mail) for group members of the single domain.
Domain Local Groups in a Mixed Mode Domain can contain users, global groups and universal groups from any domain in the forest. In Native Mode, they can also contain domain local groups from their own domain as well as be a member of another domain local group from within its own domain.
Security Domain Local Groups can be assigned permissions for any resource in the domain where the domain local group resides.
Security Global Groups organize domain user objects across domains. Distribution Global Groups would allow the non-security-related function (e.g., e-mail) for group members across domains.
Global Groups in a Mixed Mode Domain can contain user accounts from the group's local domain. In Native Mode they can contain other global groups (called Group Nesting) from the local domain.
Global Groups in a Mixed Mode Domain can be members of Domain local groups in any domain in the forest. In Native Mode they can be a member of another global (nested in another Global Group) in its own domain.
Security Global Groups can be assigned permissions for all of the domains in the forest.
Security Universal Groups are used to group users and grant permissions across an entire forest.
Distribution Universal Groups allow the non-security-related function (e.g., e-mail) for group members across the entire forest.
A Windows 2000 domain must be in native mode to create Universal Security Groups. In Mixed Mode only Universal Distribution Groups are available.
Universal Groups can contain user accounts, global groups and universal groups from any domain in the forest and can be a member of Domain local groups and other universal groups in any domain in the forest.
Universal Groups can be assigned permissions for all domains in the forest and should be used to nest global groups so that permissions can be more easily assigned to related resources in multiple domains. Individual users should not be added singly to universal groups, and you should keep membership changes in Universal Groups to a minimum, as these changes must be replicated throughout the forest.
When setting up access to any server it is important to remember that:
• Authentication determines the identity of a user
• Permissions determine what a valid user can access once authenticated
here are predefined global groups created to group common types of user accounts on Windows 2000 domain controllers.
By default, Windows 2000 automatically adds specific members to some predefined global groups. System administrators can add user objects to these predefined groups to provide additional users with the privileges and permissions assigned to the group.
Domain Admins: Windows 2000 automatically adds Domain Admins to the Administrators built-in domain local group so that members of Domain Admins can perform administrative tasks on any computer anywhere in the domain. By default, the Administrator account is a member. Also, any computer that joins the domain automatically places the Domain Admins group in the Administrators local group.
Domain Guests: Windows 2000 automatically adds Domain Guests to the Guests built-in domain local group. By default, the Guest account is a member.
Domain Users: Windows 2000 automatically adds Domain Users to the Users built-in domain local group. By default, the Administrator, Guest, IUSR_computername, IWAM_ computername, Krbtgt, and TsInternetUser accounts are initially members, and each new domain user account is automatically made a member.
Enterprise Admins: Windows 2000 allows you to add user accounts to Enterprise Admins for users who require administrative control for the entire network, and then adds Enterprise Admins to the Administrators domain local group in each domain. By default, the Administrator account is a member.
Windows 2000 also creates built-in domain local groups in each Active Directory domain. These groups provide all included users with specific user rights and permissions to perform tasks and are set up with predefined rights and permissions.
The most commonly used built-in domain local groups and their default properties are as follows:
• Account Operators: Members of the built-in Account Operators domain local group are allowed by default to create, delete, and modify user and group objects; members cannot modify the Administrators group or any of the operators groups.
• Administrators: Members of the built-in Administrators domain local group are allowed by default to perform all administrative tasks on all domain controllers and on the domain itself. By default, the Administrator user object and the Domain Admins and Enterprise Admins predefined global groups are members.
• Backup Operators: Members of the built-in Backup Operators domain local group are allowed by default to backup and restore all domain controllers using Windows Backup.
• Guests: Members of the built-in Guest domain local group can by default perform only tasks for which you have granted rights; members can gain access only to resources for which you have assigned permissions. Members cannot make permanent changes to their desktop environment. By default, the Guest, IUSR_computername, IWAM_computername, and TsInternetUser user accounts and the Domain Guests predefined global group are members.
• Pre-Windows 2000 Compatible Access: This built-in domain local group is a backward-compatibility group that provides read access for all users and groups in the domain. When you select the Permissions Compatible With Pre-Windows 2000 Servers option in the Active Directory Installation Wizard, the Everyone pre-Windows 2000 system group is made a member.
• Print Operators: Members of the built-in Print Operators domain local group are allowed by default to set up and manage network printers on domain controllers.
• Replicator: This built-in domain local group supports directory replication functions. The only member should be a domain user account used to log on to the Replicator services of the domain controller. Do not add the accounts of actual users to this group.
• Server Operators: Members of the built-in Server Operators domain local group are allowed by default to share disk resources and back up and restore files on a domain controller.
• Users: Mmbers of the built-in Users domain local group are allowed by default to perform only tasks for which you have granted rights, and they can access only the resources for which you have assigned permissions. By default, the Authenticated Users and Interactive pre-Windows 2000 groups, and the Domain Users predefined global group are members. Use this group to assign permissions and rights that every user with an account in your domain should have.
Windows 2000 stand-alone servers, member servers, and computers running the Windows 2000 Professional and Windows XP Professional desktop operating systems all have built-in local groups that give users the rights to perform specific preconfigured system tasks on the local system. Built-in local groups are located in the \Groups folder in the Local Users and Groups snap-in by default as part of the Computer Management console on every computer running Windows 2000 and Windows XP, and all Windows 2000 stand-alone and member servers.
The most commonly used built-in local groups and their default properties are as follows:
• Administrators: Members of the built-in Administrators local group are allowed by default to perform all administrative tasks on the computer. By default, the built-in Administrator user account for the computer is a member. When a member server or computer running Microsoft Windows 2000 Workstation joins a domain, Windows 2000 adds the Domain Admins predefined global group to the local Administrators group.
• Backup Operators: Members of the built-in Backup Operators local group are allowed by default to use Windows Backup to backup and restore the local system.
• Guests: Members of the built-in Guests local group are allowed by default to perform only tasks for which you have specifically granted rights and can access only resources for which you have assigned permissions; members cannot make permanent changes to their desktop environment. By default, the built-in Guest account for the computer is a member. When a member server or a computer running Windows 2000 Workstation joins a domain, Windows 2000 adds the Domain Guests predefined global group to the local guests group.
• Power Users: Members of the built-in Power Users local group are allowed by default to create and modify user accounts on the local system and share resources on the local system.
• Replicator: This built-in local group supports directory replication functions. The only member should be a domain user account used to log on to the Replicator services of the domain controller. Do not add the accounts of actual users t
o this group.
• Users: Members of the built-in Users local group are allowed by default to perform only tasks for which you have specifically granted rights and can access only resources for which you have assigned permissions. By default, Windows 2000 adds to the Users group local user accounts that you create on the computer. When a member server or a computer running Windows 2000 Professional joins a domain, Windows 2000 adds the Domain Users predefined global group to the local Users group.
Special identity groups do not have specific memberships that Administrators directly modify, but they represent different users at different times, depending on how a user accesses a given system or resource on that system. Special identity groups are not found in the Local Computers and Users or Active Directory Users and Computers MMC (Microsoft Management Console) snap-ins for direct administration, but these groups are available for use when you assign rights and permissions to resources.
The most commonly used special identity groups and their default properties are as follows:
• Anonymous Logon special identity group includes any user account that Windows 2000 did not authenticate to the local system, such as an anonymous FTP user.
• Authenticated Users special identity group includes all users with a valid user account on the computer or in Active Directory service. Use the Authenticated Users group instead of the Everyone group to prevent anonymous access to a resource.
• Creator Owner special identity group includes the user account for the user who created or took ownership of a resource. If a member of the Administrators group creates a resource, the Administrators group is owner of the resource.
• Dialup special identity group includes any user who currently has a dial-up connection to the local system.
• Everyone special identity group includes all users who access the computer. Be careful if you assign permissions to the Everyone group and enable the Guest account. Windows 2000 authenticates as Guest a user who does not have a valid user account. The user automatically gets all rights and permissions that you have assigned to the Everyone group. The Everyone group is assigned full control to many resources by default.
• Interactive special identity group includes the user account for the user who is logged on at the local system console. Members of the Interactive group gain access to resources on the computer at which they are physically located.
• Network special identity group includes any user with a current connection from another computer on the network to a shared resource on the computer.
There are two main groups in Active Directory: Distribution Groups and Security Groups.
• Distribution Groups are used to gather a specific set of users for non-security-related functions. Sending e-mail messages to a distribution group is the primary example of this. You cannot use distribution groups to assign rights and permissions. That is the function of a Security Group.
• Security Groups are used to gather a specific set of users for the specific reason of assigning access rights and permissions via the group rather than individually to each user object.
Active Directory uses a subset of both of these groups, as outlined below.
• Security Domain local groups are where permissions are set to grant user access to network resources, such as files, folders, or printers in a single domain.
• Distribution Domain local groups allow the non-security-related function (e.g., e-mail) for group members of the single domain.
Domain Local Groups in a Mixed Mode Domain can contain users, global groups and universal groups from any domain in the forest. In Native Mode, they can also contain domain local groups from their own domain as well as be a member of another domain local group from within its own domain.
Security Domain Local Groups can be assigned permissions for any resource in the domain where the domain local group resides.
Security Global Groups organize domain user objects across domains. Distribution Global Groups would allow the non-security-related function (e.g., e-mail) for group members across domains.
Global Groups in a Mixed Mode Domain can contain user accounts from the group's local domain. In Native Mode they can contain other global groups (called Group Nesting) from the local domain.
Global Groups in a Mixed Mode Domain can be members of Domain local groups in any domain in the forest. In Native Mode they can be a member of another global (nested in another Global Group) in its own domain.
Security Global Groups can be assigned permissions for all of the domains in the forest.
Security Universal Groups are used to group users and grant permissions across an entire forest.
Distribution Universal Groups allow the non-security-related function (e.g., e-mail) for group members across the entire forest.
A Windows 2000 domain must be in native mode to create Universal Security Groups. In Mixed Mode only Universal Distribution Groups are available.
Universal Groups can contain user accounts, global groups and universal groups from any domain in the forest and can be a member of Domain local groups and other universal groups in any domain in the forest.
Universal Groups can be assigned permissions for all domains in the forest and should be used to nest global groups so that permissions can be more easily assigned to related resources in multiple domains. Individual users should not be added singly to universal groups, and you should keep membership changes in Universal Groups to a minimum, as these changes must be replicated throughout the forest.
When setting up access to any server it is important to remember that:
• Authentication determines the identity of a user
• Permissions determine what a valid user can access once authenticated
here are predefined global groups created to group common types of user accounts on Windows 2000 domain controllers.
By default, Windows 2000 automatically adds specific members to some predefined global groups. System administrators can add user objects to these predefined groups to provide additional users with the privileges and permissions assigned to the group.
Domain Admins: Windows 2000 automatically adds Domain Admins to the Administrators built-in domain local group so that members of Domain Admins can perform administrative tasks on any computer anywhere in the domain. By default, the Administrator account is a member. Also, any computer that joins the domain automatically places the Domain Admins group in the Administrators local group.
Domain Guests: Windows 2000 automatically adds Domain Guests to the Guests built-in domain local group. By default, the Guest account is a member.
Domain Users: Windows 2000 automatically adds Domain Users to the Users built-in domain local group. By default, the Administrator, Guest, IUSR_computername, IWAM_ computername, Krbtgt, and TsInternetUser accounts are initially members, and each new domain user account is automatically made a member.
Enterprise Admins: Windows 2000 allows you to add user accounts to Enterprise Admins for users who require administrative control for the entire network, and then adds Enterprise Admins to the Administrators domain local group in each domain. By default, the Administrator account is a member.
Windows 2000 also creates built-in domain local groups in each Active Directory domain. These groups provide all included users with specific user rights and permissions to perform tasks and are set up with predefined rights and permissions.
The most commonly used built-in domain local groups and their default properties are as follows:
• Account Operators: Members of the built-in Account Operators domain local group are allowed by default to create, delete, and modify user and group objects; members cannot modify the Administrators group or any of the operators groups.
• Administrators: Members of the built-in Administrators domain local group are allowed by default to perform all administrative tasks on all domain controllers and on the domain itself. By default, the Administrator user object and the Domain Admins and Enterprise Admins predefined global groups are members.
• Backup Operators: Members of the built-in Backup Operators domain local group are allowed by default to backup and restore all domain controllers using Windows Backup.
• Guests: Members of the built-in Guest domain local group can by default perform only tasks for which you have granted rights; members can gain access only to resources for which you have assigned permissions. Members cannot make permanent changes to their desktop environment. By default, the Guest, IUSR_computername, IWAM_computername, and TsInternetUser user accounts and the Domain Guests predefined global group are members.
• Pre-Windows 2000 Compatible Access: This built-in domain local group is a backward-compatibility group that provides read access for all users and groups in the domain. When you select the Permissions Compatible With Pre-Windows 2000 Servers option in the Active Directory Installation Wizard, the Everyone pre-Windows 2000 system group is made a member.
• Print Operators: Members of the built-in Print Operators domain local group are allowed by default to set up and manage network printers on domain controllers.
• Replicator: This built-in domain local group supports directory replication functions. The only member should be a domain user account used to log on to the Replicator services of the domain controller. Do not add the accounts of actual users to this group.
• Server Operators: Members of the built-in Server Operators domain local group are allowed by default to share disk resources and back up and restore files on a domain controller.
• Users: Mmbers of the built-in Users domain local group are allowed by default to perform only tasks for which you have granted rights, and they can access only the resources for which you have assigned permissions. By default, the Authenticated Users and Interactive pre-Windows 2000 groups, and the Domain Users predefined global group are members. Use this group to assign permissions and rights that every user with an account in your domain should have.
Windows 2000 stand-alone servers, member servers, and computers running the Windows 2000 Professional and Windows XP Professional desktop operating systems all have built-in local groups that give users the rights to perform specific preconfigured system tasks on the local system. Built-in local groups are located in the \Groups folder in the Local Users and Groups snap-in by default as part of the Computer Management console on every computer running Windows 2000 and Windows XP, and all Windows 2000 stand-alone and member servers.
The most commonly used built-in local groups and their default properties are as follows:
• Administrators: Members of the built-in Administrators local group are allowed by default to perform all administrative tasks on the computer. By default, the built-in Administrator user account for the computer is a member. When a member server or computer running Microsoft Windows 2000 Workstation joins a domain, Windows 2000 adds the Domain Admins predefined global group to the local Administrators group.
• Backup Operators: Members of the built-in Backup Operators local group are allowed by default to use Windows Backup to backup and restore the local system.
• Guests: Members of the built-in Guests local group are allowed by default to perform only tasks for which you have specifically granted rights and can access only resources for which you have assigned permissions; members cannot make permanent changes to their desktop environment. By default, the built-in Guest account for the computer is a member. When a member server or a computer running Windows 2000 Workstation joins a domain, Windows 2000 adds the Domain Guests predefined global group to the local guests group.
• Power Users: Members of the built-in Power Users local group are allowed by default to create and modify user accounts on the local system and share resources on the local system.
• Replicator: This built-in local group supports directory replication functions. The only member should be a domain user account used to log on to the Replicator services of the domain controller. Do not add the accounts of actual users t
o this group.
• Users: Members of the built-in Users local group are allowed by default to perform only tasks for which you have specifically granted rights and can access only resources for which you have assigned permissions. By default, Windows 2000 adds to the Users group local user accounts that you create on the computer. When a member server or a computer running Windows 2000 Professional joins a domain, Windows 2000 adds the Domain Users predefined global group to the local Users group.
Special identity groups do not have specific memberships that Administrators directly modify, but they represent different users at different times, depending on how a user accesses a given system or resource on that system. Special identity groups are not found in the Local Computers and Users or Active Directory Users and Computers MMC (Microsoft Management Console) snap-ins for direct administration, but these groups are available for use when you assign rights and permissions to resources.
The most commonly used special identity groups and their default properties are as follows:
• Anonymous Logon special identity group includes any user account that Windows 2000 did not authenticate to the local system, such as an anonymous FTP user.
• Authenticated Users special identity group includes all users with a valid user account on the computer or in Active Directory service. Use the Authenticated Users group instead of the Everyone group to prevent anonymous access to a resource.
• Creator Owner special identity group includes the user account for the user who created or took ownership of a resource. If a member of the Administrators group creates a resource, the Administrators group is owner of the resource.
• Dialup special identity group includes any user who currently has a dial-up connection to the local system.
• Everyone special identity group includes all users who access the computer. Be careful if you assign permissions to the Everyone group and enable the Guest account. Windows 2000 authenticates as Guest a user who does not have a valid user account. The user automatically gets all rights and permissions that you have assigned to the Everyone group. The Everyone group is assigned full control to many resources by default.
• Interactive special identity group includes the user account for the user who is logged on at the local system console. Members of the Interactive group gain access to resources on the computer at which they are physically located.
• Network special identity group includes any user with a current connection from another computer on the network to a shared resource on the computer.
How do I remove a domain controller from Active Directory after an unsuccessful demotion?
The DCPROMO (Dcpromo.exe) utility is used for promoting a server to a domain
controller and demoting a domain controller to a member server (or to a
standalone server in a workgroup if the domain controller is the last in the
domain). As part of the demotion process, the DCPROMO utility removes the
configuration data for the domain controller from the Active Directory. This data
takes the form of an "NTDS Settings" object, which exists as a child to the server
object in the Active Directory Sites and Services Manager .
The information is in the following location in the Active Directory:
CN=NTDS
Settings,CN=,CN=Servers,CN=,CN=Sites,CN=Configu
ration,DC=...
The attributes of the NTDS Settings object include data representing how the
domain controller is identified in respect to its replication partners, the naming
contexts that are maintained on the machine, whether or not the domain
controller is a Global Catalog server, and the default query policy. The NTDS
Settings object is also a container that may have child objects that represent the
domain controller's direct replication partners. This data is required for the
domain controller to operate within the environment, but is retired upon demotion.
In the event that the NTDS Settings object is not removed properly (for example,
the NTDS Settings object is not properly removed from a demotion attempt), the
administrator can use the Ntdsutil.exe utility to manually remove the NTDS
Settings object. The following steps list the procedure for removing the NTDS
Settings object in the Active Directory for a given domain controller. At each
NTDSUTIL menu, the administrator can type help for more information about the
available options.
CAUTION : The administrator should also check that replication has occurred
since the demotion before manually removing the NTDS Settings object for any
server. Using the NTDSUTIL utility improperly can result in partial or complete
loss of Active Directory functionality.
1. Click Start , point to Programs , point to Accessories , and then click Command
Prompt .
2. At the command prompt, type ntdsutil .
3. Type metadata cleanup , and then press ENTER. Based on the options given, the
administrator can perform the removal, but additional configuration parameters
need to be specified before the removal can occur.
4. Type connections and press ENTER. This menu is used to connect to the specific
server on which the changes occur. If the currently logged on user does not have
administrative permissions, alternate credentials can be supplied by specifying the
credentials to use before making the connection. To do so, type set creds domain
name username password and press ENTER. For a null password, type null for
the password parameter.
5. Type connect to server servername , and then press ENTER. You should receive
confirmation that the connection is successfully established. If an error occurs,
verify that the domain controller being used in the connection is available and the
credentials you supplied have administrative permissions on the server.
NOTE : If you attempt to connect to the same server that you want to delete,
when you attempt to delete the server referred to in step 15, you may receive the
following error message:
Error 2094. The DSA Object cannot be deleted0x2094
6. Type quit and press ENTER. The Metadata Cleanup menu is displayed.
7. Type select operation target and press ENTER.
8. Type list domains and press ENTER. A list of domains in the forest is displayed,
each with an associated number.
9. Type select domain number and press ENTER, where number is the number
associated with the domain to which the server you are removing is a member.
The domain you select is used to determine if the server being removed is the last
domain controller of that domain.
10. Type list sites and press ENTER. A list of sites, each with an associated number,
is displayed.
11. Type select site number and press ENTER, where number is the number
associated with the site to which the server you are removing is a member. You
should receive a confirmation listing the site and domain you chose.
12. Type list servers in site and press ENTER. A list of servers in the site, each with
an associated number, is displayed.
13. Type select server number , where number is the number associated with the
server you want to remove. You receive a confirmation listing the selected server,
its Domain Name Server (DNS) host name, and the location of the server's
computer account you want to remove.
14. Type quit and press ENTER. The Metadata Cleanup menu is displayed.
15. Type remove selected server and press ENTER. You should receive
confirmation that the removal completed successfully. If you receive the
following error message:
Error 8419 (0x20E3)
The DSA object could not be found
the NTDS Settings object may already be removed from the Active Directory as
the result of another administrator removing the NTDS Settings object, or
replication of the successful removal of the object after running the DCPROMO
utility.
NOTE : You may also see this error when you attempt to bind to the domain
controller that is going to be removed. Ntdsutil needs to bind to a domain
controller other than the one that is going to be removed with metadata cleanup.
16. Type quit at each menu to quit the NTDSUTIL utility. You should receive
confirmation that the connection disconnected successfully.
17. Remove the cname record in the _msdcs. root domain of forest zone in DNS.
Assuming that DC is going to be reinstalled and re-promoted, a new NTDS
settings object is created with a new globally unique identifier (GUID) and a
matching cname record in DNS. You do not want the DC's that exist to use the
old cname record.
As best practice you should delete the hostname and other DNS records. If the
lease time that remains on Dynamic Host Configuration Protocol (DHCP) address
assigned to offline server is exceeded then another client can obtain the IP address
of the problem DC.
Now that the NTDS setting object has been deleted we can now delete the following
objects:
1. Use ADSIEdit to delete the computer account in the OU=Domain
Controllers,DC=domain...
NOTE : The FRS subscriber object is deleted when the computer object is
deleted, since it is a child of the computer account.
2. Use ADSIEdit to delete the FRS member object in CN=Domain System Volume
(SYSVOL share),CN=file replication service,CN=system....
3. In the DNS console, use the DNS MMC to delete the cname (also known as the
Alias) record in the _msdcs container.
4. In the DNS console, use the DNS MMC to delete the A (also known as the Host)
record in DNS.
5. If the deleted computer was the last domain controller in a child domain and the
child domain was also deleted, use ADSIEdit to delete the trustDomain object for
the child in CN=System, DC=domain, DC=domain, Domain NC.
Subscribe to:
Posts (Atom)