2003 SP1 - whats new? Digital Identity Management Service or (DIMS) !

  • Article

Continuing on my "neat SP1 list"....

There are a lot of new niftyola fixes\features, and one of them is the new Credential Roaming feature otherwise known as Digital Identity Management Service or (DIMS)

One note here - it does require a schema extension, but it does not require a particular Forest functional level or Domain functional level. On the client side - only Windows 2003 SP1 clients are supported. DIMS may be ported to W2k and XP but for now it is 2k3 Sp1 only.

1. The LDF file is on the link below - there is no LDF file in the service pack itself.

2. When you use the ldifde command to import you need to use the -c switch like so:

         ldifde -i -f dimsroam.ldf -c "DC=X" "DC=SPatsDomain,DC=com" -v

Where DC=SPatsDomain,DC=com is the name of my Forest.

Once you extended the schema and imported the ADM file (see the documentation) you can then manage your users via Group Policy.

NOTE: If you get some errors on ldif import or ADM import let me know - there were some problems with the first ones posted but they should be fixed.

So then the real question is.. What does all that stuff in the read box mean?

And why do we even care?

Lets tackle the second question first:

Anyone who has tried to manage crypto data for users on multiple machines, will appreciate this new feature.

In order to understand why, we need to discuss DPAPI – or the data protection API’s, a little bit.

<whirlwind tour>

When the User (via some application like EFS etc..) calls into the crypto subsystem to encrypt data the first time, we will create what is called a Master Key. This master key is used to create a session key which is used to encrypt the private data as a result of our call to CryptProtectData (for example). FYI the master key is encrypted via 3DES and a key derived from the users current password.

Now, we need some place to store this data and we chose to use the user’s profile. This is still secure since all the data is had via knowing the users password. It would be neat if we could use a smartcard to store it ..

Anyway, we will expire these Master keys and generate new ones every once in while – we never ever actually delete any of them or you would lose access to data encrypted (indirectly) via that particular Master Key.

</whirlwind tour>

Lets take an common scenario for EFS.

Bob uses EFS to encrypt confidential data on MachineA. The public key of the EFS cert is used to encrypt the data (actually the FEK) and then when he needs to decrypt the encrypted file we pull out our private key (which was indirectly encrypted via the users local master key) , decrypt the FEK, use that to decrypt the file and we are good to go. Keep in mind that the users keys (Master , cert keys etc..) are local to that machine.

Now, he logs on to machine #2 and encrypts some data – he gets a NEW master key, new cert and a whole new profile to manage and make sure nothing happens to, or he loses access to his data forever (we wont touch the DRA or KRA stuff here)

There are also more complex scenarios, like shared encrypted files between users, or remote EFS.

How would one prevent this? Well - before SP1 and DIMS one would have to use roaming profiles - but not anymore :o)

If he had had a roaming profile, then EFS would have used the same set of keys on both machine and we would be OK. But, many companies don’t use roaming profiles and honestly don’t even think of this scenario as a reason to start using them. Plus roaming profiles can create their own set of problems we won’t even get into.

So with this new feature called DIMS - our keys roam with the user.. this is great!

 

Lets look at some of the data we added to our schema and how it relates to what we have discussed.

NEW AD ATTRIBUTES:

  • ms-PKI-DPAPIMasterKey. This multivalued attribute contains master key files and information for DPAPI. The following objects will be roamed and contained within this attribute:

• All master key files. There can be multiple master key files. New master key files can be created every 90 days by the domain. Master key files must be maintained and roamed in perpetuity.

                  • The Preferred file that specifies the master key to be used for encryption. This attribute is updated every time a new master key is created.

 

  •  ms-PKI-AccountCredentials. This multivalued attribute contains binary blobs of encrypted credential objects from the Credential Manager store, private keys, certificates and requests. Each binary blob stored in Active Directory may contain a delete flag with a timestamp that persists for 60 days to ensure that all clients delete the object.

 

  •  ms-PKI-RoamingTimeStamp. This attribute is used by DIMS and credential roaming to record the time of the latest change to the user object in Active Directory.

Looking over this post, it is a bit long winded and I don’t have time to hit it all today.. so I’ll have to continue this in another post.

Until then – take a look at SP1 and https://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/633d4258-557a-4bfc-86e1-bb30265f52b4.mspx

Spat