They had a single forest with 6 child domains, some of the domains dated back to 2000 and so the “Cert Publisher’s” group was defined as a Global Group.
We need to add the computer account of the issuing CA’s to the Cert Publisher’s group in each child domain and so need the group to be a “domain local” group scope.
I used the following script to complete this as it is not possible to change within the gui of “Active Directory Users and Computers”

Set grp = GetObject(“LDAP://CN=Cert Publishers,CN=Users,DC=sub,DC=example,DC=com”)
grp.Put “groupType”,”-2147483640″
grp.SetInfo
grp.Put “groupType”,”-2147483644″
grp.SetInfo
Changing the DC=sub for each domain

Save the above in a .vbs file and run within an elevated command prompt.

Regards,
RichardK

Related posts:

1. Cert Server do not issue SAN names I have found cases where the CA server do not include...
2. Microsoft release KB977611 to fix home folder deletions when changing home folder path to a DFSR namespace in a AD user account Just to let you know Microsoft have released a hotfix...
3. Active Sync some users cannot set up smartphones We recently had a problem with one of our customers...

Related posts brought to you by Yet Another Related Posts Plugin.

Here’s a scenario, you have a PKI, it all seems to be healthy, but when you try and use the certificates on your client systems, you get ‘unexpected results’

Alternatively, you have issued certificates previously, but when you come to renew, systems fail with ‘unexpected results’

At this point, you might be ready to tear your hair out, or just go home for the night (or the month…). Instead, its worth checking the permissions on the folder where the client OS stores the systems private keys. If the ACL has been changed from the system default, results can be, lets say, unpredictable.

On XP and 2003 systems, the folder in question is “c:documents and settingsall usersapplication datamicrosoftcryptorsamachine keys”. This folder must NOT be inheriting permissions from its parent, and the ACL for the folder should contain Everyone:RW:This Folder Only, Administrators:F:This Folder Only – and nothing else! If you need to grant a service account access to one of the keys, add the account to the ACL on the specific file within the folder. Each file in the folder has explicit permissions defined, which will vary depending on the application that generated it, as a minimum they must include System:F and Administrators:R

Quite why the systems private keys would be stored in the All Users profile, I don’t know, but it has been moved in Vista and Server 2008 to “C:ProgramDataMicrosoftCryptoRSAMachineKeys”, which seems far more logical, and prevents errors where misguided administrators reset the permissions on the entire All Users profile. The ACL structure for the folder and its files remains the same.

A final word of warning – as with anything you read on the web, its always worth checking these ACL’s against a system in your environment that you know to be working, if you have one. It doesn’t matter how much you trust the writer, there’s nothing like the comfort of seeing a working system with your own eyes before you propose a change to hundreds or thousands of systems…

See the next post for info on scripting changes to the ACL’S

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.