Archive by Author

How to prevent Voicemail Hacking with AT&T Wireless

I’m sure you’ve read about how various news organizations were hacking into voicemail and such. Turns out it’s crazy easy with various Caller ID spoofing services, and USA Today has a good article on it.
AT&T also has instructions on how to require your voicemail to always ask for a password, but they’re buried deep on the site so I decided to post a link to it here:
Note that the iPhone has an integrated voicemail password function, so even with it set to ON the iPhone doesn’t prompt for a password (i.e. it remembers it). Therefore, if you follow the AT&T instructions and the password is set to ON, you’re good even if your phone doesn’t prompt for a password.
Even if you don’t intend to ever be the subject of a news story, the fact is it would be very easy for any interested person to hack into your voicemail… be it a competitor, co-worker, or significant other. Be smart and verify you have your voicemail properly secured. It might be a bit inconvenient, but definitely the smart thing to do.

How to Upgrade the Distribution Group version from Exchange 2003 to Exchange 2010 for All Objects

In my Exchange environment, I have thousands and thousands of distribution groups, all of which needed to be upgraded to the latest Exchange version so that they could be easily managed in the Exchange Management Console by our help desk.

Not wanting them to have to manually upgrade each one as they came across them, I looked for a way to upgrade all of them all at once. It’s actually quite simple, just run the command below… it simply retrieves each Distribution Group and then runs the “Set” command against it. It doesn’t actually make any modifications to the object though, it just upgrades it to the latest version.

get-DistributionGroup | set-DistributionGroup

How to Automatically Remove Spaces from Legacy Distribution Groups for Exchange 2007 & 2010

In Exchange 2003, it was possible to create a mailNickname (aka Exchange Alias) with special characters in it such as spaces. This poses a major problem in Exchange 2010, as it does a validation on that field and if it’s invalid in any way, it considers it a corrupt object. This prevents you from upgrading the object and will also prevent Distribution Group managers from modifying their lists.

Personally, I manage an Exchange environment with thousands and thousands of groups, hundreds of which included spaces. Modifying them one at a time wasn’t an option, so I found this PowerShell script to remove them programmatically.

Simply copy this script into a text file and name the file “FixDistro.ps1.” Open up the Exchange Management Shell (make sure to Run As Administrator), navigate to the directory holding the script and type: “./FixDistro.ps1”


$DistributionGroups = Get-DistributionGroup -OrganizationalUnit "internal.domain.local/OU/SubOU" | Where {$_.Alias -like "* *"}

ForEach($DistributionGroup in $DistributionGroups) {Set-DistributionGroup $DistributionGroup.Name -Alias:($DistributionGroup.Alias -Replace " ", "")}

It should go through and change all of the Distribution Groups so that they will not have spaces in them. Please note however that if the script runs into a Distro with another special character, it will likely terminate. You can either fix that distro manually and then rerun this script or simply modify this script to replace those particular special characters.

You will get a prompt to upgrade the object to Exchange 2010. Instead of hitting a key each time, just hold down the Enter key and it will fly through them pretty quick.

How to Create a Certificate Request in Windows Server 2008 R2 for Use with Threat Management Gateway 2010

For a recent project I needed to create a certificate request for use with a new listener on Threat Management Gateway 2010. I wanted some specific criteria on the cert, so I really needed to use the Certificates Snap-In in Windows to create the necessary .req file. I had a little difficulty to get this to work right at first, but it turns out there are just a couple of tricks to getting this to work right.

First, open the Certificates snap-in for the local computer and navigate down to the Personal – Certificates certificate store. Right-click on it and go to All Tasks – Advanced Operations – Create Custom Request.

Click Next on the first information screen that comes up, and then verify that Proceed Without Enrollment Policy is highlighted on the following screen. Now Click Next.

Now, by default, the Template combo box has “(No Template) CNG Key” selected, but this won’t work for Threat Management Gateway, as it does not support CNG keys. So you need to change this to “(NO Template) Legacy Key” and click Next (the default selection of PKCS #10 is fine).

On the next screen, you need to click the down arrow next to details, which will expose the Properties button.

Click Properties and fill out the form with the following.

General Tab
Friendly Name – The friendly name is however you want to refer to the certificate, I usually use the full URL so I know exactly why I got this particular certificate, but you can use whatever you want.

Subject Tab
At a minimum you should use the same fields I have listed in Subject Name.

Alternative names are optional, but if you have other URLs the certificate should be valid for you would list them here. You need to verify that the type of certificate you intend to purchase from your certificate authority supports alternative names.

Extensions Tab
There are five subsections under this tab; Key Usage, Extended Key Usage, Basic Constraints, Include Symmetric Algorithm and Custom Extension Definition.

Under Key Usage, you would normally select Digital Signature and Key Encipherment. Your application may vary, but this is a typically what you would use to publish a web site.

For Extended Key Usage, you’ll select Server Authentication and Client Authentication.

The final three you’ll leave as the defaults. Again, you may need them in some specific applications, but this is for publishing a web site or other web service.

Private Key
There are four subsections under this tab; Cryptographic Service Provider, Key Options, Key Type, and Key Permissions.

Under Cryptographic Service Provider, you can really select any one, but I typically use Microsoft RSA SChannel Cryptographic Provider (Encryption).

Under Key Options, you will probably want to change the key size to 2048, which is the new minimum for most SSLs…. Any larger and you may have to pay more for your SSL certificate.

Personally, I generally select the option “Make Private Key Exportable” as this allows me to freely back up and move the key to other servers in the array.

The options under Key Type and Key Permissions can be left as the default. Again, under specific circumstances or for specific applications, you may need to set those options, but this is just for a published web site, nothing more.

Hit Apply and then OK, and that should take you back to this screen:

Click next, select where you want the .req file stored, and you’re all done. After you have submitted the request to your Certificate Authority and recived your signed certificate back, you can import it using the Certificates snap-in for Windows. At that point it will be available for assignment to a Lister in Threat Management Gateway.

How to configure Exchange 2010 & Threat Management Gateway for iMExchange 2 or Other EWS-based Apps

We recently began a whole migration of users over to our Exchange 2010 environment after a successful months-long pilot program. One of our users reported that they could no longer successfully sync iMExchange 2 on their Apple iPhone and iPad after they were migrated from Exchange 2003 to Exchange 2010.

iMExchange 2 is a great program you can use to synchronize your tasks & notes with your iPhonei/iPad/iPod as well as manage your Out-of-Office settings. I only downloaded it for troubleshooting purposes, but it’s an app I’ll keep and use.

In order to troubleshoot it, I installed iMExchange 2 on my own iPhone and began to troubleshoot it.  It was a little puzzling because we didn’t have anything restricted any more than we did in Exchange 2003.  We still had ActiveSync and Outlook Web Access enabled, so one would think everything should work just as well under Exchange 2010.

However, iMExchange 2 doesn’t appear to use Outlook Web Access or ActiveSync under Exchange 2010 (and I would suspect the same is true with Exchange 2007). It actually uses Exchange Web Services, which would normally be set up as a component of Outlook Anywhere. Unfortunately, we don’t use Outlook Anywhere in this environment due to erroneous InfoSec concerns, so I needed to enable some of the functions while still restricting Outlook Anywhere.

So, in order to support it or any apps like it, you need to configure your environment with some of the same things that are used for Outlook Anywhere, but you don’t have to go all the way with it.

On Forefront Threat Management Gateway, you’ll need to use the Exchange Publishing Wizard to publish Outlook Anywhere (note: enable the option for Outlook 2007 extra folders when you come to it) just as you would have for ActiveSync & Outlook Web Access. You can use the same Listener you set up for the other services as well… no need for a unique IP or certificate.

In addition, you’ll likely need to enable Basic Authentication for the /EWS and /OAB folders in IIS Manager on each of the Client Access Servers.

At this point, iMExchange 2 should work great and all you have changed is that you are now publishing the /EWS and /OAB folders. They still require authentication, they are still protected via SSL, and Outlook Anywhere still will not work… leaving your end users’ and InfoSec needs satisfied.

Post Installation Script (Post_Install.bat) Template for Windows Server 2008 R2 Issuing CA

While implementing PKI at my current employer, I used the Microsoft Press books extensively to develop our implementation strategy. While doing so, I noticed that some of the scripts in the book had errors in them, so I ended up revising them to correct the errors and implement PKI with the policies we felt worked best in our environment.

The Post Installation Script below is specifically for an Issuing CA in a three tier hierarchy. With this policy, your Issuing CA will issue certificates lasting a maximum of 2 years and your CRL will be valid for up to three days (that should be updated automatically anyway). We did that in the CAPolicy.inf file as well, but this makes doubly sure that those settings were set.

Additionally, we are using this batch file to set publication points in Active Directory as well as on two web servers.

Change the areas in bold to fit your environment. After that, simply copy the text below into a file named Post_Install.bat and run it on your Issuing CA immediately after Active Directory Certificate Services role installation.


::Issuing CA Post Installation Script
::Declare Configuration NC
certutil -setreg CA\DSConfigDN CN=Configuration,DC=DOMAIN,DC=TLD

::Define CRL Publication Intervals
certutil -setreg CA\CRLPeriodUnits 3
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLOverlapUnits 4
certutil -setreg CA\CRLOverlapPeriod "Hours"
certutil -setreg CA\CRLDeltaPeriodUnits 12
certutil -setreg CA\CRLDeltaPeriod "Hours"

::Apply the required CDP Extension URLs
certutil -setreg CA\CRLPublicationURLs "65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n79:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n6:http://%%1/CertEnroll/%%3%%8%%9.crl\n6:http://WEBSERVER1/CertData/%%3%%8%%9.crl\n6:http://WEBSERVER2/CertData/%%3%%8%%9.crl"

::Apply the required AIA Extension URLs
certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n3:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n2:http://WEBSERVER1/CertData/%%1_%%3%%4.crt\n2:http://WEBSERVER2/CertData/%%1_%%3%%4.crt\n2:http://%%1/CertEnroll/%%1_%%3%%4.crt"

::Enable all auditing events for the Issuing CA
certutil -setreg CA\AuditFilter 127

:: Enable discrete signatures in issued certificates
Certutil –setreg CA\csp\DiscreteSignatureAlgorithm 1

::Set Maximum Validity Period for Issued Certificates
certutil -setreg CA\ValidityPeriodUnits 2
certutil -setreg CA\ValidityPeriod "Years"

::Restart Certificate Services
net stop certsvc & net start certsvc

Install Policy (CAPolicy.inf) Template for Windows Server 2008 R2 Issuing CA

While implementing PKI at my current employer, I used the Microsoft Press books extensively to develop our implementation strategy. While doing so, I noticed that some of the scripts in the book had errors in them, so I ended up revising them to correct the errors and implement PKI with the policies we felt worked best in our environment. For more complete information on the CAPolicy.inf file, see the excellent “Windows Server 2008 CAPolicy.inf Syntax” Microsoft blog post.

The Install Policy below is specifically for an Issuing CA in a three tier hierarchy. With this policy, your Issuing CA will issue certificates lasting up to 2 years and your CRL will need to be updated at least every three days (should be set to update automatically anyway).

Save the text below into a file named “CAPolicy.inf” and place it in C:\Windows prior to adding the Active Directory Certificate Services role on your Issuing CA.


[Version Issuing CAPolicy]
Signature="$Windows NT$"

[certsrv_server]
renewalkeylength=2048
RenewalValidityPeriodUnits=years
RenewalValidityPeriod=2

CRLPeriod=3
CRLPeriodUnits=days
CRLOverlapPeriod=4
CRLOverlapUnits=hours
CRLDeltaPeriod=12
CRLDeltaPeriodUnits=hours

AlternativeSignatureAlgorithm=1
LoadDefaultTemplates=0

How to Publish Root/Policy CAs in Active Directory

In order to get the Root and Policy CA’s CRT and CRL files published in Active Directory, you’ll need to run the following commands from a command line with elevated permissions. Make sure you either reference the directory in the file name or run the command from the directory where you have these files stored.

You should do this prior to setting up your Issuing CA, but it is not required if you manually add the CRT’s to the Issuing CA and have the CRL’s published in a location the Issuing CA can resolve.


certutil -dspublish -f "ROOTCA.crt" RootCA
certutil -dspublish -f "POLICYCA.crt" SubCA
certutil -dspublish -f "ROOTCA.crl"
certutil -dspublish -f "POLICYCA.crl"
gpupdate /force

Post Installation Script (Post_Install.bat) Template for Windows Server 2008 R2 Policy CA

While implementing PKI at my current employer, I used the Microsoft Press books extensively to develop our implementation strategy.  While doing so, I noticed that some of the scripts in the book had errors in them, so I ended up revising them to correct the errors and implement PKI with the policies we felt worked best in our environment.

The Post Installation Script below is specifically for a Policy CA in a three tier hierarchy.  With this policy, your Policy CA will issue a certificate to your Issuing CA lasting 5 years and you will only need to update your CRL once a year, allowing you to keep the Policy CA offline all but a few minutes a year.  We did that in the CAPolicy.inf file as well, but this makes doubly sure that those settings were set.

Additionally, we are using this batch file to set publication points in Active Directory as well as on two web servers.  Those web servers will be listed on the Root CA Certificate, but you will manually need to copy the CRL’s and CRT’s there from %SystemRoot%\System32\CertSrv\CertEnroll.  As your Policy CA should not be a member of the domain, you will also need to import the certificates into Active Directory.


::Policy CA Post Installation Script
::Declare Configuration NC
certutil -setreg CA\DSConfigDN CN=Configuration, DC=DOMAIN,DC=TLD

::Define CRL Publication Intervals
certutil -setreg CA\CRLPeriodUnits 52
certutil -setreg CA\CRLPeriod "Weeks"
certutil -setreg CA\CRLOverlapUnits 2
certutil -setreg CA\CRLOverlapPeriod "Weeks"
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod "Days"

::Apply the required CDP Extension URLs
certutil -setreg CA\CRLPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n10:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n2:http://WEBSERVER1/Certdata/%%3%%8%%9.crl\n2:http://WEBSERVER2/Certdata/%%3%%8%%9.crl"

::Apply the required AIA Extension URLs
certutil -setreg CA\CACertPublicationURLs  "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n2:http://WEBSERVER1/CertData/%%1_%%3%%4.crt\n2:http://WEBSERVER2/CertData/%%1_%%3%%4.crt"

::Enable all auditing events for the [CompanyName] Policy CA
certutil -setreg CA\AuditFilter 127

::Set Validity Period for Issued Certificates
certutil -setreg CA\ValidityPeriodUnits 5
certutil -setreg CA\ValidityPeriod "Years"

:: Enable discrete signatures in subordinate CA certificates
Certutil -setreg CA\csp\DiscreteSignatureAlgorithm 1

::Restart Certificate Services
net stop certsvc & net start certsvc

Copy the text below into a file named Post_Install.bat and run it on your Policy CA immediately after Active Directory Certificate Services role installation.

Install Policy (CAPolicy.inf) Template for Windows Server 2008 R2 Policy CA

While implementing PKI at my current employer, I used the Microsoft Press books extensively to develop our implementation strategy.  While doing so, I noticed that some of the scripts in the book had errors in them, so I ended up revising them to correct the errors and implement PKI with the policies we felt worked best in our environment.

The Install Policy below is specifically for a Policy CA in a three tier hierarchy.  With this policy, your Policy CA certificate will last 10 years and you will only need to update your CRL once a year, allowing you to keep the Policy CA offline all but a few minutes a year.

Since this is a Policy CA, we also include a link to the Certificate Practice Statement in the configuration.

Save the text below into a file named “CAPolicy.inf” (changing the items in bold to fit your environment) and place it in C:\Windows prior to adding the Active Directory Certificate Services role on your Policy CA.


[Version Intermediate CAPolicy]
Signature="$Windows NT$"

[PolicyStatementExtension]
Policies=[CompanyName]CPS

[[CompanyNameCPS]]
OID=1.3.6.1.4.1.311.509.3.1
NOTICE=[CompanyName]  Certificate Practice Statement
URL=http://WEBSERVER/Policies-Checklists-Procedures/

[certsrv_server]
RenewalKeyLength=2048
RenewalValidityPeriodUnits=10
RenewalValidityPeriod=years

CRLPeriod=weeks
CRLPeriodUnits=52
CRLOverlapPeriod=weeks
CRLOverlapUnits=2
CRLDeltaPeriodUnits=0
CRLDeltaPeriod=days

AlternativeSignatureAlgorithm=1