Sugerir tradução
 
Outras sugestões:

progress indicator
Sem sugestões.
TechNet Magazine > Home > Todas as edições > 2009 > TechNet Magazine Setembro 2009 >  Active Directory: AdminSDHolder, grupos protegi...
Exibir Conteúdo: Lado a LadoExibir Conteúdo: Lado a Lado
Este é um conteúdo traduzido por máquina que os membros da comunidade podem editar. Incentivamos você a melhorar a tradução clicando no link Editar associado a qualquer sentença abaixo.
Active Directory
AdminSDHolder, Protected Groups and SDPROP
John Policelli
 
At a Glance:
  • Overview of AdminSDHolder, protected groups and SDPROP
  • Controlling groups that are protected by AdminSDHolder
  • Security Descriptor propagator

Active Directory Domain Services uses AdminSDHolder, protected groups and Security Descriptor propagator (SD propagator or SDPROP for short) to secure privileged users and groups from unintentional modification. This functionality was introduced in the inaugural release of Active Directory in Windows 2000 Server and it's fairly well known. However, virtually all IT administrators have been negatively impacted by this functionality, and that will to continue unless they fully understand how AdminSDHolder, protected groups and SDPROP work.
Each Active Directory domain has an object called AdminSDHolder, which resides in the System container of the domain. The AdminSDHolder object has a unique Access Control List (ACL), which is used to control the permissions of security principals that are members of built-in privileged Active Directory groups (what I like to call "protected" groups). Every hour, a background process called SDPROP runs on the domain controller that holds the PDC Emulator operations master role. It compares the ACL on all security principals (users, groups and computer accounts) that belong to protected groups against the ACL on the AdminSDHolder object. If the ACL lists aren't the same, the ACL on the security principal is overwritten with the ACL from the Admin–SDHolder object. In addition, inheritance is disabled on the security principal.
As you can see, multiple layers of security are incorporated into this functionality. First, the permissions applied to users belonging to protected groups are more stringent than the default permissions applied onto other user accounts. Next, this functionality disables inheritance on these privileged accounts, ensuring that permissions applied at the parent level aren't inherited by the protected objects, regardless of where they reside. Finally, the SDPROP process running every 60 minutes identifies manual modifications to an ACL and reverses them so that the ACL matches the ACL on the AdminSDHolder object.
See the sidebar "A Common Example of the Impact of AdminSDHolder, Protected Groups, and SDPROP" for a real-world look at this functionality.

The AdminSDHolder Object
As mentioned, each Active Directory domain contains an AdminSDHolder object that resides in the domain's System partition. The distinguished name of the AdminSDHolder object is "CN=AdminSDHolder,CN=System,DC=domain,DC=com," where DC=domain,DC=com is the distinguished name of the domain. Figure 1 shows the AdminSDHolder object in a Windows Server 2008 R2 domain.
Figure 1 AdminSDHolder Object (Click the image for a larger view)

Default ACL
Because the AdminSDHolder object is used in the process to secure privileged accounts, the default ACL on the AdminSDHolder object is more stringent than the ACL on other objects, such as the domain, OUs and containers.
In the default ACL for AdminSDHolder, the default Owner is the Domain Admins group, which is fairly unusual. Most Active Directory objects have the Administrators group as the default Owner. That's significant because an Owner can take control of an object and reset permissions.
Another important design factor for the AdminSDHolder object is that inheritance is disabled, which ensures that no parent-level permissions are inherited.
Finally, the Administrators, Domain Admins and Enterprise Admins groups are the groups that have the write permission to attributes on AdminSDHolder, which is more stringent than the default permissions applied to other Active Directory objects.

Protected Groups
As previously noted, AdminSDHolder permissions apply to security principals that belong to protected groups. The list of protected groups has expanded since the inaugural release of Active Directory in Windows 2000 Server. Figure 2 shows the default protected groups and users from Windows 2000 Server to Windows Server 2008 R2.
Figure 2 Default Protected Groups
Windows 2000 Server RTM
Windows 2000 Server with SP1
Windows 2000 Server with SP2
Windows 2000 Server with SP3
Windows 2000 Server with SP4
Windows Server 2003 RTM
Windows Server 2003 with SP1
Windows Server 2003 with SP2
Windows Server 2008 RTM
Windows Server 2008 R2
Administrators Account Operators Account Operators Account Operators
Domain Admins Administrator Administrator Administrator
Enterprise Admins Administrators Administrators Administrators
Schema Admins Backup Operators Backup Operators Backup Operators
  Cert Publishers Domain Admins Domain Admins
  Domain Admins Domain Controllers Domain Controllers
  Domain Controllers Enterprise Admins Enterprise Admins
  Enterprise Admins Krbtgt Krbtgt
  Krbtgt Print Operators Print Operators
  Print Operators Replicator Read-only Domain Controllers
  Replicator Schema Admins Replicator
  Schema Admins Server Operators Schema Admins
  Server Operators   Server Operators
A Common Example of the Impact of AdminSDHolder, Protected Groups and SDPROP
Most Active Directory administrators become aware of AdminSDHolder, protected groups and SDPROP through a scenario like this one:
You delegate permissions on an Organizational Unit (OU). You're later informed that the permissions are in place for most—but not all—user accounts in the OU. You determine that the ACL on the affected accounts is different from what you delegated and that inheritance is not enabled, so you enable inheritance to resolve the issue. Initially, this seems to work, but later the issue resurfaces. You again determine that the ACL is different and inheritance has been disabled.
I've seen individuals go through this seeming endless cycle over and over.
This situation actually occurs by design, however. It's caused by AdminSDHolder, protected groups and SDPROP.
The accounts affected by this issue belong to a protected group. As a result, the ACL on these accounts is inherited from the AdminSDHolder object in the domain, and inheritance is disabled. That's why the permissions that you delegated aren't applied to the affected user accounts. When you manually enable inheritance on these accounts, the delegated permissions are added to the ACL.
However, when the SDPROP process runs on the domain controller that holds the PDC Emulator operations master role—by default, every 60 minutes—the ACL is overwritten to match the ACL on the AdminSDHolder object and inheritance is disabled.
The list of protected groups consisted of four security groups in Windows 2000 Server RTM. In Windows 2000 Server SP4 and Windows Server 2003, several other groups were added, including the Administrator and Krbtgt accounts. In Windows Server 2003 with SP1 and later versions, Microsoft removed the Cert Publishers group from the default protected groups. In Windows Server 2008, Microsoft expanded this list to include the Read-Only Domain Controllers group. The list of protected groups hasn't changed in the Release Candidate build of Windows Server 2008 R2.

Controlling Groups that are Protected by AdminSDHolder
In my experience, a subset of these default protected groups causes problems with AdminSDHolder. For example, many organizations use the Print Operators group for Print Services management but not for Active Directory management. However, the Print Operators group is a protected group because it has elevated permissions on domain controllers by default. A best practice is to remove the elevated permissions that this group has on domain controllers. If you do follow this best practice (and you should!), you probably won't need to protect this group with AdminSDHolder.
You can exclude a subset of the default protect groups from the AdminSDHolder process, including:
  • Account Operators
  • Server Operators
  • Print Operators
  • Backup Operators
This ability to control groups that are protected by AdminSDHolder was introduced via hotfix for the RTM versions of Windows 2000 Server and Windows Server 2003 and is included in the most recent service pack for Windows Server 2003 and in the RTM versions of Windows Server 2008 and Windows Server 2008 R2. For more information on the hotfix, go to Delegated permissions are not available and inheritance is automatically disabled.
The ability to control groups protected by AdminSDHolder is enabled by modifying the dsHeuristic flag. This is a Unicode string in which each character contains a value for a single domain-wide setting. Character position 16 is interpreted as a hexadecimal value, where the left-most character is position 1. Therefore, the only valid values are "0" through "f". Each operator group has a specific bit, as shown in Figure 3.
Figure 3 dsHeuristic Operator Bits
Bit Group to Exclude Binary Value Hexadecimal Value
0 Account Operators 0001 1
1 Server Operators 0010 2
2 Print Operators 0100 4
3 Backup Operators 1000 8
This situation becomes even more complicated when you're trying to exclude more than one group from AdminSDHolder, especially because you can have multiple combinations of exclusions—for example, Account Operators and Server Operators, or Account Operators and Backup Operators. To deal with this issue, simply add the binary value of each group and then convert the result to a hexadecimal value. For example, to exclude the Print Operators and Backup Operators groups, take the binary value for the Print Operators group (0100) and add it to the binary value of the Backup Operators group (1000), which equals 1100. You then convert the binary sum (1100) to the hexadecimal value (C).
To make this task a little easier, Figure 4 lists all possible combinations in binary and hexadecimal format.
Figure 4 dsHeuristic Values for Excluding Combinations of Groups
Group(s) to Exclude Binary Value Hexadecimal Value
None (Default) 0 0
Account Operators 1 1
Server Operators 10 2
Account Operators
Server Operators
0001 + 0010 = 0011 3
Print Operators 100 4
Account Operators
Print Operators
0001 + 0100 = 0101 5
Server Operators
Print Operators
0010 + 0100 = 0110 6
Account Operators
Server Operators
Print Operators
0001 + 0010 + 0100 = 0111 7
Backup Operators 1000 8
Account Operators
Backup Operators
0001 + 1000 = 1001 9
Server Operators
Backup Operators
0010 + 1000 = 1010 A
Account Operators Server Operators
Backup Operators
0001 + 0010 + 1000 = 1011 B
Print Operators
Backup Operators
0100 + 1000 = 1100 C
Account Operators
Print Operators
Backup Operators
0001 + 0100 + 1000 = 1101 D
Server Operators
Print Operators
Backup Operators
0010 + 0100 + 1000 = 1110 E
Account Operators
Server Operators
Print Operators Backup Operators
0001 + 0010 + 0100 + 1000 = 1111 F
After deciding which group(s) you want to exclude, you're ready to modify the dsHeuristics attribute. For details on that process, see the sidebar "How to Use the dsHeuristics Attribute to Exclude Groups from AdminSDHolder."

Determining Whether a Security Principal Is Protected by AdminSDHolder
A fairly large number of default users and groups are protected by AdminSDHolder. One thing to keep in mind is that users are protected by AdminSDHolder if they have direct or transitive membership in a security or distribution group. Distribution groups are included because a distribution group can be converted to a security group.
Let's say a user belongs to a distribution list called Canada IT. The Canada IT DL is a member of the North American IT security group; the North American IT security group is a member of the Administrators group. Because the user's transitive group membership includes the Administrators group (by virtue of group nesting), the user's account is protected by AdminSDHolder.
There's an easy way to determine which users and groups AdminSDHolder protects in your domain. You can query the adminCount attribute to determine whether an object is protected by the AdminSDHolder object. The following examples use the ADFind.exe tool, which can be downloaded from joeware. net.
  • To find all objects in a domain that are protected by AdminSDHolder, type:
Adfind.exe -b DC=domain,DC=com -f "adminCount=1" DN
  • To find all user objects in a domain that are protected by AdminSDHolder, type:
Adfind.exe -b DC=domain,DC=com -f "(&(objectcategory=person)(objectclass=user)(admincount=1))" DN
  • To find all groups in a domain that are protected by AdminSDHolder, type:
Adfind.exe -b DC=domain,DC=com -f "(&(objectclass=group)(admincount=1))" DN
Note: In the preceding examples, replace DC=domain,DC=com with the distinguished name of your domain.

Orphaned AdminSDHolder Objects
When a user is removed from a protected group, the adminCount attribute on that user account is changed to 0. However, inheritance isn't re-enabled on the user account. As a result, the user account no longer receives its ACL from the AdminSDHolder object, but it also doesn't inherit any permissions from parent objects. The common term for this issue is "orphaned AdminSDHolder objects." There is no automated mechanism to fix inheritance on objects that no longer belong to protected groups; you must deal with orphaned AdminSDHolder objects manually. Microsoft has developed and made available a VB Script that will assist you in re-enabling inheritance on user accounts that were previously members of protected groups. To find the VB Script, go to Delegated permissions are not available and inheritance is automatically disabled.

Security Descriptor Propagator
SDPROP is a background process that runs on the domain controller that holds the PDC Emulator operations master role. By default, SDPROP runs every 60 minutes. SDPROP is designed to compare the ACL on users and groups that are members of protected groups. If the ACL is the same, SDPROP doesn't touch the ACL. However, if the ACL is different, it's overwritten with the ACL from the AdminSDHolder object.

Modifying How Often SDPROP Runs
If the default frequency of 60 minutes for SDPROP to run isn't sufficient, you can change it by creating or modifying the AdminSDProtectFrequency entry in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters subkey.
If this key doesn't exist, the default frequency (60 minutes) is used.
You can configure the frequency to anywhere between one minute and two hours. You must enter the number of seconds when creating or modifying the registry entry. The following command will configure SDPROP to run every 10 minutes (600 seconds):
REG ADD HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /V AdminSDProtectFrequency /T REG_DWORD /F /D 600
Note, however, that modifying this subkey isn't recommended because doing so can increase LSA (Local Security Authority) processing overhead.

Forcing SDPROP to Run
You can also force SDPROP to run in cases where you're testing changes or you can't wait for the configured interval. Forcing SDPROP to run involves manually initializing the SDPROP thread to evaluate inherited permissions for objects in Active Directory. This process can be achieved by taking the following steps on the domain controller that holds the PDC Emulator operations master role:
  1. Go to Start. Click Run. Type LDP.exe. Click OK.
  2. On the Connection menu in the LDP console, click Connect.
  3. In the Connect dialog box, type the server name you want to connect to in the Server field and ensure that 389 is listed in the Port field. Click OK.
  4. On the Connection menu, click Bind.
  5. In the Bind window, select the Bind as the currently logged-on user option, or select the Bind with Credentials option. If you selected the latter, enter the credentials that you want to bind with. Click OK.
  6. On the Browse menu, select Modify.
  7. In the Modify dialog box, leave the DN field empty. Type FixUpInheritance into the Attribute field. Type Yes into the Value field. Select the Add operation, then click Enter. Figure 5 shows how the Modify window should look.
  8. In the Modify dialog box, click Run. The Details pane will be similar to the highlighted text in Figure 6.
Figure 5 The Modify Window. When Forcing SDPROP to run in the Modify dialog box, click Run. The Details pane will be similar to the highlighted text in Figure 6. (Click the image for a larger view)
Figure 6 Call Modify Operation in LDP.exe. (Click the image for a larger view)
At this point, SDPROP should initialize. The amount of time the SDPROP process takes depends on the size of your Active Directory environment. The larger the environment, the longer it will take the process to run. You can monitor the DS Security Propagation Events counter in the NTDS Performance object to determine when SDPROP has completed, which will be indicated by a counter value of 0.

Wrapping Up
The AdminSDHolder is an important security feature in Active Directory. The AdminSDHolder, protected groups and Security Descriptor propagator help secure user accounts that contain elevated Active Directory permissions. The AdminSDHolder functionality has evolved from Windows 2000 Server to Windows Server 2008. During this evolution, Microsoft has expanded the number of objects that are secured by AdminSDHolder, introduced the ability to exclude certain groups from the Admin–SDHolder and added the ability to control how often SDPROP runs.
Most Active Directory administrators have been introduced to AdminSDHolder, intentionally or unintentionally. I've tried to provide you with a good understanding of what AdminSDHolder is, how it works and what cleanup is required when you remove a user from a protected group, along with some useful tweaks. I hope that this information will help prevent you from being caught off guard by the AdminSDHolder functionality the next time you delegate or remove Active Directory permissions.
How to Use the dsHeuristics Attribute to Exclude Groups from AdminSDHolder
The dsHeuristics attribute can be used to exclude certain groups from being protected by AdminSDHolder. The following instructions outline the steps for modifying the dsHeuristics attribute on Windows Server 2008 R2:
  1. Log on to a domain controller or a member computer that has the Remote Server Administrator Tools (RSAT) installed.
  2. Go to Start. Click Run. Type adsiedit.msc, then click OK.
  3. In the ADSI Edit console, right-click on ADSI Edit in the console tree. Select Connect To.
  4. In the Connection Settings window, select Configuration from the Select a Well-Known Naming Context drop-down. Click OK.
  5. In the console tree, expand Configuration, expand Service, and expand Windows NT. Right-click on the Directory Service node, then select Properties.
  6. In the CN=Directory Service Properties window, select dsHeuristics. Click Edit.
  7. In the String Attribute Editor window, copy the existing value for dsHeuristics if it is set.
  8. In the String Attribute Editor window, replace the dsHeuristics value with what you want to set, such as 000000000100000f to exclude Account Operators, Server Operators, Print Operators, and Backup Operators groups. Figure A shows the String Attribute Editor window.

    Note: Replace the zeros in the first part of the value with what you may already have in dsHeuristics. Make sure that you have the correct count of digits up to the "f" or whatever bits you want to set.
  9. Click OK on the String Attribute Editor window. Click OK on the CN=Directory Service Properties window.
Figure A String Attribute Editor Window(Click the image for a larger view)

John Policelli, Microsoft MVP for Directory Services, MCTS, MCSA, ITSM, iNet+, Network+ and A+, is a solutions-focused IT consultant with more than a decade of combined success in architecture, security, strategic planning and disaster-recovery planning. For the past nine years, he has focused on identity and access management and providing thought leadership for some of Canada's largest installations of Active Directory. Policelli is the author of Active Directory Domain Services 2008 How-To (Sams Publishing, 2009).

Active Directory
AdminSDHolder, grupos protegidos e SDPROP
John Policelli
 
Visão geral:
  • Visão geral de AdminSDHolder, grupos protegidos e SDPROP
  • Controlando grupos que são protegidos por AdminSDHolder
  • Propagador de descritor de segurança

Serviços de domínio diretório ativo usam AdminSDHolder, grupos protegidos e o descritor de segurança propagador (SD propagador ou SDPROP de forma abreviada) para usuários com privilégios seguros e grupos de modificação não intencional. Essa funcionalidade foi introduzida na versão nova do Active Directory no Windows 2000 Server e é bastante conhecida. No entanto, praticamente todos os administradores de TI têm sido negativamente impactados por essa funcionalidade, e que irá para continuar a menos que compreendam totalmente como AdminSDHolder, grupos protegidos e SDPROP funcionam.
Cada domínio do Active Directory tem um objeto chamado AdminSDHolder, que reside no recipiente System do domínio. O objeto AdminSDHolder tem um exclusivo acesso controle List (ACL), que é usado para controlar as permissões de objetos de segurança que são membros de internos grupos do Active Directory com privilégios (o que gosto de chamar "protegido"grupos). Cada hora, um processo de plano de fundo chamado SDPROP é executado em controlador de domínio que tem a função de mestre de operações do emulador PDC. Ele compara a ACL em todos os objetos de segurança (usuários, grupos e contas de computador) que pertencem a grupos protegidos contra a ACL no objeto AdminSDHolder. Se as listas ACL não são iguais, a ACL no objeto de segurança será substituída com a ACL do objeto Admin–SDHolder. Além disso, a herança é desabilitada na entidade de segurança.
Como você pode ver, várias camadas de segurança são incorporadas a essa funcionalidade. Primeiro, as permissões aplicadas a usuários pertencentes a grupos protegidos são mais rigorosas que as permissões padrão aplicadas para outras contas de usuário. Em seguida, essa funcionalidade desativa herança essas contas privilegiadas, garantindo que as permissões aplicadas no nível do pai não são herdadas por objetos protegidos, independentemente de onde residem. Finalmente, o processo SDPROP em execução a cada 60 minutos identifica modificações manuais para uma ACL e inverte-los para que a ACL coincide com a ACL no objeto AdminSDHolder.
Consulte a barra lateral "Um exemplo comum de impacto de AdminSDHolder, grupos de protegido e SDPROP"para uma visão de mundo real dessa funcionalidade.

O objeto AdminSDHolder
Como mencionado, cada domínio do Active Directory contém um objeto AdminSDHolder que reside na partição do sistema do domínio. O nome distinto do objeto AdminSDHolder é "CN = AdminSDHolder, CN = System, DC = domain, DC = com"onde DC = domain, DC = com é o nome distinto do domínio. A Figura 1 mostra o objeto AdminSDHolder em um domínio do Windows Server 2008 R2.
Figura 1 Objeto AdminSDHolder (clique na imagem para ampliá-la)

ACL padrão
Como o objeto AdminSDHolder é usado no processo para proteger contas privilegiadas, a ACL padrão no objeto AdminSDHolder é mais rigorosa que a ACL em outros objetos, como o domínio, unidades organizacionais e recipientes.
Na ACL para AdminSDHolder padrão, o padrão proprietário é o grupo Domain Admins, que é bastante incomum. A maioria dos objetos do Active Directory têm o grupo Administradores como o proprietário padrão. Isso é significativo porque um proprietário pode assumir o controle de um objeto e redefina as permissões.
Outro fator importante de design para o objeto AdminSDHolder está que herança é desabilitada, o que garante que nenhum permissões de nível pai são herdadas.
Finalmente, os grupos Administradores, administradores de domínio e administração de empresa são grupos que possuem a permissão de gravação de atributos em AdminSDHolder, que é mais rigorosa que as permissões padrão aplicadas a outros objetos do Active Directory.

Grupos protegidos
Como observado anteriormente, permissões AdminSDHolder se aplicam a objetos de segurança que pertencem a grupos protegidos. A lista de grupos protegidos expandiu desde o lançamento inaugural do Active Directory no Windows 2000 Server. Figura 2 mostra que o padrão protegido grupos e usuários do Windows 2000 Server para Windows Server 2008 R2.
Figura 2 padrão protegido grupos
Windows 2000 Server RTM
Windows 2000 Server com SP1
Windows 2000 Server com SP2
Windows 2000 Server com SP3
Windows 2000 Server com SP4
Windows Server 2003 RTM
Windows Server 2003 com SP1
Windows Server 2003 com SP2
Windows Server 2008 RTM
Windows Server 2008 R2
Administradores Operadores de conta Operadores de conta Operadores de conta
Admins. do Domínio Administrador Administrador Administrador
Administração de Empresa Administradores Administradores Administradores
Administradores de esquema Operadores de backup Operadores de backup Operadores de backup
  Editores de certificados Admins. do Domínio Admins. do Domínio
  Admins. do Domínio Controladores de domínio Controladores de domínio
  Controladores de domínio Administração de Empresa Administração de Empresa
  Administração de Empresa KrbTGT KrbTGT
  KrbTGT Operadores de impressão Operadores de impressão
  Operadores de impressão Replicator Controladores de domínio somente leitura
  Replicator Administradores de esquema Replicator
  Administradores de esquema Operadores de Servidor Administradores de esquema
  Operadores de Servidor   Operadores de Servidor
Um exemplo comum do impacto de AdminSDHolder, protegido SDPROP e grupos
Active Directory a maioria dos administradores ficam atento ao AdminSDHolder, protegido grupos e SDPROP por um cenário como este:
Delegar permissões em uma unidade organizacional (OU). Posteriormente você está informado de que as permissões são in-loco para a maioria — mas não todos — contas de usuário na OU. Você determina que a ACL em contas afetadas é diferente da que tenha delegado e que herança não está ativada, para que você ativar a herança resolver o problema. Inicialmente, isso parece funcionar, mas posteriormente resurfaces o problema. Novamente, você determinar que a ACL é diferente e herança tiver sido desativada.
Já vi indivíduos passar por esse ciclo infinito aparente repetidamente.
Essa situação realmente ocorre por design, no entanto. Isso é causado por AdminSDHolder, grupos protegidos e SDPROP.
As contas afetadas por esse problema pertencem a um grupo protegido. Como resultado, a ACL nessas contas é herdada do objeto AdminSDHolder no domínio, e herança está desabilitada. É por isso que as permissões que tenha delegado não são aplicadas a contas de usuário afetado. Quando você habilitar manualmente herança essas contas, as permissões delegadas são adicionadas à ACL.
No entanto, quando o processo de SDPROP é executado em controlador de domínio que tem a função de mestre de operações do emulador PDC — por padrão, a cada 60 minutos — a ACL é substituída para coincidir com a ACL no objeto AdminSDHolder e herança é desabilitada.
A lista de grupos protegidos consistiu em quatro grupos de segurança no Windows 2000 Server RTM. No Windows 2000 Server SP4 e Windows Server 2003, foram adicionados vários outros grupos, incluindo as contas Administrador e KRBTGT. No Windows Server 2003 com SP1 e versões posteriores, Microsoft removido o grupo Editores de certificados os grupos padrão protegido. No Windows Server 2008, Microsoft expandida desta lista para incluir o grupo controladores de domínio somente leitura. A lista de grupos protegidos não foi alterada na compilação de versão RC do Windows Server 2008 R2.

Controlando grupos que são protegidos por AdminSDHolder
Na minha experiência, um subconjunto desses padrão protegido grupos causas problemas AdminSDHolder. Por exemplo, muitas organizações usam o grupo Operadores de impressão para gerenciamento de serviços de impressão, mas não para gerenciamento do Active Directory. No entanto, o grupo de operadores de impressão é um grupo protegido porque ele tenha permissões elevadas em controladores de domínio por padrão. Uma prática recomendada é remover as permissões elevadas que esse grupo tem em controladores de domínio. Se você fazer execute essa prática recomendada (e você deve!), você provavelmente não precisa proteger esse grupo com AdminSDHolder.
Você pode excluir um subconjunto do padrão proteger grupos do processo de AdminSDHolder, incluindo:
  • Operadores de conta
  • Operadores de Servidor
  • Operadores de impressão
  • Operadores de backup
Essa capacidade de grupos de controle são protegidas por AdminSDHolder foi introduzida por meio de hotfix para as versões RTM do Windows 2000 Server e Windows Server 2003 e está incluída no service pack mais recente para o Windows Server 2003 e nas versões RTM do Windows Server 2008 e Windows Server 2008 R2. Para obter mais informações sobre o hotfix, vá para delegado permissões não estão disponíveis e a herança é automaticamente desativado.
A capacidade de grupos de controle protegidas por AdminSDHolder é ativada por modificar o sinalizador dsHeuristic. Essa é uma seqüência de caracteres Unicode em que cada caractere contém um valor para uma única configuração de todo o domínio. Posição do caractere 16 é interpretada como um valor hexadecimal, onde o caractere mais à esquerda é a posição 1. Portanto, os valores somente válidos são "0"por meio de "f". Cada grupo operador tem um pouco específico, como mostrado no Figura 3.
Figura 3 dsHeuristic bits de operador
Bit Excluir grupo Valor binário Valor hexadecimal
0 Operadores de conta 0001 1
1 Operadores de Servidor 0010 2
2 Operadores de impressão 0100 4
3 Operadores de backup 1000 8
Essa situação se torna ainda mais complicada quando você está tentando excluir mais de um grupo de AdminSDHolder, especialmente porque você pode ter várias combinações de exclusões — por exemplo, operadores de conta e servidores, ou Account Operators e operadores. Para lidar com esse problema, simplesmente adicione o valor binário de cada grupo e converter o resultado em um valor hexadecimal. Por exemplo, para excluir os operadores de impressão e operadores grupos, têm o valor binário para os operadores de impressão (0100) de grupo e adicione-ao valor binário de Backup Operators agrupar (1000), que é igual a 1100. Em seguida, você converter a soma binária (1100) para o valor hexadecimal (C).
Para facilitar essa tarefa um pouco, Figura 4 lista todas as combinações possíveis em formato binário e hexadecimal.
Figura 4 dsHeuristic valores para exclusão combinações de grupos
Grupo (s) para excluir Valor binário Valor hexadecimal
Nenhum (padrão) 0 0
Operadores de conta 1 1
Operadores de Servidor 10 2
Operadores de conta
Operadores de Servidor
0001 + 0010 = 0011 3
Operadores de impressão 100 4
Operadores de conta
Operadores de impressão
0001 + 0100 = 0101 5
Operadores de Servidor
Operadores de impressão
0010 + 0100 = 0110 6
Operadores de conta
Operadores de Servidor
Operadores de impressão
0001 + 0010 + 0100 = 0111 7
Operadores de backup 1000 8
Operadores de conta
Operadores de backup
0001 + 1000 = 1001 9
Operadores de Servidor
Operadores de backup
0010 + 1000 = 1010 Um
Conta de operadores de servidores
Operadores de backup
0001 + 0010 + 1000 = 1011 B
Operadores de impressão
Operadores de backup
0100 + 1000 = 1100 C
Operadores de conta
Operadores de impressão
Operadores de backup
0001 + 0100 + 1000 = 1101 D
Operadores de Servidor
Operadores de impressão
Operadores de backup
0010 + 0100 + 1000 = 1110 E
Operadores de conta
Operadores de Servidor
Operadores de backup operadores de impressão
0001 + 0010 + 0100 + 1000 = 1111 F
Depois de decidir quais grupos você deseja excluir, você estará pronto para modificar o atributo dsHeuristics. Para obter detalhes sobre esse processo, consulte a barra lateral "Como usar o atributo dsHeuristics para excluir grupos de AdminSDHolder."

Determinar se uma entidade de segurança está protegida por AdminSDHolder
Um número relativamente grande de usuários padrão e grupos é protegido por AdminSDHolder. Uma coisa em mente é que os usuários são protegidos por AdminSDHolder se tiverem direta ou transitiva de participação em um grupo de segurança ou distribuição. Grupos de distribuição estão incluídos porque um grupo de distribuição pode ser convertido para um grupo de segurança.
Digamos que um usuário pertencer a uma lista de distribuição chamada IT Canadá. LISTAS de TI Canadá é membro do grupo de segurança de TI da América do Norte;o grupo de segurança de TI da América do Norte é um membro do grupo Administradores. Como o usuário é transitivo participação no grupo inclui o grupo Administradores (por devido aninhamento de grupo), a conta do usuário é protegida por AdminSDHolder.
Há uma maneira fácil de determinar quais usuários e grupos protege AdminSDHolder no domínio. Você pode consultar o atributo adminCount para determinar se um objeto é protegido pelo objeto AdminSDHolder. Os exemplos a seguir usam a ferramenta ADFind.exe, que pode ser baixada em joeware. NET.
  • Para localizar todos os objetos em um domínio que são protegidas por AdminSDHolder, digite:
Adfind.exe -b DC=domain,DC=com -f "adminCount=1" DN
  • Para localizar todos os objetos de usuário em um domínio que são protegidas por AdminSDHolder, digite:
Adfind.exe -b DC=domain,DC=com -f "(&(objectcategory=person)(objectclass=user)(admincount=1))" DN
  • Para localizar todos os grupos em um domínio que são protegidas por AdminSDHolder, digite:
Adfind.exe -b DC=domain,DC=com -f "(&(objectclass=group)(admincount=1))" DN
Observação: No exemplos anteriores, substitua DC = domain, DC = com o nome distinto do domínio.

Objetos de AdminSDHolder órfãos
Quando um usuário é removido de um grupo protegido, o atributo adminCount essa conta de usuário é alterado para 0. No entanto, herança não reabilitada na conta de usuário. Como resultado, a conta de usuário não recebe sua ACL do objeto AdminSDHolder, mas ele também não herda as permissões da objetos pai. O termo comum para esse problema é "órfãos AdminSDHolder objetos". Não há nenhum mecanismo automatizado para corrigir herança em objetos que não pertencem a grupos protegidos;devem lidar com objetos AdminSDHolder órfãos manualmente. A Microsoft tem desenvolvido e disponibilizado um script VB que ajudarão você na herança reabilitando em contas de usuário que eram anteriormente membros de grupos protegidos. Para localizar o script de VB, vá para delegado permissões não estão disponíveis e a herança é automaticamente desativado.

Propagador de descritor de segurança
SDPROP é um processo de plano de fundo que é executado no controlador de domínio que tem a função de mestre de operações do emulador PDC. Por padrão, SDPROP é executado a cada 60 minutos. SDPROP foi projetado para comparar a ACL em usuários e grupos que são membros de grupos protegidos. Se a ACL é a mesma, SDPROP não toque a ACL. No entanto, se a ACL é diferente, ele é substituído com a ACL do objeto AdminSDHolder.

Modificando como normalmente executa SDPROP
Se a freqüência padrão de 60 minutos para SDPROP executar não é suficiente, você pode alterá-lo criando ou modificando a entrada AdminSDProtectFrequency na subchave HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters.
Se essa chave não existir, a freqüência padrão (60 minutos) será usada.
Você pode configurar a freqüência para qualquer lugar entre um minuto e duas horas. Você deve digitar o número de segundos quando criar ou modificar a entrada do Registro. O comando a seguir irá configurar SDPROP para executar cada 10 minutos (600 segundos):
REG ADD HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /V AdminSDProtectFrequency /T REG_DWORD /F /D 600
No entanto, observe que modificar essa subchave não é recomendável porque isso pode aumentar LSA (autoridade de segurança local) sobrecarga de processamento.

Forçar SDPROP para executar
Você também pode forçar SDPROP executado em casos onde você está testando alterações ou você não é possível aguardar o intervalo configurado. Forçar SDPROP para executar envolve manualmente ao inicializar o thread SDPROP para avaliar as permissões herdadas para objetos no Active Directory. Esse processo pode ser alcançado levando as seguintes etapas no controlador de domínio que tem a função mestre de operações de emulador PDC:
  1. Vá para iniciar. Clique em executar. Digite LDP.exe. Clique em OK.
  2. No menu Connection no console do LDP, clique em conectar.
  3. Na caixa de diálogo Conectar, digite o nome do servidor que você deseja se conectar no campo do servidor e verifique se 389 está listado no campo porta. Clique em OK.
  4. No menu conexão, clique em BIND.
  5. Na janela BIND, selecione o vínculo como a opção do usuário conectado no momento ou selecione o vínculo com a opção de credenciais. Se você selecionou o segundo, insira as credenciais que você deseja vincular com. Clique em OK.
  6. No menu Browse, selecione modificar.
  7. Na caixa de diálogo Modificar, deixe o campo DN vazio. Digite FixUpInheritance no campo de atributo. Digite Sim no campo valor. Selecione a operação adicionar, clique em ENTER. Figura 5 mostra a janela modificar deve aparência.
  8. Na caixa de diálogo Modificar, clique em executar. O painel de detalhes será similar ao texto realçado em Figura 6.
Figura 5 A modificar a janela. Quando forçar SDPROP para executar na caixa de diálogo Modificar, clique em executar. O painel de detalhes será semelhante ao texto realçado na Figura 6. (Clique na imagem para uma visão ampliada)
Figura 6 chamada modificar operação em LDP.exe. (Clique na imagem para uma visão ampliada)
Neste ponto, SDPROP deve inicializar. A quantidade de processo SDPROP leva tempo depende do tamanho do ambiente do Active Directory. Quanto maior o ambiente, mais tempo levará o processo seja executado. Você pode monitorar o contador de eventos de propagação de segurança DS no objeto de desempenho NTDS para determinar quando SDPROP tiver sido concluído, que será indicado por um valor de contador de 0.

Resumo final
O AdminSDHolder é um recurso de segurança importante no Active Directory. Protegido por AdminSDHolder, grupos e descritor de segurança propagador ajuda seguro contas de usuário com permissões elevadas do Active Directory. A funcionalidade de AdminSDHolder evoluiu do Windows 2000 Server para o Windows Server 2008. Durante esta evolução, a Microsoft expandiu o número de objetos que são protegidas por AdminSDHolder, introduziu a capacidade de excluir determinados grupos do Admin–SDHolder e adicionados a capacidade de controlar a freqüência SDPROP é executado.
A maioria dos administradores do Active Directory foram introduzidos para AdminSDHolder, intencionalmente ou acidentalmente. Tentei fornecer-lhe uma boa compreensão do que é AdminSDHolder, como ele funciona e qual limpeza é necessária quando você remove um usuário de um grupo protegido, juntamente com alguns ajustes útil. Espero que essas informações ajudará a impedir que você que está sendo detectada desativar proteção pela funcionalidade AdminSDHolder a próxima vez que você delegar ou remover permissões do Active Directory.
Como usar o atributo dsHeuristics para excluir grupos de AdminSDHolder
O atributo dsHeuristics pode ser usado para excluir determinados grupos de protegido pelo AdminSDHolder. As instruções a seguir descrevem as etapas para modificar o atributo dsHeuristics no Windows Server 2008 R2:
  1. Efetuar logon em um controlador de domínio ou um computador membro que tenha as Remote Server administrador RSAT (Ferramentas) instalado.
  2. Vá para iniciar. Clique em executar. Digite adsiedit.msc, clique em OK.
  3. No ADSI Edit console, clique com o botão direito no ADSI Edit na árvore de console. Selecione conectar-se A.
  4. Na janela configurações de conexão, selecione configuração selecionar um contexto de nomeação conhecido drop-down. Clique em OK.
  5. Na árvore de console, expanda Configuration, expanda serviços e expanda Windows NT. Clique com o botão direito do mouse no nó serviço de diretório, e selecione Propriedades.
  6. No CN = janela de propriedades do serviço de diretório, selecione dsHeuristics. Clique em Editar.
  7. Na janela do Editor de atributo de seqüência, copie o valor existente para dsHeuristics se ele estiver definido.
  8. Na janela do Editor de atributo de seqüência, substitua o valor dsHeuristics o que você deseja definir, como 000000000100000f para excluir grupos Operadores de conta, operadores de servidor, operadores de impressão e operadores. A Figura A mostra a janela Editor de atributo de seqüência.

    Observação: Substitua os zeros na primeira parte do valor que você já pode ter no dsHeuristics. Verifique se você tem a contagem correta de dígitos até "f"ou qualquer bits que você deseja definir.
  9. Clique em OK na janela do Editor de atributo de seqüência. Clique em OK em CN = janela de propriedades do serviço de diretório.
Figura A String Attribute Editor janela(Click the image for a larger view)

John Policelli, MVP do Directory Services, MCTS, MCSA, ITSM, iNet +, Network + e A +, é consultor IT focados em soluções com mais de uma década de sucesso combinado em arquitetura, segurança, planejamento estratégico e planejamento de recuperação de desastres. Nos últimos nove anos, ele tem focalizado no gerenciamento de identidades e acesso e fornecendo planejado liderança para algumas instalações maiores do Canadá do Active Directory. Policelli é autor de Active Directory Domain Services 2008 instruções (Sams Publishing, 2009).

Page view tracker