Hello S-1-1-0! Recently I was extremely busy on various stuff including PS PKI Module writing, as the result I hadn’t enough much time to write here. Today I would like to announce a new Manning book called PowerShell Deep Dives. the project started last year and by bringing PowerShell MVP community, the stuff went quite quickly.

Why I’m advertising this book?

1. The book is believed to be very interesting to all sort of IT Pro and Devs who is interesting in PowerShell. The book is divided in four general sections: Administration, Scripting, Development, PS for Platforms. Everyone of you will find something interesting for yourself.
2. All chapters in the book are written by PowerShell MVPs = quality guaranteed!
3. No one from writers or book coordinators will get a cent from book sales. All revenue will go to charity: to the memory of Will Steele, one of our co-authors and important member of the PowerShell community.

Hello folks, today I want to present you my another product in PKI integration with Windows PowerShell. I worked hard on server-side extensions: PowerShell PKI Module, which is (so far) the biggest project I have developed.

Now I got a time to work on client side extensions. Some prototypes are already published in this blog. The first complete tool (which is a part of client-side extensions) is self-signed certificate creation for testing purposes. The reason why I developed this tool is that makecert.exe (from Windows SDK) is now deprecated. The blog post provides a replacement for makecert — certreq.exe tool. Although, certreq is very cool, there are few things to note:

1. certreq uses external INF file which may be a bit complicated.
2. if there is a mistake in the INF file, certreq raises exception message box. It is a pain when the message box is raised in PowerShell remoting session. You never will see it and unable to close it!

Update 14.03.2013: added workaround information

SYMPTOMS

Consider the following scenario. You install and configure Certificate Enrollment Web Service (CES) against a Certification Authority (CA) that has spaces and other disallowed by HTML URL scheme characters in the certificate name. When you attempt to use the service for certificate enrollment, the following message appears:

Updated 20.06.2018: clarified the purpose of NTAuthCertificates DS container.

Hello folks! Today I want to explain in details about Active Directory containers related to ADCS (Active Directory Certificate Services), their purposes and how they work.

Intro

All ADCS related containers are stored in configuration naming context under Public Key Services container:

CN=Public Key Services, CN=Services, CN=Configuration, DC={forest root domain}

Since Public Key Services container is stored in configuration naming context, any it’s content is replicated between all domain controllers in the current forest (not only current domain) and are available to any client in the forest. This means that there is no way to limit PKI containers only to specific domain or domains.

Here is a screenshot from ADSIEdit.msc tool:

Just let you know, it is pushed (with sources) to CodePlex.

>> Welcome <<