Существует ли влияние производительности прямого AD универсального присвоения групп?

Вот заявление Microsoft относительно универсальных групп. Часть, выделенная жирным шрифтом, особенно относится к вам:

Универсальные группы можно использовать в любом месте одной Windows лес. Они доступны только на предприятии, работающем в основном режиме. Универсальный группам может быть проще для некоторых администраторов, потому что там внутренних ограничений на их использование нет. Пользователи могут быть напрямую назначены в универсальные группы, они могут быть вложенными, и их можно использовать напрямую со списками контроля доступа для обозначения прав доступа в любом домен на предприятии.

Универсальные группы хранятся в глобальном каталоге (GC); это означает что все изменения, внесенные в эти группы, вызывают репликацию для всех серверы глобального каталога во всем предприятии. Изменения на универсальный поэтому группы должны создаваться только после тщательного изучения преимущества универсальных групп по сравнению со стоимостью повышенных нагрузка репликации глобального каталога. Если в организации есть только один, хорошо подключенная локальная сеть, не должно быть снижения производительности, в то время как широко рассредоточенные сайты могут испытывать значительное влияние. Как правило, организации, использующие глобальные сети, должны использовать только универсальные группы. for relatively static groups in which memberships change rarely.

The performance impact should be rather minimal in a well-connected environment where everyone has access to global catalogs.

The performance impact will be increased time to log in and increased time to evaluate ACLs on resources if a global catalog cannot be reached, or if your Sites & Subnets are misconfigured so that you find yourself communicating with global catalog servers outside of your own site. Also, there will be increased global catalog replication load.

However, I'm obliged to once again inform you that what you're doing is against commonly-accepted best practices.

This part of what you said: "... and my tool will watch for the right security by itself." That also scares me.

So I'm on the side of your IT consultants and I think they are doing their jobs by trying to persuade you to follow commonly-accepted best practices in terms of AD design.

But there's the answer to your question regardless.

Going way back, one potential performance scenario was the group membership replication used to be much worse prior to Windows Server 2003, and can still perform poorly with old groups with legacy members created before Windows Server 2003.

Prior to Windows Server 2003, anytime a Global/Universal group membership was changed, the entire group member attribute was replicated. This had serious replication performance implications in large, distributed directories, particularly with Universal groups with many members. Therefore, in large, multi-domain directories, it was common practice to have Global security groups in each domain added to a Universal group. This had the effect of partitioning the membership replication to within the domain itself.

Windows Server 2003 introduced Linked Value Replication (LVR). That fixed a lot of those issues for newly-created groups, and groups whose legacy members were converted, because only the individual "linked values" (members) are replicated when a change (add/remove member) occurs.

Another potential issue was the total number of members. If you have more users that you have, say 50,000, and 40,000 need to be in a security group, it was common practice to limit the number of members per group to less than 5,000, due to that is the maximum number of items that can be safely committed in a single, atomic, Active Directory transaction. However, with an LVR group, updates to a group with large memberships no longer require sending the entire membership, so that typically is no longer an issue, as long as you don't yourself perform that many updates (adds/removes) in a single transaction.

That being said, it is still a good practice for large groups in multi-domain forests to have domain-specific security groups that are added as members to a single Universal security group, which resides typically in a resource domain. Whether you use that Universal group to ACL a resource, or add the Universal Group to a Domain Local group is up to you. In practice, I haven't seen that many issues with using Universal Groups, performance or otherwise. Note that access to a Global Catalog should rarely be an issue, as Microsoft has long recommended that all domain controllers be Global Catalogs. It's not uncommon to find large directories created before Domain Local groups were around that haven't converted any of their groups or their strategy to use Domain Local groups.

Some reasons Domain Local groups are recommended by Microsoft because they provide the greatest flexibility in the types of members that can be added to the group, and level of discretionary control for the Domain Admins. It also provides a means to minimize group membership replication:

Global catalog replication
http://technet.microsoft.com/en-us/library/cc759007%28v=ws.10%29.aspx

"Groups with universal scope, and their members, are listed exclusively in the global catalog. Groups with global or domain local scope are also listed in the global catalog, but their members are not. This reduces the size of the global catalog and the replication traffic associated with keeping the global catalog up to date. You can improve network performance by using groups with global or domain local scope for directory objects that will change frequently."

You should also never use Domain Local groups to ACL objects in Active Directory:

"When a user connects to a global catalog and tries to access an object, an access check is performed based on the user's token and the object's DACL. Any permissions specified in the object's DACL for domain local groups that are not from the domain that the domain controller hosting the global catalog (to which the user has connected) belongs to, will be ineffective because only domain local groups from the global catalog's domain of which the user is a member are represented in the user's access token. As a result, a user may be denied access when access should have been granted, or allowed access when access should have been denied.

"As a best practice, you should avoid using domain local groups when assigning permissions on Active Directory objects, or be aware of the implications if you do use them."