http://www.windowsitlibrary.com/Content/617/06/6.html
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al
Sent: Friday, September 10, 2004 4:38 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Fun with Kerberos
From: Guy Teverovsky [mailto:[EMAIL PROTECTED] On Behalf Of Guy Teverovsky
Sent: Thursday, September 09, 2004 8:26 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Fun with Kerberos
>sAMAccountName: guy
>userPrincipalName: [EMAIL PROTECTED]
>sAMAccountName: guysu
>userPrincipalName: [EMAIL PROTECTED]
Sent: Thu 9/9/2004 11:52 AM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Fun with Kerberos
that's correct - even if you configure an additional UPN suffix
for the
forest (or for an OU) and assign this to an account when you create
the
account (e.g. via ADUC), every account will still have an implicit
UPN
suffix that is made up of his samAccountName + the domain-suffix of
his
AD domain. So even though your first user had an explicit UPN
of
[EMAIL PROTECTED], he also had an implicit UPN of
[EMAIL PROTECTED]
Looks like the reason for your problem was mainly
caused due to the
special char in your ADM accounts (as it only used the
first part of the
name to create) - or did you configure your 2nd account
like this on
purpose? I assume that the accounts were created
programmatically, as
the ADUC UI will check for duplicate UPNs by querying a
GC - so usually
this is only a problem if accounts are created at roughly the
same time
on differnt DCs (even in different domains). But I'm not sure if
ADUC
only queries for the explicit UPN that you've assigned at creation
and
ignores the implicit UPN (seems to be the case). But I'm quite sure
that
this check is not performed when you programmatically add accounts
to
AD.
As a result the duplicate UPNs caused a Kerberos conflict as
you well
noticed - interesting to read how your users noticed this on their
XP
clients. Can you elaborate on the "Once in a while..." - i.e.
how
often? and did this only occurr if they were also logged on as
the
guy$adm at the same time?
And when did the 2nd account get
locked out - at the time the kerberos
ticket of #1 was getting refreshed
(i.e. after 10 hours past logon of
#1)? Or at logon of #1?
I'll have
to check out this sort of attack a little closer...
BTW - the same
risk applies with machine-accounts in AD, wich register
an SPN (service
principal name) that must also be unique: if they're
able to register the
same name as another machine (e.g. when DDNS is not
secured sufficiently
well), they can hinder both machines from receiving
kerberos tickets and (if
the "attacked" server was set to allow kerberos
delegation e.g. for some
web-application) could thus cause a DOS for
applications running on the other
server.
/Guido
-----Original Message-----
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of Guy Teverovsky
Sent: Thursday, September 09, 2004 6:22 AM
To:
[EMAIL PROTECTED]
Subject: [ActiveDir] Fun with
Kerberos
Stumbled upon an issue couple of days ago and wanted to hear
what you
guys think about it.
Suppose that your AD is called myad.com
and you also configure
additional UPN suffix "company.com".
Now I create 2
users in child.myad.com child domain:
1) sAMAccountName:
guy
userPrincipalName: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
2)
sAMAccountName: guy$adm
userPrincipalName: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
(Notice
that in ADUC the userPrincipalName is constructed from 2 fields:
W2K username
and suffix)
>From AD point of view this is all nice and legit and UI
will be happy
to create both.
But if you look at the users explicit
Kerberos principals, both look the
same:
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
(checked with klist
tgt).
In our environment, if you are logged on with
account #1, two things
happened:
1. Once in a while LAN users had XP pop
up a baloon in systrey with "XP
needs your user credentials"
2. The
corresponding account #2 was getting locked out.
Renaming UPNs of
supplemental accounts fixed the issue (the name clash
was not intentional
from the beginning as you might guess). Still I am
wondering why AD allowed
creation of account with Kerberos principal
that already existed in AD. If AD
check for sAMAccountName collisions,
is there any special reason not to check
Kerberos principals ?
How can I prevent this from happening ? (the
implications would mean
that anyone with permissions to create user accounts
can do some very
nasty things)
Guy
List info : http://www.activedir.org/mail_list.htm
List
FAQ : http://www.activedir.org/list_faq.htm
List
archive:
http://www.mail-archive.com/activedir%40mail.activedir.org/
List
info : http://www.activedir.org/mail_list.htm
List
FAQ : http://www.activedir.org/list_faq.htm
List
archive: http://www.mail-archive.com/activedir%40mail.activedir.org/