We have a multi domain forest and we are trying to install the CA Access Control UNIX attributes Snap-in to try to manage the UNIX attributes in the domain. We are using a Domain Admin for one of the domains in the forest.
However, we see a lot of Failed IADs::SetInfo, Error = 0x80070005 in the logs and the snap-in seems not to install itself correctly. We also see that is seems to try to add UNIX attributes from the root of the forest, so using a user with Admin rights over the domain which we would like to manage seems not to be enough.
What are the minimal rights required in an Active Directory where there is a forest with multiple domains underneath ?
Domain Admins, or Enterprise Admins in Active Directory Domain Services (AD DS) can perform this procedure. The minimum equivalent permission required to complete this procedure is having the Modify Permission (read and write permissions) on the AD/Forest computer object(s).
The CA AccessControl UNIX attributes (Snap-in) utility adds security principal objects: users (user name, UID), computers, groups (group name, GID), login shell, home directory, etc.. of the Active Directory/entire Forest, to which you can grant or deny access to network resources.
However, bear in mind that there is no real need to install it in AD Windows versions equal or later than 2k8 R2 – since then the AD schema already has the relevant UNIX attributes and they can be populated with e.g. ADSIEdit. However, our MMC plug-in serves actually another purpose, namely, it allows one to conveniently manage Unix attributes directly in ADUC.
If the Windows admin prefers to use a different tool to manage user accounts, then installing that plug-in is not necessary at all. Also, the plug-in can be installed on just one machine and then all users’ Unix attributes can be managed from there.
Windows uses a pretty sophisticated and fine-grained access control for what one can do in AD. If the above recommendations regarding rights do not help, then you may be having a user error, which may likely be caused by some customizations of AD or incorrect usage (from Microsoft’s point of view on what one should be allowed), and we would have to investigate further