I was recently having a discussion about the definition of multifactor authentication and what actually constitutes one, two or three factor authentication.  There seems to be confusion around these definitions, so I am posting some industry accepted definitions for all to see or reference.  Authentication methodologies involve three basic “factors”:

I came across this very useful free tool for alerting when a certificate that has been issued by an internal Microsoft Certificate Authority is going to expire (SCOM can do this too but this is a good alernative). In the words of the developer:

The Certificate Expiration Alerter helps IT departments monitor the expiration status of all their certificates which are issued from an internal Windows Server Certificate Authority (CA). When a certificate is about to expire, the Certificate Expiration Alerter sends a notification email with information about the certificate. This allows IT administrator to be proactive and take action by renewing the certificates before they expire and prevent possible service downtimes.

For more info, see these 2 websites – http://blogs.technet.com/b/nexthop/archive/2011/11/18/certificate-expiration-alerting.aspx and http://sourceforge.net/projects/certexpalerter.
 
 

During a new deployment of a Certificate Services, I needed to increase the validity period of the CA certificate issued from the root (and offline) CA to the issuing CA (online and domain joined). By default this is only valid for 1 year. After unsuccessful hunting around the GUI options, I realised that this is going to be a registry change:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CertSvc\Configuration\
Find ValidityPeriod. Set the value one of the following – Days, Weeks, Months or Years.
Find ValidityPeriodUnits and set this to the numeric value that you want.
Then restart the Certificate Services NT service.

I made this change on both the root CA and issuing CA because I wanted to increase the validity period of not just the CA certificate that is issued from the root CA, but also any certificates that are issued from the issuing CA also. Be aware that validity period may also be set in the certificate template and templates supported by Windows 2000 and Windows Server 2003 Standard Edition cannot be modified. Templates supported by Windows Server Enterprise Edition (Version 2 templates) do support modification.

There is a bit more detail here if required – http://support.microsoft.com/kb/254632.

I had set my SCCM 2007 R2 environment (using native mode) up for automatic client push but noticed that none of my clients have the SCCM agent installed after a few days. The log contained at c:\windows\ccmsetup\ccmsetup.log on the client showed that the installation was failing and the error messages included:

WINHTTP_CALLBACK_STATUS_FLAG_CERT_CN_INVALID is set
Failed to send HTTP request. (Error at WinHttpSendRequest: 12175)

This indicates that the computer name that the client is using to contact the management point doesn’t match the FQDN in the Web Server certificate Subject, which is installed on the server and configured in IIS.

The solution was to request (from the enterprise certificate authority) and assign a new certificate in IIS. Using IIS 7.5, open the IIS manager console, click on the server name, double-click Server Certificates and then Create Domain Certificate. Fill in the details and select your enterprise EA server. It is important here to use the FQDN of the server in the Common Name section. Once complete, head to the Default Web Site, edit Bindings and click on edit for https, then select your newly issued certificate. You don’t need to restart IIS. Initiate a new client install – it should be successful this time.

We’d rolled out Office Communicator 2007 R2 across the environment, however a handful of machines were getting the ‘Cannot synchronize address book’ error and when expanded the entire error message was ‘Cannot synchronize with the corporate address book. This may be because the proxy server setting in your web browser does not allow access to the address book.’

So after doing some extensive Googling, I did some troubleshooting and found that the situtation was:

- There was no issue with the proxy server. I could manually enter the name of one of the address book files (eg https://ocs.domain.com/Abs/Ext/F-0918.lsabs) and download it manually through the browser.

- There is no GalContacts.db file in the ‘C:\Documents and Settings\%UserName%\Local Settings\Application Data\Microsoft\Communicator’ folder meaning that there was no locally cached copy of the address book.

- In the registry under ‘HKCU\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\INTERNET SETTINGS’ if I set the CertificateRevocation DWORD and to 0, I can successfully sign in and retrieve the address book (below)

This pointed to an issue with the certificate we were using and specifically the Certificate Revocation List (CRL). From here we need to check the certificate we were using for OCS, look at the details tab and check the CRL Distribution Point (shown below)

I then checked this distribution point (a HTTP location in our case) and found out that it was invalid. Right, so next it was off to reconfigure our internal Certificate Authority server with the correct CRL locations.

On the Certificate Authority, we open up the MMC snap-in, right click the server name and select properties. On the extension tab, select ‘CRL Distibution Point’. You then want to configure some valid location underneath here and tick the box to ensure these are being included in the issued certificates. For example in my case, I ensured that there were 3 additional entries (not including the C:\Windows one):

LDAP:///CN=<CATruncatedName><CRLNameSuffix>,CN=<ServerShortName>,CN=CDP,CN=Public Key Services,CN=Services,<ConfigurationContainer><CDPObjectClass>
[TICK] Publish CRLs to this location
[UNTICK] Include in all CRLs…….Active Directory…..
[UNTICK] Include in CRLs….Delta CRL Locations…..
[TICK] Include in the CDP extension of issued certificates
[TICK] Publish Delta CRLs to this location

file://\\<ServerDNSName>/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
[TICK] Publish CRLs to this location
[GREYED OUT] Include in all CRLs…….Active Directory…..
[UNTICK] Include in CRLs….Delta CRL Locations…..
[TICK] Include in the CDP extension of issued certificates
[UNTICK] Publish Delta CRLs to this location

http://<ServerDNSName>/CertEnroll/<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl
[GREYED OUT] Publish CRLs to this location
[GREYED OUT] Include in all CRLs…….Active Directory…..
[UNTICK] Include in CRLs….Delta CRL Locations…..
[TICK] Include in the CDP extension of issued certificates
[GREYED OUT] Publish Delta CRLs to this location

Selecting OK will then restart the Certificate Services service. Then you need to recreate your OCS certificates via the OCS MMC certificate wizard. Once these have been applied to the OCS server (OCS services do NOT need to be restarted), you clients just need to sign out and back in and all of your address book issues are fixed!

If you look at your new certificate, the newly added CRL Distribution Points should be listed. You can also use the ‘Certutil.exe –v –verify –urlfetch c:\exported_certificate.cer’ with above certificate and check that CRL locations can be reached successfully. The ‘pkiview.msc’ tools from the Windows 2003 Resource Kit was also very useful in checking that the CRL locations could be reached.