PKI : Publishing CRL to an IIS Website Automatically

 

PKI : Publishing CRL to an IIS Website Automatically

This article covers the required steps for configuring an Issuing CA to publish its CRL automatically to an IIS Website that is accessible externally.

1.       Deploy an IIS Web Server to host the AIA and CDP;

a.       Create a file share ‘PKI’ with Modify Permissions for “Cert Publishers” and the AD DS Computer accounts of the Issuing CA’s deployed in step 3.

b.      Create a new Website in IIS, use the PKI share created above as the home directory. Use port 80 and a host header to differentiate the site.

c.       Via IIS Manager ‘Allow Double Escaping’ under the web site > Request Filtering > Edit Feature Settings (in action pane). 

d.      Ideally, publish this website using TMG/ISA Server.

 

2.       Next deploy the issuing CA (if you already have then skip this step); this is the front-line of your PKI. When deploying a CA I’d suggest the following as good practice:

a.       Don’t forget to use the CAPolicy.inf file. This should be created in advance of installing the AD CS role. This will reduce the impact of deployment in any production environment, especially the “LoadDefaultTemplates=False” option which will ensure the CA cannot issue any certificates until you configure it to do so. An example CAPolicy.inf file is below:

{code lang:ini title:”CAPolicy.inf” lines:false hidden:false}[Version]
Signature=”$Windows NT$”

[certsrv_server]
RenewalKey length =2048
RenewalValidityPeriodUnits=6
RenewalValidityPeriod=years
LoadDefaultTemplates=False
CRLPeriodUnits=3
CRLPeriod=days
CRLDeltaPeriodUnits=12
CRLDeltaPeriod=hours
CRLOverlapPeriod=Hours
CRLOverlapUnits=8
CRLDeltaOverlapPeriod=Hours
CRLDeltaOverlapUnits=8
[PolicyStatementExtension]
Policies = AllIssuancePolicy
Critical = FALSE

[AllIssuancePolicy]
OID = 2.5.29.32.0{/code}

 

3.       Configure CDP / AIA settings on the new CA:

a.       CDP; Remove http and file locations already listed and then add the following MANUALLY (do not copy paste!):

·         file://\\ <IIS server>\PKI\cdp\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

·         http://<external DNS name> /cdp/<CaNAme><CRLNameSuffix><DeltaCRLAllowed>.crl

·   File point s should be set to ONLY: Publish CRL’s to this location, Publish Delta CRL’s to this location

·   HTTP point should be set to ONLY: Include in CRLs, Include in the CDP extension of issued certificate

·   LDAP point should be set for all other than IDP

 

b.      AIA; Remove http and file locations already listed and then add the following MANUALLY (do not copy paste!):

·         file://<IIS Server>\PKI\aia\<ServerDNSName>_<CaName><CertificateName>.crt

·         http://<external DNS name>/aia/<ServerDNSName>_<CaName><CertificateName>.crt

·         File point should be set to NOT include in AIA extension

·         HTTP point should be set to include in AIA         

·         LDAP point should be set to include in AIA         

 

You’ll need to manually copy the CRT file across from C:\Windows\system32\certsrv\CertEnroll. Make sure you do this every time the certificate is renewed.

 

ConfigMgr : Download Setup ConfigMgr Updates in Advance for Offline Install

ConfigMgr : Download Setup ConfigMgr Updates in Advance for Offline Install

The commands below facilitate deployment of SCCM / ConfigMgr in an offline environment by allowing you to download the setup required updates from another machine.

  • For SCCM 2007 use the following command to download Setup required SCCM updates to C:\TEMP\: SMSSETUP\BIN\I386\SETUP.EXE” /download C:\TEMP
  • For ConfigMgr 2010 use the command: SMSSETUP\BIN\x64\SETUP.EXE” /download C:\TEMP

 

Exchange 2010 : Troubleshooting Inter-Exchange Organistaion Mailflow

Exchange 2010 : Troubleshooting Inter-Exchange Organistaion Mailflow

We recently got caught out by the introduction of an Exchange Server to a relatively new AD site. Prior to the deployment of the server the AD DS site was not an Exchange Site.

After a few hours we started to get calls regarding mail stuck in a queue with the nexthop set as the AD DS site where the new Exchange Server had been deployed. We confirmed this using the Exchange Shell command: get-queue

So we knew that the new Exchange AD DS Site was the root cuase, but why? Next port of call was the Exchange Routing Log Viewer, available from the Exchange Management Console, under Toolbox.

First things first you’ll need to edit the file. From the File menu select ‘Open log file…’ Enter a HT server name then click ‘Browse server files.” Right-click the filw you wish to open and select ‘Open with…’ then select ‘Notepad.’ Now remove all of the lines that read ‘<SourceOrTargetServers />‘ – if you do not complete this step you wont be able to view the log files.

Now open the file in the Routing Log Viewer, expand Active Directory Sites and then a site where delivery of mail to has been affected. You should be able to verify the a) next hop and b) cost of delivery.

You can also compare logs using ‘File’ > ‘Compare log file…’ (remember to edit the file as before). This outlined the changes in routing caused by the site – changes we were unaware would be triggered by deployment of Exchange.

The next step was to acertain where the AD DS site link cost was coming from, there was a IP site link that we were unaware existed. It turned out to be the DefaultIPSiteLink contained this site and another key site – thus skewing the Exchange Routing Table once Exchange had been deployed to this site. This left us three options:

  1. Remove the new Exchange Site from the DefaultIPSiteLink
  2. Assign an Exchange Site Link cost to this site link (using set-adsitelink)
  3. Increase the cost of the DefaultIPSiteLink in AD DS

We went with option 1, the problem then cleared up within a few minutes; moral of the story – when deploying Exchange into an Active Directory site where it has not previously been installed check any and all site links where the AD DS site is defined as a member.

AD DS : DCPROMO fails with A domain controller for the specified domain could not be located.

AD DS : DCPROMO fails with A domain controller for the specified domain could not be located.

Check the DCPROMO log files located under: C:\Windows\Debug.

Perform the following test on the server: nltest /dsgetdc:<fqdn of a functioning domain controller>

You can also confirm, that you can lookup srv records in DNS, execute the following from a command prompt:

  1. nslookup
  2. set type=all
  3. _ldap._tcp.dc._msdcs.<domain_name>

If SRV records are returned then it is more than likle this is a firewall related issue. Check logs for blocked traffic, specifically on UDP and TCP port 389.

Active Directory: Firewalled Domain Controller Issues

Active Directory: Firewalled Domain Controller Issues

In implementing a new child domain recently I encountered some strange and typically unhelpful error messages which turned out to be firewall related. Moral of the story, ensure that all of your domain controllers can communicate with each other on all of the ports listed here: http://social.technet.microsoft.com/wiki/contents/articles/active-directory-replication-over-firewalls.aspx

Also, ensure that all of your clients can also communicate on these ports.

Symptoms

When trying to create a new account using dsa.msc:


 
Windows cannot verify that the user name is unique because the following error occurred while contacting the global catalog: a local error has occurred.

When trying to modify group membership via dsa.msc:

The following Active Directory Domain Services error occurred: The system detected a possible attempt to compromise security.

When browsing the GC using adsiedit.msc:

Operation failed: Error code: 0x80090350. The system detected a possible attempt to compromise security.

Confirm time is the same on all Domain Controllers in the forest, this is especially important if you domain is a child domain.

Test srv records for GC:

  1. nslookup
  2. set type=srv
  3. _ldap._tcp.<site name>._sites.gc._msdcs.<fully qualified domain name>

Confirm replication is working as expected: repadmin /showreps

GC is browsabel via ADSIedit connecting on port 3268

 

QLogic 10Gb CNA for IBM System x and IBM Power : Connectivity Issues

QLogic 10Gb CNA for IBM System x and IBM Power : Connectivity Issues

I ran into an isse with a couple of X3650 M3 servers recently where after connetcing the Cisco TwinAx cables, linking the CNA’s to a Nexus 5000 switch, the cards did not seem to function properly:

  1. The SAN and LAN LED’s flashed at the same time, slowly. Looking at the product hardware manual this indicated the CNA did not have a connection!
  2. Ethernet connectivity appeared to work via one port but not the other
  3. The QLogic teaming utility was unreliable/unstable when configuring a network team using the CNA ports
  4. Once teamed, when disconnecting a single cable the team would not failover
  5. Disabling/enabling a port in Windows caused the system to become unresponsive
  6. The qlvt.exe applictaion kept hanging causing the system to be unresposive / hang on restart requiring a hard reset.

After rebuiling the OS on the servers, installing newer driovers (1.0.1.3) and the most recent firmware I eventually started to look further down the stack.

I eventually set my sights on the physical cables; using the following command we were able to identify the cable in use (it was at a remote site):  sh interface e1/30 transceiver calibrations

Ethernet1/30
    transceiver is present
    type is SFP-H10GB-CU5M
    name is CISCO-MOLEX    
    part number is 74752-9047     
    revision is 07 
    serial number is MOC15144945    
    nominal bitrate is 10300 MBit/sec
    Link length supported for copper is 5 m
    cisco id is —
    cisco extended id number is 4

The part number relates to a passive 10GB TwinAx cable, note passive. After some more digging it was identified that the IBM card only supported active cables as identified in the supported IBM Cables here: http://www.redbooks.ibm.com/abstracts/tips0720.html

The cables have now been swapped for active cables and the issues above have all disappeared.