5.1 Security Considerations for Implementers

This protocol generates group keys from root keys stored in Active Directory, and distributes them on the basis of authentication to an Active Directory domain. Therefore, security of this protocol depends critically on the security of the Active Directory infrastructure. In particular, the protocol is not secure against an attacker who obtains administrative privileges on an Active Directory DC, or who gains access to the Active Directory database in some other way. Therefore, it is important that Active Directory domain administrators are trusted, and that access to this protocol's root key objects be restricted to these trusted administrators.

Also, since root keys are used to generate group keys for all security descriptors, it is very important to ensure the cryptographic strength of these keys. Accordingly, root keys have to be generated only with a cryptographically strong random number generator, and new root keys should be created periodically to limit the impact of root key compromise.

Client implementations need to restrict access to the client's group key cache. Moreover, an implementation needs to ensure that a group key corresponding to a given security descriptor cannot be read or modified by a user who would not normally be able to obtain that key. If the group key cache is stored on disk, it is strongly recommended that it be stored in encrypted form.

Guidance on building strong cryptographic subsystems is available in [FIPS140]. An overview of the Windows security architecture is available in [MS-WPO] section 9.

Any implementation of a protocol exposes code to inputs from attackers. It is strongly advised for such code to be developed according to secure coding and development practices to avoid buffer overflows, denial-of-service attacks, escalation of privilege, and disclosure of information. For more information about these concepts, secure development best practices, and common errors, see [HOWARD].