June 2006

The OpenSSL toolkit is a veritable Swiss Army knife of SSL functionality.  Among the many, many things that can be done using OpenSSL is converting SSL certificates between formats.  This is particularly helpful in a heterogeneous environment where different platforms may require SSL certificates to be in different formats.

A mixed Windows-Linux shop is one excellent example.  Windows typically requires certificates in PFX format; Linux, on the other hand, typically needs PEM format.  (See this X.509 article for more information on the PFX and PEM formats.)  Using the OpenSSL toolkit, we can pretty easily convert certificates from PFX to PEM.  Here’s how.

Before we begin, we’ll need to make sure we have the certificate in PFX format with the private key.  In organizations that use the Windows Certificate Services as a CA, we can use the Certificates MMC snap-in to export the certificate and the corresponding private key to a PFX file.  During this process, we’ll be prompted for a passphrase; make note of it, as we’ll need it later in the process.

With our PFX file in hand, we start the conversion process:

1. At a command-line prompt, type “openssl pkcs12 –in pfxfilename.pfx –out tempfile.pem”. This will convert the PFX file to a PEM file. The OpenSSL toolkit will prompt for the import passphrase; this will be the passphrase for the PFX file when the certificate and private key were exported (as mentioned above). OpenSSL will prompt for a new PEM passphrase; be sure to make note of this information as well.
2. Using a text editor, split the PEM file into two separate files, one containing the certificate and one containing the encrypted private key.  Remove all extra text from these files outside the lines with the dashes.
3. Because many Linux-based applications will need the private key decrypted (or they will prompt for the passphrase during service start), we’ll decrypt the private key.  To decrypt the private key, use the command “openssl rsa –in encryptedkey –out decryptedkey” (where encryptedkey is the file containing the RSA private key, as separated above, and decryptedkey is the file that will contain the decrypted RSA private key). The OpenSSL toolkit will prompt for the RSA key passphrase; this will be the PEM passphrase we specified when we first converted the certificate to PEM format above.
4. If the application can use the certificate and the key in separate files, then we’re finished.  If we need to put them back into the same file, then use the command “cat decryptedkey certificatefile > finalfile.pem” (on Mac OS X or Linux) or the command “copy /b decryptedkey+certificatefile finalfile.pem” (on Windows).  This will combine the certificate and the decrypted private key into a single file.  Using a text editor, add a blank line between the decrypted RSA private key and the certificate, and a blank line after the end of the certificate.

The final file is now ready for use with any number of Linux-based applications, such as Stunnel, Apache, Postfix, or others.

UPDATE:  It turns out this is a duplicate post, originally covered earlier here.  Sorry!

As of last night, I’ve moved this weblog to a new host.  Now that I’m not running my own business anymore (I went to work for ePlus Technology a few months ago), it didn’t really make sense for me to have all this equipment (including the server that was running this weblog).  I couldn’t really justify paying for Internet service with a static IP address and hosting all my own equipment at home.  In addition, maintaining that equipment and the operating system(s) was starting to become difficult since I was no longer working from home and working at an office instead.

All the domains, web sites, and e-mail services that I formerly managed myself have been transitioned to Bluehost.com (or are—ahem—in the process of being transitioned).  I still have a few little minor issues to address, mainly the result of some sort of disconnect between the Bluehost sales team and the Bluehost technical team.  Hopefully, I’ll have that sorted out shortly.

My own personal network at home is being dismantled and reorganized.  When that’s all said and done, I’ll probably end up with only a single server (most likely Linux-based) acting as some sort of media server for the house, so that the kids can listen to music and watch movies and stuff.  You know, the important things.

A third Excel flaw has been uncovered in a week, giving Excel users one more thing to worry about and opening one more door for hackers to get into corporate networks.

Here are more details on the third flaw; more details on the second flaw are also available from this article.  This posting also has additional information on the latest vulnerability.

Unfortunately, this new flaw is more critical than the second flaw discovered earlier in the week.  The second flaw required the user to click a specially-crafted hyperlink inside an Excel document, and the latest version of Excel even displayed a dialog box that had to be dismissed after clicking the link.  This new flaw, however, only requires that the user open the Excel document.

These new flaws underscore the need for users to be very wary of unsolicited Office attachments.  If you didn’t ask for it, it very well may be a malicious attachment—exercise caution.

In addition, the recent flaw in Microsoft Word and these flaws in Microsoft Excel have contributed to the placement of Microsoft Office on the SANS Top 20 list of vulnerabilities.

UPDATE:  In following up on these reports, I came across a few additional links with more information on the vulnerabilities, including information that proof-of-concept code to exploit the second Excel vulnerability was available:

Notice of exploit code availability:  http://www.eweek.com/article2/0,1759,1979409,00.asp
Secunia advisory on the second Excel flaw:  http://secunia.com/advisories/20748/
MSRC response to the second Excel flaw:  http://blogs.technet.com/msrc/archive/2006/06/20/437826.aspx
US-CERT Vulnerability Note on the second Excel flaw:  http://www.kb.cert.org/vuls/id/394444

It’s a fairly well-known fact that universal group membership in Active Directory is replicated among all Global Catalog (GC) servers.  That is, when the membership of a universal group changes, that change must be replicated to all GC servers in the forest.  In Windows 2000, a change to universal group membership replicated the entire membership again; in Windows Server 2003, only the changes are replicated.  Even though Windows Server 2003 reduces the load for replicating universal group membership, it’s still considered a best practice to keep universal group membership fairly static and to use global groups instead of users.  But how does an administrator check that?  In large organizations, it’s easy to lose control of universal groups and their memberships, especially when delegations have been performed to allow another group to handle group memberships.  Fortunately, the directory service command line tools provide the functionality necessary to make this a relatively easy task even in large distributed enterprises.

There are two components here.  First, we must find all the universal groups.  That in itself can be a fairly daunting task since the number of groups in an Active Directory deployment grows very large as the size of the company increases.  Considering that groups, particularly security groups, are the fundamental building block of Windows security, it’s easy to see how organizations can quickly end up with hundreds, perhaps thousands, of groups.  So we must first find a way to sift through all the groups and find only the universal groups.

Second, we need to enumerate the membership of those universal groups so that we can see who or what has been placed into the membership of the groups.  If the members are only other groups, all is well; if there are users as members, that needs to be documented and noted.  There very well may be valid business reasons why a user and not a group is placed into a universal group—that’s fine.  Just document it for future reference.  What we want to avoid is allowing the membership of the universal group to become too dynamic, as that will have an adverse impact on Active Directory replication.

Finding all the Universal Groups

To find all the universal groups, we turn to the “dsquery *” command.  The “dsquery group” command won’t work here because it has no way of specifying to list/find only universal groups.  Instead, we’ll use a generic LDAP query with the “dsquery *” command to find universal groups.

But how exactly do we identify universal groups?  Kudos to Microsoft’s Scripting Guy for providing the method to identify universal groups.  Based on that information (follow the link and read the article real quick, then come back), we come up with this command:

dsquery * “dc=example,dc=net” -scope subtree
-filter “(&(objectCategory=group)(groupType=-2147483640))”

This command will return the DN of all universal groups.  Note that it may be necessary to add a “-limit” parameter to allow the dsquery statement to return all of the universal groups (the default is 100, if I recall correctly).

Enumerating Membership in Universal Groups

Now that we have the DNs for the universal groups, we can use the “dsget group” command to show the membership for those groups, like so:

dsquery * “dc=example,dc=net” -scope subtree
-filter “(&(objectCategory=group)(groupType=-2147483640))” |
dsget group -members

This will return the membership of each of the universal groups.  It may be helpful to redirect the output to a text file for future storage or additional manipulation.

One problem with this method is that it doesn’t like the universal group name along with the membership.  I haven’t quite figured out how to do that with the directory service command-line tools just yet…but give me some time.

I’d previously published information on making bulk changes in Active Directory, but those changes previously involved changing one attribute to the same value for all the accounts.  For example, earlier I described how to make mass password changes using dsquery and dsmod.  But what about those situations where simple piping of output doesn’t work, like when multiple attributes need to be changed?  Here’s one technique.

I needed to create this process for a project I was working on.  In this project, we needed to be able to set the User Principal Name (UPN) in Active Directory.  We couldn’t just use dsquery and dsmod here, since dsmod can only accept a DN on standard input; how would we get the UPN value into the command?  There was no way to pipe both values from dsquery to dsmod.  A more elegant solution was going to be required.

After a fair amount of trial and error, I finally found this solution.  Hopefully, it will prove useful to someone.

Exporting the Data from Active Directory

First, we need to get some raw data to work with.  In this scenario, we’re going to set the UPN for a group of user accounts in the same OU to match their primary e-mail address.

To get the information we need to accomplish that, we’ll first use CSVDE to export information from Active Directory in CSV (comma-separated values) format:

csvde -f c:\output.csv
-d “ou=Users,ou=Atlanta,ou=Locations,dc=example,dc=net”
-r “(objectclass=user)” -l dn,mail

Be sure to type this command all on a single line, not wrapped as it is displayed here.  This exports only the DN and mail attributes (as specified by the -l switch) for users in the Locations/Atlanta/Users OU to a file named output.csv.

Now we have the raw data we need, so we move on to the next step.

Manipulating the Data

The problem we face is that we can only use CSVDE to add new objects, not to modify existing objects.  That’s not what we need, so we need to convert the CSV data we have into something else.  I experimented with a number of CSV-to-LDIF converters, especially this one from Novell, but couldn’t get them to work correctly.  Finally, I found Log Parser.

If you’ve never heard of Log Parser, take a break right now and visit the unofficial Log Parser support site to find out more about the program and what it can do.

Done now?  OK, good.  We’re going to use Log Parser to read in our CSV output and place the fields into a template file that we will create.  That template file can then be fed to LDIFDE for import into Active Directory.

Here’s the template file that I used:

<LPBODY>
dn: %FIELD_3%
changetype: modify
replace: userPrincipalName
userPrincipalName: %FIELD_4%
-
</LPBODY>

In this template, %FIELD_3% and %FIELD_4% represent the third and fourth fields in the CSV file.  This confused me at first, since the CSV output has only two fields, but the difference is in how Log Parser generates the output.  Save this file (make note of the filename!) and then we’re ready to proceed.  For the purposes of this article, I’ll assume we used the name “template.tpl”.  By the way, if you leave the “header line” in the CSVDE output, you can use the “friendly” field name in the template instead of the more generic %FIELD_3%.

Use this command to convert our CSV output into LDIF format for modifying Active Directory:

type c:\output.csv |
logparser “SELECT * FROM STDIN”
-i:CSV -o:tpl -tpl:c:\template.tpl -q:on -stats:off >
c:\output.ldf

This command selects all fields from standard input (which is being piped to Log Parser by the type command) and places them into the template file (using the placeholders described earlier), then redirecting the output to a file named output.ldf.

The results of the file will look something like this:

dn: CN=Bob Smith,OU=Users,OU=Atlanta,OU=Locations,DC=example,DC=net
changetype: modify
replace: userPrincipalName
userPrincipalName: Bob.Smith@atlanta.example.net
-

The dash is important, by the way.  Refer to this Microsoft article for more information and examples on using LDIFDE to modify Active Directory.

Importing the Data Back Into Active Directory

Now, with our freshly created output.ldf file ready, we can import the data back into Active Directory to make the desired changes:

ldifde -i -f c:\output.ldf

This will import the LDIF file back into Active Directory and make the requested changes.  Be sure to use the -j switch if logs of the changes are needed; otherwise, no logging is performed.

While this is a fairly simple example, the procedure easily lends itself to making multiple changes to large numbers of user accounts.  In this procedure, Log Parser is the key; this is what allows us to take information from Active Directory (obtained using dsquery, csvde, or other utilities) and manipulate it so as to be importable back into Active Directory.

Now that I’ve discovered Log Parser, I hope to be able to find more ways to use this extremely powerful tool.  Look for more Log Parser-related articles soon.

UPDATE:  I modified the article to properly render the percent signs above, as well as removing the reference to delete the header line (leaving the header line in the CSVDE output allows you to specify friendly field names in the Log Parser template file).  In addition, I added the switches to Log Parser to use quiet output and not display statistics; this keeps us from having to edit the Log Parser output before importing it back into Active Directory.  Finally, I published a follow-up article that provides some additional information as well.

Less than a month after the disclosure of a zero-day exploit in Microsoft Word, another zero-day exploit has been found in Microsoft Excel and is being exploited in a highly targeted attack.  As with the Word vulnerability, this one has shown up in attacks against a single customer, but it has gotten the attention of many of the major security vendors.

Brought to my attention by this eWeek article and this posting on Thincomputing.net, the Excel exploit has been disclosed by Microsoft on the Microsoft Security Response Center weblog.  From the specific post on the MSRC for this exploit:

In order for this attack to be carried out, a user must first open a malicious Excel document that is sent as an email attachment or otherwise provided to them by an attacker.

So, security best practices will protect you—just don’t open unsolicited attachments via e-mail.  If the e-mail claims to be from someone you know, contact them directly and see if they sent the message to you.  If they don’t know what you’re talking about, then the message sender is most likely spoofed (faked) and can’t be trusted.

Additional information on protecting yourself against this vulnerability is available in this just-released Microsoft security bulletin.

Note also that Secunia has posted an advisory on this issue as well.  All the major anti-virus vendors are also stating that their signatures have been updated to watch out for malicious Excel files containing the exploit.  However, this attack may morph or mutate in the future, easily bypassing simple signature-based detection, so I wouldn’t count on this as your only layer of protection.

On a slightly related note, this article at Darkreading.com points out that exploits and/or exploit code already exist for almost one-third of the exploits patched in the latest round of Microsoft patches.  This underscores the need for organizations to remain as current as possible with security patches, since it now appears that many malicious entities are reverse-engineering the patch to create a virus or worm.  This approach seems to work well, too, since most organizations don’t stay on top of patches.

I wrote a short while ago about the fact that Microsoft’s Windows Genuine Advantage tool is phoning home on a regular basis (daily, in fact).  This issue has garnered more attention over the last week or so, and very smart people are tackling the issue.

These two articles, Big Brother Microsoft and Big Brother Microsoft is Snooper Than I Thought, were written following my original posting and include more information about the information disclosed to Microsoft.  Then, Pamela Jones of Groklaw got into the discussion with her article, Microsoft’s Calling Home Problem: It’s a Matter of Informed Consent, in which she carefully and meticulously looks at the issues, the EULAs (or lack thereof), and the timing of those EULAs.  Her conclusion?

Microsoft has now put out a statement, asserting that the Windows Genuine Advantage tool is not spyware, that they’re going to change it some, and that one thing that distinguishes it from spyware is that they get consent before installing it. I question the accuracy of the statement.

She proceeds to back that up with a detailed analysis of the EULAs (End User License Agreements), when EULAs are even presented to the user.  I’m no lawyer, but her discussion and analysis of the matter is detailed and fascinating to read.  Even if you disagree with Microsoft’s handling of this situation, I encourage you to read the entire article so that you have a good feel for the principles that are involved.

While performing some testing and research at the office today, I found myself in need of a way to mass-create some Exchange mailboxes.  A very quick Google search revealed just the tool I needed to perform the task:  ExchMbx, a freeware utility by the same author of AdFind and AdMod.

The real power of ExchMbx is demonstrated when combined with Dsquery (a Microsoft-supplied command-line tool for pulling lists of objects from Active Directory) or AdFind.  In these examples I’m using AdFind because tools such as Dsquery don’t work on Windows 2000 (at least, not in my experience).

So, let’s say you wanted to mailbox-enable all the users in a particular OU.  With AdFind, you could enumerate all the users in an OU like this:

adfind -dsq -b “OU=Users,OU=Department,DC=example,DC=net”
-f “(objectclass=user)”

(Be sure to type commands like this on a single line, not broken across lines for appearance’s sake as shown here.)

This will produce a quoted DN listed similar to the output of Dsquery (hence the “-dsq” switch).  Then, this output can be fed to ExchMbx:

adfind -dsq -b “OU=Users,OU=Location,DC=example,DC=net”
-f “(objectclass=user)” | exchmbx -cr “SERVER1:First Storage
Group:Mailbox Store (SERVER1)”

Here, the DN output from AdFind is piped to ExchMbx to create a mailbox on the database named “Mailbox Store (SERVER1)” in the First Storage Group on SERVER1.

Or, you could move all the user objects for the HR personnel to a new Exchange server or database:

adfind -dsq -b “OU=Users,OU=Location,DC=example,DC=net”
-f “(&(objectclass=user)(department=HR))” |
exchmbx -move “SERVER1:First Storage Group:Second Database”

To find which accounts don’t have an Exchange mailbox (perhaps you only created Exchange mailboxes for a subset of your users), this command will help you out:

adfind -dsq -b “ou=RTP,dc=legacyad,dc=net”
-f “(&(objectclass=user)(!(homeMDB=*)))”

You could then pipe this to ExchMbx again to create mailboxes, repeating the process until the AdFind command did not find any more accounts out there without mailboxes.

Of course, there’s a lot more to ExchMbx than just creating and moving mailboxes; you can also mail-enable objects, hide or unhide objects from address lists, and set mailbox quotas.  All in all, a very handy tool!

Due to the changes to the site I described earlier, there are some changes ahead in how posts will be categorized and tagged.  Because Ultimate Tag Warrior now causes WordPress to include the tags as well as the category in the RSS feed (to properly link up with Technorati), I will be removing tags that duplicate the category and instead using tags that are more specific, where possible.

For example, posts placed into the Microsoft category won’t have the Microsoft tag also assigned to them; otherwise, the feed shows two entries for Microsoft—one for the category, and one for the tag.  Likewise, posts categorized into Security won’t be tagged Security as well; instead, I’ll break down the tags into Patches, Vulnerabilities, Exploits, etc.  I haven’t come up with the specific tags that I’ll use just yet, but I do want to continue to try to keep the tags I’m using here consistent with the tags I’m using on del.icio.us.

UPDATE:  I started to go back and update some of the older articles with this scheme, and then I realized that if I don’t tag the article with the same tag as the category, then site visitors can’t search for related weblog entries or bookmarks with those tags.  So, I’ve decided to leave the tags as they are and not worry about duplicate tags/categories.

I’ve updated the site to use a tagging plugin called Ultimate Tag Warrior.  It’s taken some time to get things working the way I’d like, but it’s working now and I’m really pleased with how things have turned out.  Read on for more details.

I had been using ecto (my Mac OS X-based blogging client) to add Technorati-specific tags to my posts.  This was all well and good, but these tags were not getting added to my RSS feeds and therefore weren’t getting picked up fully by Technorati, even though I was pinging Technorati every time I published an entry.

In searching for an answer, I came across this plug-in.  Additional research showed me to how make ecto work more fully with this plugin by placing tags in the keywords for the post; those instructions can be found here and here.  It was bit unnerving to be editing the xmlrpc.php file, but everything seems to work just fine now, and ecto happily places the tags in the keywords as it is supposed to.

In addition, this plugin gives me the ability to automatically generate site search tags (the current type being displayed, which merely show all other posts tagged the same way), Technorati tags, and del.icio.us tags, among others.  I haven’t enabled those yet, but probably will soon.  You can also display related tags (I am).  Finally, RSS feeds are exposed for tags as well, so that visitors can follow a feed for articles tagged a certain way.  There is a great deal of functionality to this plugin; I heartily recommend it to fellow WordPress users.

I still have a few clean-up items to do (fix-up older blog posts and resolve one niggling issue with a trailing slash when using site search tags), but otherwise it is working perfectly.  I hope the new functionality is useful to you!