2

I am looking to implement a transparent plugin for Outlook that would need no configuration at all. I was thinking of maybe using Active Directory/Exchange to store each user's public key and be able to retrieve it the same way as Outlook retrieves user information.

I would like to avoid relying on an external key server or having to add more infrastructure in order to serve keys.

Is it possible to store PGP keys this way? What would be the easiest way to store them in order to retrieve them from an Outlook plugin?

Aki
  • 200
  • 1
  • 8
  • Do you already have a specific Outlook plugin, or are you just brainstorming ways to create your own Outlook plugin that doesn't exist yet? – Ryan Ries Jul 03 '14 at 04:35
  • @RyanRies: I was thinking of tuning google's. I am still brainstorming about this, if something good comes out of it I'll submit a patch. – Aki Jul 03 '14 at 06:21
  • Keyserver access using LDAP is (somewhat?) standardized. Have a look at [this GnuPG mailing list post](http://lists.gnupg.org/pipermail/gnupg-users/2006-February/028058.html) for some background. If I'm not totally mistaken, you should be able to query the Active Directory using LDAP and enhancing the underlying schema. – Jens Erat Jul 03 '14 at 07:57
  • @JensErat That would be great indeed. LDAP key servers for PGP is common but I couldn't find any material about practical usage with AD – Aki Jul 03 '14 at 09:09

1 Answers1

5

Yes, it is possible. But the only good way that I can think of to do it using Active Directory is to modify the AD schema. Modifying the AD schema is one of those things that administrators shy away from doing because one, it is basically irreversible (by "irreversible" I mean without an authoritative restore) and two, making irreversible changes to a production Active Directory scares many administrators. If you were making an application or plugin, you would have to consider that your software would not be used by as many organizations if it required AD schema modification.

But modifying the AD schema is not bad thing per se, as long as we have a good reason for doing it. Installing Microsoft Exchange, for example, extends the AD schema. A lot.

We know that Active Directory is plenty capable of and well suited to storing this kind of data (user's public keys) because it already stores the X509 public keys for users if you use a PKI. But I would definitely not try to commandeer one of those existing attributes like X509-Cert or User-Cert or thumbnailPhoto to stuff your own custom data into it. That would cause problems if your organization ever wanted to use a PKI or other products that assumed that those AD attributes held the actual kind of data that they were designed to store.

There are plenty of existing user attributes that you can sneak your data into if your data is a very small string... description, employeeID, telexNumber, etc. But there are not many attributes that are suitable for storing a kilobyte or more of data. And those are usually already spoken for.

Nevertheless you can take a gander here and see if you can find an attribute that already exists on each user account that might be able to hold PGP public keys and not interfere with other applications:

Probably best that you create your own.

First, open Registry Editor on your schema master and edit:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
    Schema Update Allowed (DWORD) 0x00000001

You do not have to reboot or even restart AD DS.

Next, register AD schema management snap-in:

regsvr32 schmmgmt.dll

Open MMC and add Active Directory schema snap-in.

Warning

You have to assign an X500 object OID to your new attribute that is based on your domain's OID. You can use this script to generate a new X500 OID for your new schema attribute:

New Attribute

Notice that it's a good idea to prefix all your related attributes with an identical prefix, such as "MyApp". For instance, all the Active Directory specific attributes have a prefix like "msDS" and DFS Replication specific attributes will have a "msDFSR" prefix, etc. All future attributes that you add that are relevant to this software will use the same prefix and the same OID prefix.

You probably do not want to index this attribute, as searching for a user who has a specific PGP public key does not sound like a common search to me. (You only index things if you want to use them as search terms.) Or you might want to replicate to the global catalog if you have multiple domains in your forest. Beware that this can cause your indices and GC replication traffic increase substantially if you have a large domain.

Next you want to assign the new attribute to the Person class:

Add to Person

Now if you go check the Attribute Editor tab on your users, you will see that they have a new attribute for you to edit and query.

Some follow-up homework for you:

  • Edit the default security on the attribute so that only account owners (and maybe Domain Admins) can update the attribute on their own account and no one else's. This way, you can have your Outlook plugin automatically upload the PGP public key for the user assuming that their Outlook client is running under their security context.

  • Use a different syntax for your attribute. The Unicode String syntax that I used in my example sucks for something like a PGP key, but I was too lazy to go back and repeat everything just for you. :)

Ryan Ries
  • 55,481
  • 10
  • 142
  • 199
  • This is great. Also great news as I can give it a shot soon (will update question accordingly). I will definitely follow up when I can spare some time to go further on my research. Now, what I want is to make this transparent for users, PGP is mostly useful when sending emails outside of the organization network (to meet security certifications with partners for instance). So I was thinking of adding also a private key field that would only be readable by the user himself (and of course our admins). Does that sounds feasible to you? This way he wouldn't be involved in managing keys at all. – Aki Jul 04 '14 at 00:23
  • 2
    You can technically use the `confidential` bit of the `searchFlags` attribute to "hide" data in Active Directory. Microsoft uses it in their credential roaming feature. But honestly... I'm starting to get squeamish now and I don't really recommend it. I consider Active Directory to be a *directory*, like a phone book, that is meant to *share* information, not hide it. All I'm trying to say is that technically, yes, the ability is there, but be very careful about trying to hide sensitive data in AD. – Ryan Ries Jul 04 '14 at 00:45
  • Look here for an example of Microsoft doing something like this: http://technet.microsoft.com/en-us/library/cc776299(v=WS.10).aspx – Ryan Ries Jul 04 '14 at 00:46
  • In the end, credentials are stored in AD, since the capability is here I think I will go for it. I don't see any alternatives, we won't provide training or do support for users messing with their private keys (they could leak them also). About your link: "Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2", so Windows Server 20008 R2 and above can't follow this, right? – Aki Jul 04 '14 at 01:31
  • 1
    @Aki Oh, that just means that the feature was *introduced* in 2003 SP1, but it still very much applies to 2008 R2, 2012, etc. I wish you luck. :) – Ryan Ries Jul 04 '14 at 01:52
  • +1 for the squimish about extending the schema. There is no undoing it, and breaking AD would make for a very bad day. But it is a valid thing to do, Microsoft apps do it all the time. – Grant Jul 04 '14 at 02:53