joeware - never stop exploring... :)

A pretty common issue out there in the real world is an error of something like

“There are multiple accounts with name XXX/YYYYYYYYYY of type DS_SERVICE_PRINCIPAL_NAME” or maybe that last bit is “of type 10”

floating about.

The general guidance is to find the objects with the same SPNs and clean all but one of them up. Some people get touchy about this because they think cleaning these dupes up will break kerberos… News flash if you are seeing these errors, Kerberos already is broken for those objects. Nuff said; clean them up.

Well then you get the folks who say “Well I searched like you told me to (or like KB321044 told me to) and I couldn’t find but the one object with that SPN set.”

The problem with this is that not all SPNs are explicitly registered in Active Directory. So the guidance from many people as well as from KB321044 is not altogether good enough. KB321044 hints to a solution for the problem but it is such an afterthought in the article most people blow right past it, specifically the line that says “Note If you do not receive the expected result, try searching for ” HOST/” as opposed to searching only for the exact SPN in the event ID.”

I think they should add a whole section to that KB concerning what I am about to write below, in fact, just append this blog article to any note or anything else you respond to when telling someone how to troubleshoot this. Think of this article as KB321044++…

So back to point… I said, and meant it when I said it, that not all SPN’s are explicitly registered in Active Directory. Microsoft did something that I personally think was very intelligent. They set up a bunch of SPN types that by default any HOST object can automatically be tied to even if they aren’t explicitly stated – i.e. these types will be mapped to HOST/whatever when they are encountered by AD. Currently in my Windows 2008 Test forest, that list of types that map to HOST is

• alerter
• appmgmt
• browser
• cifs
• cisvc
• clipsrv
• dcom
• dhcp
• dmserver
• dns
• dnscache
• eventlog
• eventsystem
• fax
• http
• ias
• iisadmin
• mcsvc
• messenger
• msdtc
• msiserver
• netdde
• netddedsm
• netlogon
• netman
• nmagent
• oakley
• plugplay
• policyagent
• protectedstorage
• rasman
• remoteaccess
• replicator
• rpc
• rpclocator
• rpcss
• rsvp
• samss
• scardsvr
• scesrv
• schedule
• scm
• seclogon
• snmp
• spooler
• tapisrv
• time
• trksvr
• trkwks
• ups
• w3svc
• wins
• www

That means if an application or machine asks for says CIFS/machinename or CIFS/machinename.domain.com Active Directory will look up that specified SPN but also HOST/machinename or HOST/machinename.domain.com. This is why Microsoft has that small note in the article… Because if the SPN has type of any of the above types, you very likely WON’T find the SPN by searching for the specific SPN specified in the event log entry.

You too can easily see which HOST mappings you have by running the following command with my very own AdFind command line tool

adfind -config -f spnmappings=* spnmappings

The output looks like this on my brand spanking new Windows Server 2008 Server…

C:\>adfind -config -f spnmappings=* spnmappings

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

Using server: TROUBLE-DC1.trouble.loc:389
Directory: Windows Longhorn
Base DN: CN=Configuration,DC=trouble,DC=loc

dn:CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=trouble,DC=loc
>sPNMappings: host=alerter,appmgmt,cisvc,clipsrv,browser,dhcp,dnscache,replicator,eventlog,eventsystem,policyagent,oakley,dmserver,dns,mcsvc,fax,msiserver,ias,messenger,netlogon,ne
tman,netdde,netddedsm,nmagent,plugplay,protectedstorage,rasman,rpclocator,rpc,rpcss,remoteaccess,rsvp,samss,scardsvr,scesrv,seclogon,scm,dcom,cifs,spooler,snmp,schedule,tapisrv,trk
svr,trkwks,ups,time,wins,www,http,w3svc,iisadmin,msdtc

1 Objects returned

Quick Note: To my friends at MSFT who I know for sure read the blog… Eric, Brett, Moon, Nathan, and others…. The name of the domain is indeed “Trouble”, this is not in any way shape or form a reference to Microsoft nor Windows Server 2008. Seriously. This is a reference to my black cat who was walking across my keyboard whapping me in the face with her tail as I made that domain and was thinking, what should this domain be named? <WHAP>

<…and we’re back>

So when you are looking for these duplicated, just expand the query to look for the specific SPN you want as well as the SPN with the type replaced with HOST. Actually Microsoft’s QuerySPN.VBS script should do exactly that but it doesn’t.

I say, don’t even bother with that script, don’t bother with LDIFDE (can ya say yuck?), and don’t even bother with LDP (even though it rocks in general); just use AdFind to go looking for these objects. Do something like

adfind -sc c:computername

Why will just looking for the computer name work? Because almost certainly (like 99.999% chance) the computer name is duplicated in your forest and even though you may not be using WINS (hahahahaha sure…), you still can’t duplicate machine names in a forest. They have to be unique so you can have unique SPNs for the short host name versions. For example, one of my Windows Server 2008 machines has the following SPNs

dn:CN=TROUBLE-DC1,OU=Domain Controllers,DC=trouble,DC=loc
>servicePrincipalName: E3514235-4B06-11D1-AB04-00C04FC2DCD2-ADAM/TROUBLE-DC1.trouble.loc:50000
>servicePrincipalName: E3514235-4B06-11D1-AB04-00C04FC2DCD2-ADAM/TROUBLE-DC1:50000
>servicePrincipalName: TERMSRV/TROUBLE-DC1
>servicePrincipalName: TERMSRV/TROUBLE-DC1.trouble.loc
>servicePrincipalName: NtFrs-88f5d2bd-b646-11d2-a6d3-00c04fc9b232/TROUBLE-DC1.trouble.loc
>servicePrincipalName: Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/TROUBLE-DC1.trouble.loc
>servicePrincipalName: GC/TROUBLE-DC1.trouble.loc/trouble.loc
>servicePrincipalName: HOST/TROUBLE-DC1.trouble.loc/TROUBLE
>servicePrincipalName: HOST/TROUBLE-DC1
>servicePrincipalName: HOST/TROUBLE-DC1.trouble.loc
>servicePrincipalName: HOST/TROUBLE-DC1.trouble.loc/trouble.loc
>servicePrincipalName: E3514235-4B06-11D1-AB04-00C04FC2DCD2/02cd7861-be73-4ef5-9892-fcd35231ac27/trouble.loc
>servicePrincipalName: ldap/02cd7861-be73-4ef5-9892-fcd35231ac27._msdcs.trouble.loc
>servicePrincipalName: ldap/TROUBLE-DC1.trouble.loc/TROUBLE
>servicePrincipalName: ldap/TROUBLE-DC1
>servicePrincipalName: ldap/TROUBLE-DC1.trouble.loc
>servicePrincipalName: ldap/TROUBLE-DC1.trouble.loc/trouble.loc

 

Notice that some of those SPNs do not have a FQDN in them… Specifically

>servicePrincipalName: TERMSRV/TROUBLE-DC1
>servicePrincipalName: HOST/TROUBLE-DC1
>servicePrincipalName: ldap/TROUBLE-DC1

These all would have collisions if you had the same machine name in two domains in the same forest. Hence any app that used them would fail to use kerberos for the authentication because AD cannot map the name to a unique object.

So anything else? I think not, this is good… What did we learn?

1. Don’t duplicate machine names in a forest, period.
2. If you have duplicate SPN issues, use AdFind to find all computers with the name in the SPN.
3. Duplicate SPNs means kerberos is already not working right for those machines so cleaning it up isn’t going to break anything worse.

 

    joe

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.