Adjusting Windows Certificate Authority Validity Period

For the second time since going live with our CAMPUS Active Directory Services, the Subordinate Certificate Authority that is bound to our production domain has come very close to expiring.  What gives with the default two year validity period for Microsoft CAs?  Verisign’s certificates are not any less secure than ours, and they have 5+ year CA validity periods.

After much head banging, I discovered this KB:
http://support.microsoft.com/kb/254632/en-us

The reason I have been having so much trouble is that the Microsoft domain-rooted CA will use either the issuing certificate template validity period (which is what I would expect) or the maximum CA cert validity period defined in the CertSvc registry key, whichever is less (which is not what I expected at all).

After setting the registry values in the KB on my Enterprise Root CA, I now have a SubCA that has a five year validity.  Huzzah!

Here is what did not work:

Creating a new Subordinate CA Certificate with a five year validity period…
This failed because the existing CA uses for renewal the template that issued it’s certificate initially.  Thus, if I remove the default “SubCA” template from the list of certificate templates to issue, cert renewal fails claiming that there is no appropriate template available.  I can’t seem to add the default SubCA template to the “superceded templates” list, either.  It is likely that this is a hard-coded limitation; perhaps MS does not want us altering the default CA templates?  Whatever… at least I get a bit more time on my certs now, thankfully.

iSCSI block device migraiton plan for NetApp filer

If you have a NetApp, and you ever need a plan for migrating your iSCSI block devices from one filer head to another, here is a step by step:

1. Stop services on your iSCSI initiator host that may be writing to your lun to be migrated.
2. Refresh your target lun from source using snapmirror:
   snapmirror update <target>
3. Break your snapmirror relationship to prevent further writes to the new production lun:
   snapmirror break <target>
4. edit /etc/snapmirror.conf, remove the entry for your broken snapmirror target.
5. stop any remaining services on source server that rely on iSCSI storage
6. stop iSCSI initiator service
7. Upgrade MS iSCSI initiator to current version (at this time, v2.0.5
8. Unmap your original lun on the source filer:
   lun unmap <source lun>
   (NOTE: “lun show -m” can be useful for displaying existing map relationships)
9. Map your new lun to an iSCSI initiator group that contains your host:
   Map lun map <target lun> <target iSCSI group>
   (NOTE:  You can use igroup create -i -t windows <iSCSI group> and igroup add <initiator ID> <iSCSI group> to define the “iGroup” used in this command.  The initiator ID can be read from the poperties of the MS iSCSI Initiator Control panel.)
10. start the iSCSI service
11. log in to the new iSCSI targer, bind lun
12. restart services

Migrating NetApp filers

We are preparing to migrate from our FAS270c NetApp filer to a new FAS3050c.  Migration/Upgrade procedure documentation is a bit sketchy on the NetApp site, so I thought I should put together my own step-by-step.  Here it is, a work in progress…

Pre-migration:

1. Verify destination filer settings:
   1. Quota configuration – compare /etc/quotas to current config on “files”.
   2. CIFS config:
      1. /etc/cifsconfig_shares.cfg
      2. /etc/cifsconfig_setup.cfg
      3. /etc/cifs_homedir.cfg
   3. Filer options:
      capture output from “options” command and compare settings to source filer. – DONE!
   4. DNS and WINS registration settings

Migration:

1. Disable CIFS on the source filer:
   cifs terminate -t 0
2. Force final SnapMirror synchronization:
   1. snapmirror update coffee:vol1
   2. snapmirror update coffee:vol2
   3. snapmirror update coffee:vol3
      (Note:  the “-w flag can be used if we want to wait for a mirror operation to complete before returning control to the console)
3. Break snapmirror relationship:
   1. snapmirror break coffee:vol1
   2. snapmirror break coffee:vol2
   3. snapmirror break coffee:vol3
   4. update /etc/snapmirror.conf, remove old relationship definitions.
4. Initialize quotas on target filer:
   1. quota on vol1
   2. quota on vol2
   3. quota on vol3
5. Rename the source filer

1. cf disable the cluster.
2. Verify SPNs for “files” computer account.
3. delete “files” computer account
4. assign new IP address to the filer, reboot
5. run cifs setup on source filer
   1. read config using rdfile /etc/hosts
   2. Assign new IP using ifconfig vif1-720 132.198.102.???
   3. ping to/from an external host to verify the update
   4. verify /etc/hosts and /etc/rc, then reboot to verify IP change
   5. update settings in options autosupport to reflect host name changes.
   6. Verify or force registrations in /etc/hosts, WINS, DNS.  May need to manually register DNS using “nsupdate” on cdc01.
6. reboot to verify CIFS config files
7. Check settings in /etc/nsswitch.conf
8. cf enable  the cluster
9. reset filer login info in dfm:

1. dfm host set <hostname> hostlogin=<username>
2. dfm host set <hostname> hostpassword=<password>

Rename the target filer

1. cf disable the cluster.
2. delete “blocks” computer account 
3. assign new IP address to the filer, reboot
   1. read config using rdfile /etc/hosts
   2. Assign new IP using ifconfig vif1-720 132.198.102.16
   3. ping to/from an external host to verify the update
   4. verify /etc/hosts and /etc/rc, then reboot to verify IP change
   5. update settings in options.autosupport to reflect host name changes.
4. run cifs setup on destination filer
5. reboot to verify CIFS config files
6. Verify or force registrations in /etc/hosts, WINS, DNS
7. Check settings in /etc/nsswitch.conf
8. cf enable  the cluster
9. reset filer login info in dfm:

1. dfm host set <hostname> hostlogin=<username>
2. dfm host set <hostname> hostpassword=<password>

Post-migration testing:

1. Home directory connections via CIFS (Windows 2000/XP/Mac)
   Verify all variations on homedir mounting still function:

   1. \filesNetID
   2. \files~
   3. \filescifs.homedir
2. Home directory connection via SFTP/WebDAV
3. Kerberos authentication from CAMPUS and “uvm.edu” k5 realm
4. NTLM authentication levels/packet signing
5. Quota enforcement
6. Cluster failover
7. DFM monitoring (need to update passwords used by DFM for connection to filers)
8. Autosupport info in NOW.NETAPP.COM.
9. NDMP backup from Networker.