joeware - never stop exploring... :)

I was recently pinged by a friend who had some consultants in at his company and the consultants I guess were going on about how the domain is the security boundary and it is perfectly safe/acceptable to have a bunch of child domains that are run by disparate groups of admins.

THIS IS INCORRECT!

It has ALWAYS been incorrect.

I expect until there is a really major redesign of AD such as PKI signed updates, etc it WILL REMAIN incorrect.

You cannot, I repeat, cannot protect the forest from any administrator in any domain in the forest. You can think you can, and a lot of people think they can, I see it all the time. But just because you as a technical person can’t think of a way to compromise a forest, doesn’t mean someone else can’t. Do not justify bad security decisions with your own technical shortcomings.

   joe

Someone on ActiveDir Org (and actually the umich LDAP list) were asking about putting multivalued manager info into AD for dotted line reports. Active Directory’s manager attribute is single valued so this won’t work. You get one manager, have a nice day. 🙂

Well this someone wants MSFT to add this to their schema, it may happen, it may not happen. Not sure how likely it is to happen as this is the first time I have seen a request like that since 1999 so I am thinking MSFT isn’t being flooded by requests for this. Regardless, if they do, they will have to add new attributes because they won’t be able to modify manager to do this so might as well just add your own attributes.

While responding to the post I decided to help out and designed the required schema extensions and then donated part of my OID space and my joeware prefix for the two needed attributes and an auxiliary class that the attributes are assigned to. Then you can attach that aux class to some other structural classes statically (there is an example of attaching it to the Person class in the LDF file) or you can use the aux class dynamically and only use it on specific objects that need it.

So I decided to post the information and LDIF file here in case anyone else finds it useful. If you do find it useful and have thought, why didn’t MSFT do this, please comment. The MSFT DS PG folks swing by and read these entries occasionally and also if I get enough feedback I can always raise it with them as well.

Here is what the use of the attributes will look like if you go to enumerate the information on the user objects:

G:\new1\Dev\SCHEMA\DottedLine>adfind -h . -default -f objectcategory=person joeware-dottedmanagers joeware-dottedreports

AdFind V01.37.00cpp Joe Richards (joe@joeware.net) June 2007

Using server: sfmxp32.test.loc:389
Directory: Active Directory Application Mode
Base DN: CN=addressbook

dn:CN=someuser,CN=addressbook
>joeware-DottedReports: CN=testorgperson,CN=addressbook
>joeware-DottedManagers: CN=someuser3,CN=addressbook
>joeware-DottedManagers: CN=someuser2,CN=addressbook

dn:CN=someuser2,CN=addressbook
>joeware-DottedReports: CN=someuser,CN=addressbook

dn:CN=someuser3,CN=addressbook
>joeware-DottedReports: CN=someuser,CN=addressbook

dn:CN=testuser,CN=addressbook
>joeware-DottedReports: CN=testorgperson,CN=addressbook

dn:CN=testorgperson,CN=addressbook
>joeware-DottedReports: CN=testorgperson,CN=addressbook
>joeware-DottedManagers: CN=testorgperson,CN=addressbook
>joeware-DottedManagers: CN=testuser,CN=addressbook
>joeware-DottedManagers: CN=someuser,CN=addressbook

5 Objects returned

Here is the actual LDIF file to import (watch for line wrap). I have tried it with ADAM and Active Directory using the ADAM SP1 LDIFDE tool. It works great in both cases.

#==================================================================
#
# This file contains extensions for dotted line managers.
# It should be imported with the following command:
#   ldifde -i -f joeware-DottedLine.ldf -s server:port -b username domain password -k -j . -c “CN=Schema,CN=Configuration,DC=X” #schemaNamingContext
#
#==================================================================

# Attributes

dn: CN=joeware-DottedManagers,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: attributeSchema
attributeID: 1.2.840.113556.1.8000.1420.1.2.5000
attributeSyntax: 2.5.5.1
isSingleValued: FALSE
adminDisplayName: joeware-DottedManagers
adminDescription: joeware-DottedManagers
oMSyntax: 127
lDAPDisplayName: joeware-DottedManagers
systemOnly: FALSE
isMemberOfPartialAttributeSet: TRUE
linkid: 1.2.840.113556.1.2.50

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
–

dn: CN=joeware-DottedReports,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: attributeSchema
attributeID: 1.2.840.113556.1.8000.1420.1.2.5001
attributeSyntax: 2.5.5.1
isSingleValued: FALSE
adminDisplayName: joeware-DottedReports
adminDescription: joeware-DottedReports
oMSyntax: 127
lDAPDisplayName: joeware-DottedReports
systemOnly: TRUE
isMemberOfPartialAttributeSet: TRUE
linkid: joeware-DottedManagers

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
–

# Classes

dn: CN=joeware-DottedLine,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: classSchema
subClassOf: top
governsID: 1.2.840.113556.1.8000.1420.1.1.5000
systemMayContain: joeware-DottedManagers
systemMayContain: joeware-DottedReports
adminDisplayName: joeware-DottedLine
adminDescription: joeware-DottedLine
objectClassCategory: 3
lDAPDisplayName: joeware-DottedLine
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
–

#
# Update person class with static aux class
#    Remove REM chars (#) to complete
#

#dn: CN=Person,CN=Schema,CN=Configuration,DC=X
#changetype: ntdsschemamodify
#add: auxiliaryClass
#auxiliaryClass: joeware-DottedLine
#-

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

Back in May of last year I mentioned that Longhorn RODCs would have an issue with updating lastLogonTimeStamp. This was indeed the case at the time. I just wanted to revisit the topic and say that the DS team at MSFT realized that was a serious problem and put in some special functionality into Windows Server 2008 so that lastLogonTimeStamp does indeed get updated as it should even if you are logging into an RODC most of the time.

Thanks guys!

Also the first bullet I now believe to be wrong. It was about lastLogonTimeStamp only being updated if lastLogon was updated. I believe I have seen a case where lastLogon wasn’t updated by lastLogonTimeStamp was. I don’t recall the details, just recall seeing it and going… Hmmmm.