I want to start with a little disclaimer: The real credits for this tool does not really belong to me. This tool is using the really wonderful PSPKI PowerShell module from http://pspki.codeplex.com/ and all credits should go them for making this wonderful piece of work public. I just format the output that those cmd-lets provide into a HTML based report.

A very common problem people have with certificates is that they realize that it’s time to renew their certificates… after they have expired!

To be able to get a web based report of the certificates in an ADCS CA that is about to expire within 30 days, I wrote this small script today on the train on my way to work. It accepts two switches, –computername of the CA (which defaults to local computer if not specified) and –reportfile (defaults to a HTML-file on the current users desktop).

The script can be run locally on the CA if desired.

This opens up the report.

The report contains all certificates that are expiring within 30 days. This can be edited in the script.

I want to thank a small group of people for their input during the day.

Ludwig “Ludde” Nilsson = for cosmetic input regarding the HTML report.

Stefan Schörling = for his support, thoughts and feedback during the development of this script.

Kerim Sidia = for validation of “intelligent” design.

Niklas Goude = for his clever idea regarding detection of the PSPKI module.

Hasain Alshakarti = for a good note about that the filtering is client based (very large ADCS databases will take longer time to process).

Please note that this is a simple proof of concept and is not done or complete in any way. I will continue to work on this and include many more switches, etc.… but I wanted to show you guys already now what can be done if people share their knowledge and work together.

The code to the script is embedded below.

PKI and ADCS is fun, so go out and play!

// Fredrik “DXter” Jonsson

#ADCS Certificate Expiration Report Tool
#Made by Fredrik “DXter” Jonsson (dxter@poweradmin.se) 2011-08-09
#http://www.poweradmin.se

#Get input strings
param(
  [string] $computername = “$ENV:COMPUTERNAME”,
  [string] $reportfile = “$ENV:USERPROFILE\Desktop\acert_certificate_expiration_report.html”
   )

#Start stopwatch
$totalTime = New-Object -TypeName System.Diagnostics.Stopwatch
$totalTime.Start()

#Credits
Write-Host
Write-Host “ADCS Certificate Expiration Report Tool ” -ForegroundColor “Yellow”
Write-Host “by Fredrik “”DXter”" Jonsson (dxter@poweradmin.se)” -ForegroundColor “Yellow”
Write-Host

if(Get-Module -ListAvailable -Name PKI | Where-Object { $_.name -eq “PKI” })
{
#Import PSPKI PowerShell module
if(Get-Module -Name PKI | Where-Object { $_.name -eq “PKI” })
{
Write-Host “PSPKI PowerShell module already imported…” -ForegroundColor “Yellow”
}
else
{
Write-Host “Importing PSPKI PowerShell module…” -ForegroundColor “Yellow”
Import-Module -Name PKI
}
Write-Host

#Set variables
Write-Host “Setting variables…” -ForegroundColor “Yellow”
Write-Host
$caname = $computername.ToLower()
$domaindns = $ENV:USERDNSDOMAIN.ToLower()
$todaysdate = Get-Date
$findaldate = $todaysdate.AddMonths(1)
$htmlpre = “<P>Generated by user: $ENV:USERNAME</P><P>The following certificates expire before $findaldate</P>”
$htmlpost = “<P>Certificate expiration information retrived from $caname.$domaindns</P>”
$htmltitle = “Certificate expiration information from $caname.$domaindns”
$htmlinput = Get-CertificationAuthority “$caname.$domaindns” | Get-IssuedRequest -Filter “NotAfter -ge $(Get-Date)”, “NotAfter -le $((Get-Date).AddMonths(1))”

#Generate report
Write-Host “Generating report…” -ForegroundColor “Yellow”
Write-Host
$htmlinput | ConvertTo-Html -Body (Get-Date) “Report date:” -Property RequestID,RequesterName,CommonName,NotBefore,NotAfter,SerialNumber -Pre $htmlpre -Post $htmlpost -Title $htmltitle | Out-File -FilePath $reportfile

#Open report
Write-Host “Opening report…” -ForegroundColor “Yellow”
Write-Host
Invoke-Item $reportfile

#Warning if PSPKI is not installed
}
else
{
Write-Host “PSPKI is not installed. Please install it from http://pspki.codeplex.com/ ” -ForegroundColor “Yellow”
Write-Host
}

#Stop stopwatch
$totalTime.Stop()
$ts = $totalTime.Elapsed
$totalTime = [system.String]::Format(“{0:00}:{1:00}:{2:00}”,$ts.Hours, $ts.Minutes, $ts.Seconds)
Write-Host “Process total time: $totalTime” -ForegroundColor Yellow
Write-Host

No related posts.

At this TechDays 2011 here in Sweden, I got a question when I was standing in the Swedish Windows Security User Group booth about if there was some easy way to determine if the Microsoft Base CSP (KB909520) is installed on a machine or not. My instant answer was to try to run pintool.exe since it is a PIN management utility that comes with the Base CSP.

However, in Windows Vista and above, even if the Base CSP is included by default, pintool.exe isn’t. This is because this functionality has been merged into the Windows logon screen that is native in Windows.

Just for fun, and because of my unusual big amount of spare time a few days ago, I wrote this very small PowerShell script to check if Base CSP is installed on a local or remote machine. The script is doing this regardless if the target computer is running a pre or post Windows Vista operating system, since the script is simply checking if the dll for Base CSP is installed in Windows or not.

The reason I am not using the Get-HotFix cmd-let that is native in PowerShell is that Base CSP is not available as an hotfix for Vista and later since it is already included. Therefor, it will not show up as an installed hotfix.

The reason that I am checking for that file and not the Gemalto .NET mini driver (that is also a part of KB909520) is that the axaltocm.dll mini driver for the Gemalto .NET cards might be installed, but not always. In Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008, it is installed by default with the Base CSP. But it is not installed be default in Windows 7 and Windows Server 2008 R2!

This is because the mini drivers for smartcards are dynamically installed when needed from Windows Update through the smartcard plug and play feature in Windows 7 and Windows Server 2008 R2. (You have to enable it on 2008 R2. It is disabled by default for security reasons.)

The script relies on two quite basic components, remote access to the C$ share of the computer and that it is responding to ping to be able to check if the machine is available on the network or not. If you don’t like this, simply remove that part from the code.

If no input for the computer parameter is given, the script will default on localhost.

Here we try to check the computer SRV0042. It is not responding to ping and is assumed to be offline.

If you need to distribute the Base CSP through WSUS, I wrote a blog post about for a year ago: http://poweradmin.se/blog/2010/01/15/distributing-the-base-csp-for-windows-xp-with-wsus/

My dear friend Hasain tipped me about the following one liner to list all installed CSP’s in Windows with PowerShell. Sometimes the coolest things are both short, easy and brilliant, even if you don’t think about them.

Get-ChildItem HKLM:\SOFTWARE\Microsoft\Cryptography\Defaults\Provider | Format-List

The script can be found below. Enjoy!

// Fredrik “DXter” Jonsson

#Get input strings
param(
  [string] $computer = "localhost"
   )
.$ENV:SystemRoot\System32\ping.exe -n 1 $computer | Out-Null
if ($? -eq $True)
{
if (Test-Path -Path "\\$computer\C$\Windows\System32\basecsp.dll")
{
    Write-Host
    Write-Host "Microsoft Base CSP is installed on $computer!" -ForegroundColor Green
    Write-Host
}
else
{
    Write-Host
    Write-Host "Microsoft Base CSP is not installed on $computer!" -ForegroundColor Red
    Write-Host
}
}
else
{
    Write-Host
    Write-Host "$computer is not available!" -ForegroundColor Red
    Write-Host
}

No related posts.

For some time now, I have been a little bit tired of certmgr.msc, the certificate management MMC-snap in.

Not only by the fact that a user needs local administrator rights to be able to open it (because MMC itself needs it),  but it also doesn’t show info about if certificates are on smartcards or not and it does not have a quick command for the computer certificate store, etc.…

So instead of just whining, I decided to create my own certificate viewer in PowerShell (which does NOT need any elevation).

Hereby, I present my own certificate viewer.

My PowerShell script only needs one parameter and that is the thumbprint of the certificate you want to view (wildcards are accepted).

The script will search both the current users and the local computers personal certificate store until the certificate is found. You will see output such as if the certificate is stored on a smartcard, if it has been exported, which CSP it is using, what key container it is stored in, etc.…

Not enough info? Well, run the script in an elevated PowerShell prompt instead and check the output of that then!

The script can be found in the download section! Enjoy!

// Fredrik “DXter” Jonsson

No related posts.

Now don’t get me wrong, I absolutely love ADFS. I think is a great way to enable single sign on and federated login on a per application basis using existing identities in your infrastructure. However, the only thing I don’t like about ADFS is the management of its certificates.

Now that might be a strange thing for a guy like me to say, but I see much improvement potential with the certificate management part in ADFS.

Certificate management for the certificates is disabled by default (you need to enable it through PowerShell), ADFS require a SAN attribute in the certificate that is the same as the CN (why, I don’t know), the Service-Communications certificate does not get updated in the ADFS site in IIS when you change it, ADFS itself has no certificate enrollment capabilities unlike other server roles that utilize certificates such as IIS or ADDS, the ADFS context (by default) does not have access to the certificates private keys giving multiple errors in the event viewer, etc..

And it does not get better by the fact that the ADFS help in PowerShell has errors in it (the help says the parameter is Token-Encryption, which is wrong, it is called Token-Decryption)!

Yesterday when I was on the train on my way to work I decided to play around a little with PowerShell and ADFS. And since I knew that there was quite many cmd-lets for ADFS that comes with the ADFS 2.0 role, there just had to be some scripting possibilities here!

So I wrote a script that automatically adds and sets a specific certificate for ADFS different purposes and it also updates the SSL-binding in IIS for the Service-Communications website. Everything is done with native cmd-lets for ADFS 2.0, IIS and Windows Server 2008 R2.

Before the execution of the script. Notice the self signed decryption and signing certificates that comes by default and that they are the primary certificates.

The script executes with only one necessary parameter, and that is the exact thumbprint of the certificate in the computers certificate store you want to use for Token-Signing, Token-Decryption and Service-Communications. It also restarts both the ADFS service and the IIS service when it is done with its configuration in each service.

After the script has executed, a new certificate with common name adfs1.poweradmin.se is the primary token-decryption, token-signing and service communications certificate!

And if we take a look at the ADFS website in IIS, the script has also changed the SSL-binding for that website!

The script can be found in the download section! Enjoy!

// Fredrik “DXter” Jonsson

No related posts.

One of my favorite features in MDT 2010 is that everything you do in the GUI is executing a PowerShell command that is using the cmd-let’s that comes with the MDT 2010 PowerShell snapin.

This gives excellent opportunities for scripting geeks such as Dalle and myself since we can automate and do exactly everything what the GUI does, since the GUI itself is using PowerShell behind the scenes.

This weekend I upgraded my private MDT environment to MDT 2010 Update 1 which was a very smooth operation. I have a very simple MDT environment at home with a single WDS/MDT server. Since I wanted to have the new and cool background picture in Windows PE that comes with Update 1, I had to update the boot images and import them to the WDS server, which in my case was on the same machine.

Therefore I created this little PowerShell script that does that for me automatically. The script is using the PowerShell cmd-let Update-MDTDeploymentShare and PS-Drive provider that comes with MDT 2010 snaping. It is also using wdsutil which is a command line based tool for managing WDS.

The script does the following tasks:

1. Generates completely new and updated boot images for your deployment share.

2. Removes you previous LiteTouch boot images from your WDS server.

3. Imports the newly created LiteTouch boot images into your WDS server.

4. Set each boot image as default boot image for respective architecture.

I must say, it works really nice.

“Do more with less…” – the PowerShell way.

The script is defaulting to MDT default names, descriptions and file locations. If you have changed any of this, please update the script according to your environment. Some people may ask why I choose to use Remove-Image and Add-Image and not Replace-Image. Well, the answer is quite simple. If I have deleted the boot image in WDS, the script would not be able to execute since there is no image to replace. If we split it up in to two commands, we will always be able to recreate our boot image in WDS regardless if the boot image is present or not, since only the Remove-Image command will fail and not the Add-Image.

So right now I have scheduled this script to run on my WDS/MDT server each midnight. If I add any new storage or NIC drivers into MDT, they will be injected automatically into the boot images during the next scheduled generation of boot images during the night and I “never” have to open the WDS console manually again!

Here is the script (don’t forget to modify it according to your installation):

Add-PSSnapIn Microsoft.BDD.PSSnapIn

New-PSDrive -Name "DS001" -PSProvider MDTProvider -Root "C:\DeploymentShare"

Update-MDTDeploymentShare -path "DS001:" -Force –Verbose

wdsutil /Remove-Image /Image:"Lite Touch Windows PE (x86)" /ImageType:Boot /Architecture:x86

wdsutil /Remove-Image /Image:"Lite Touch Windows PE (x64)" /ImageType:Boot /Architecture:x64

wdsutil /Verbose /Progress /Add-Image /ImageFile:C:\DeploymentShare\Boot\LiteTouchPE_x86.wim /ImageType:Boot

wdsutil /Verbose /Progress /Add-Image /ImageFile:C:\DeploymentShare\Boot\LiteTouchPE_x64.wim /ImageType:Boot

wdsutil /Verbose /Set-Server /BootImage:Boot\x86\images\LiteTouchPE_x86.wim /Architecture:x86

wdsutil /Verbose /Set-Server /BootImage:Boot\x64\images\LiteTouchPE_x64.wim /Architecture:x64

I must say, thank god for PowerShell!

// Fredrik “DXter” Jonsson

No related posts.

Thanks to my post http://poweradmin.se/blog/2010/05/08/pkiview-msc-doesnt-say-the-entire-truth and the great, open and quick communication between myself and Microsoft, PKI View is no longer a part of KB889250, which is the step by step guide for CA decommission. I really salute Microsoft for listening to the communities (such as blogs ) and removes references in KB’s that have unexpected behaviors and may cause confusion for people! Kudos to you guys!

I guess it is back to hardcore, old school stuff again with ldifde.exe, dssite.msc and adsiedit.msc when it comes to CA decommissions, which is just fine with me!

Who knows? Maybe two guys will make a very nice PowerShell based GUI for managing the Public Key Services container using the Cmd-Lets for Active Directory in Windows Server 2008 R2? Time will tell…

// Fredrik “DXter” Jonsson

No related posts.

I guess I am not the only one that usually removes old PKI stuff from the Public Key Container in Active Directory with pkiview.msc.

However, recently I discovered something that kind of bothered me. I was working with a customer of mine, and I was removing some stuff in sites and services regarding a decommissioned DC and I by curiosity open the Public Key Services container to take a look at it. I found three objects in the KRA Container and I decided to take a look at them with pkiview.msc since it presents PKI related objects in Active Directory in a much nice way than Sites and Services. But you can imagine my face expression when pkiview.msc reported the container as empty!

As you guys must understand, I just had to reproduce this “bug”.

So this morning, I installed a virtual Windows Server 2008 R2 Standard Edition in a isolated environment and made it a DC for the domain wtf.poweradmin.se.

I also made it an Enterprise Root CA for the same domain. After that, I started by confirming that the KRA object was located in that container. There are multiple ways to look at the PKI information in Active Directory but I decided to use five of them for this test.

I started with adsiedit.msc:

ADSI Edit clearly shows that we have a object in the KRA container.

Then I decided to try dssite.msc:

Sites and Services also displays our object in the KRA container (if we show services nodes).

A third option is to use a LDAP using ldifde:

It writes out entries to a text file, and if we look at that text file…

… we can actually see the same info that both ADSI Edit and Sites And Services has provided us earlier.

Our fourth option is to query Active Directory with the Active Directory Module for PowerShell:

PowerShell also shows us our object in the KRA container.

Now, what does the fifth option, pkiview.msc, say about the KRA container? Well…

… according to Manage AD Containers in PKI View, the KRA Container is empty.

I recommend you guys that have removed objects of decommissioned CA’s with the “Manage AD containers” in PKI View: Look again in the KRA Container with ADSI Edit, Sites And Services, LDAP or PowerShell. You might find something interesting left behind.

Update: http://poweradmin.se/blog/2010/06/02/pki-view-is-no-longer-a-supported-way-for-ca-decommission/

// Fredrik “DXter” Jonsson

No related posts.

I have for a very long time tried to explain to people that network security using pre shared keys is a false feeling of security (you should look at PKI based solutions instead )! Many people seems to think that you must have one of those evil hacking tools (that your antivirus probably will detect) to be able to get your password for your WLAN from your computer in a clear text format. But that is incorrect, we can actually do this with built in tools in Windows.

For example, the following one liner is using netsh to reveal your WLAN password and is using PowerShell to sort out the security information and dumps it into a text file in the folder that your are executing the command. This command should be executed in an elevated PowerShell prompt.

netsh wlan show profiles name="the_name_of_your_network_profile_which_is_usually_the_ssid" key=clear | Select-Object -last 8 | Out-File -Filepath .\wlan_security_settings.txt

// Fredrik “DXter” Jonsson

No related posts.

I am not a very big fan of KB976002, the Microsoft Browser Choice Screen. Here are three ways to prevent it to appear on your computers:

1. The cmd way:

reg add HKLM\Software\BrowserChoice /v Enable /t REG_DWORD /d 0×00000000 /f

2. The VB.NET way:

Public Module Registry
Public Sub Main()

My.Computer.Registry.SetValue("HKEY_LOCAL_MACHINE\Software\BrowserChoice", "Enable", "0", Microsoft.Win32.RegistryValueKind.DWord)

End Sub
End Module

3. The PowerShell way:

Set-ItemProperty -path ‘HKLM:\Software\BrowserChoice’ -name ‘Enable’ -type ‘DWord’ -value ‘0‘

An interesting fact however is that KB976002 can not yet be found in WSUS. I wonder if it will ever show up?

// Fredrik “DXter” Jonsson

No related posts.

Hi,

I sat down thinking a little bit today.
And then It strikes me that the Lab AD was not finished
and that It was not done by best practice.

So I will do the structure from this document from Microsoft,
Best Practice Active Directory Design for Managing Windows Networks.

And then we need to:

1. Create groups
2. Computers
3. OU Information

Then I think we are where we should be.

No related posts.