2003 SP1 Digital Identity Management Service - DIMS continued.

 So when we left off, we were talking about DIMS as a new feature for 2003 SP1. The overview was brief , so here are some details.

1.  DIMS takes advantage of another new feature in SP1 for confidential attributes, actually this attribute feature was added specifically for DIMS. (Ill blog more about this later perhaps)

Rundown on confidential attributes:

1. Add or determine the attribute you want to mark confidential (Base Schema objects cannot be marked confidential)

2. Mark the attribute "confidential" by modifying the searchFlags attribute of the object in the schema. SearchFlags contains multiple bits representing various properties of an attribute. E.g. bit 1 means that the attribute is indexed. The new value128 (bit 7) designates the attribute as confidential. Note you cannot set this flag on base-schema attributes (such as common-name). See https://msdn.microsoft.com/library/default.asp?url=/library/en-us/adschema/adschema/a_searchflags.asp for more info on search flags

3. Grant the users who need to view the attribute’s value CONTROL_ACCESS on the specific objects they need to view. By default administrators have CONTROL_ACCESS

 

 

   2. DIMS will roam all DPAPI keys for a user from any machine s\he logs in to.

3. DIMS is configurable via the GPO ( it’s a per user GPO) and the ADM template we discussed last time, but you can set the reg values independent if desired.
 

General configuration:

1. Import the ldifde script.

NOTE: You will need to change the ldif file a little bit, the one on the web (to the best of my knowledge) is incorrect. You need to add a “-“ so the very last few lines should look like this:

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

 

   2. Import the ADM file:

NOTE: you will need to edit the ADM a little as well. Change the lines which contain DIMSCredentialRoamnig to DIMSCredentialRoaming.

 

   3. Edit the ACLS on the user or the Parent to inherit ACLS as follows

 

            Ace[39]

                        Ace Type: 0x5 - ACCESS_ALLOWED_OBJECT_ACE_TYPE
Ace Size: 40 bytes
Ace Flags: 0x12
CONTAINER_INHERIT_ACE
INHERITED_ACE
Object Ace Mask: 0x00000130
ACTRL_DS_READ_PROP
ACTRL_DS_WRITE_PROP
ACTRL_DS_CONTROL_ACCESS
Object Ace Flags: 0x1
ACE_OBJECT_TYPE_PRESENT
Object Ace Type: Private Information - 91e647de-d96f-4b70-9557-d63ff4f3ccd8
Object Ace Sid: NT AUTHORITY\SELF S-1-5-10

GPO SETTINGS:

 

NOTE: Updated May 24 2006

Due to changes in the ADM downloadable online - you may not see the same settings available in your GPO.

 

"Roam all x509 certificates and keys" – does what is implied. All certificates, private keys, and requests from the user stores will roam.

 "Roam encryption certificates and keys only" - will NOT roam signature certs\keys

 Strict arbitration

 Scenario:

1. User Joe logs on to Machine1 has a cert which is password protected and is exportable.
2. User Joe exports the key from Machine1 and imports it to Machine2 – when he imports it he clicks thru the import wizard and the cert on Machine2 is now NOT password protected and NOT exportable.
3. DIMS is enabled on the domain for this user.
4. User is on Machine1 and via winlogon (user logs off and on etc..see HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify\dimsntfy) notification, DIMS kicks off and and the keys\certs etc.. are roamed to the AD (net store)
5. The next day user Joe then logs on to Machine2 and DIMS kicks in for the user on this machine.
6. DIMS sees the data from the Net Store is the same key \ cert data as the Local Store – but there are differences in the extended properties.
7. How do we reconcile this situation? In our scenario – and a strict GPO setting - we would keep the local data as NOT exportable and NOT password protected.

The data in the Net Store would be overwritten with this new data and next time he logs on the Machine1 – he would find the cert is not exportable and not pass protected.

The matrix below breaks it down – we denote EXPORTABLE as E, and USER_PROTECTED as P. /E and /P are their opposites.

The winner arbitration matrices are:

 

 

Ill talk about the tombstone and max settings in another post as I need to run today.. its Friday!! :)

 

spat

Comments

• Anonymous
  May 24, 2006
  Article is not available yet - but if you ask PSS for 907247 - that's the ticket in.
  If you need some...

• Anonymous
  August 01, 2006
    3.   Edit the ACLS on the user or the Parent to inherit ACLS as follows??  
  Help.  I have everything done but this step.  Not sure what I need to do here.
  
  

• Anonymous
  August 16, 2006
  Works as advertised.  Thanks for your help Steve.  One caveat.  In order to get the ACLS settings to flow down, I had to check the "inherit permissions from parent" on all of the user objects who were once a member of a built in priveleged group, such as Domain Admins,backup operators etc.  

• Anonymous
  August 27, 2006
  Thank you Chris, Im sorry I couldnt have helped more - but I weas on vacation.  Im really glad you got it working.

• Anonymous
  November 03, 2006
  this has been extremely helpfull. One thing i did not see mentioned is if sLDAP has be enabled on all AD servers for the process to work. The MS info talks about Kerberos and secure LDAP to protect key transfers. Does every DC has to be enabled for sLDAP before this works? Still unclear on the ACL's piece also

• Anonymous
  November 11, 2006
  I will post another entry on DIMS end to end and tshooting soon. As far as LDAPS - it is not needed for DIMS.

• Anonymous
  April 14, 2007
  Arrg - I'm stuck! I have everything setup. The default "administrator" account has copied it's certs to AD just fine. All the other accounts have sent NADA. I know it has to do with the ACLS settings, but I can put my finger on it... A good step by step on the ACLs would be a big help

• Anonymous
  April 14, 2007
  The comment has been removed

• Anonymous
  April 15, 2007
  The comment has been removed