RE: [ActiveDir] Fun with Kerberos
I have been trying to reproduce the behavior in our test forest, but meanwhile in vain. I can only speculate that you need more than one DC on site (at least 1 DC and 1 GC maybe ?). In any case, meanwhile another issue popped up and it looks like it might be related. As I have already mentioned, we have 2 forest in our environment: 1) myad.com (empty root + domains: child.myad.com, anotherchild.myad.com) 2) rd.company.com (well yes, we are RD and have to be special :-) ) For myad.com we have alternative UPN suffix in the form of company.com == my account in child.myad.com would be [EMAIL PROTECTED] The rd.company forest is resource forest: all user accounts are located in child domains of myad.com forest. Now user CHILD\guy (Kerberos principal: [EMAIL PROTECTED]) logs on to host mycomp01.rd.company.com (the host is in rd.company.com forest) using UPN ([EMAIL PROTECTED]) The trust is one-way forest trust. Now user guy decides to change his password, hits ALT+CTRL+DEL, fills in his UPN, types the new password, hits Enter, and The system can not change your password now because domain is not available. OK... I do some searching and come up with this KB: Cannot Change Password if You Use the UPN Suffix: http://support.microsoft.com/default.aspx?scid=kb;en-us;321074 http://support.microsoft.com/default.aspx?scid=kb;en-us;321074 The cause is, I quote: This behavior may occur when the built-in Authenticated Users group was removed from the organizational unit where the user account resides. By default, the computer account is a member of the Authenticated Users group. If you use the Change Password dialog box, the local computer account is used to resolve the UPN. If the Authenticated Users group was removed from the organizational unit that contains the user account, you cannot successfully change the password. ok... this makes sense... but there is a slight problem: This is one-way trust and the computer account can not have access to the OU the user accounts are located in even if Authenticated users group has read access - this is Authenticated Users group from the wrong forest ! I guess the answer would still be the behavior is by design, but this is rather confusing for the users - object picker wants Kerberos principals in W2K, if you logon using DOMAIN\Username you end up with messed up cached credentials, UPN almost works, but you can't change your password using UPN and the list goes on... We have started to document what actions can be done using UPN, explicit Kerb principal and DOMAIN\username and we can't figure out a rule of thumb that can work for the end-users. Ideas ? Guy From: [EMAIL PROTECTED] on behalf of Grillenmeier, Guido Sent: Fri 9/10/2004 6:10 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Fun with Kerberos Al, realize that the user accounts Guy is talking about are all in one forest - so the issue is not related to UPNs being unique accross more than one forest. They're just logging in from a machine in a different forest. I've already discussed offline with Guy that the clash is between the implicit UPN of the regular account (which would be [EMAIL PROTECTED]) and the explicit UPN of the supplemental account (which had previously been set to [EMAIL PROTECTED]) = fixing the explicit UPN of the supplemental account fixed the clash and the related problems... BTW, we're thinking that the account lockouts and the XP request for credentials is likely related to Kerberos preauthentication. During preauth, AD looks up accounts using the UPN - so if it hits the wrong account, and uses the wrong password hash for validation of the Kerberos preauth data this may have the same effect as logging on with the wrong password. Here's a nice article that explains Kerberos preauthentication in more detail http://www.windowsitlibrary.com/Content/617/06/6.html http://www.windowsitlibrary.com/Content/617/06/6.html /Guido 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 No, that sounds about right. Across two forests? Be tough for any administrative program to enforce uniqueness unless it was authoritative for both forests. That said, that's something you want your admin processes to compensate for and ensure that all accounts are unique across forests that can talk to each other. Al 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 ok... this starts to be more interesting. If the implicit UPN is constructed from samaccountname and AD DNS name, I do not see how Kerberos principals could clash. This is what I initially had (names changed to protect
RE: [ActiveDir] Fun with Kerberos
Title: RE: [ActiveDir] Fun with Kerberos No, that sounds about right. Across two forests? Be tough for any administrative program to enforce uniqueness unless it was authoritative for both forests. That said, that's something you want your admin processes to compensate for and ensure that all accounts are unique across forests that can talk to each other. Al From: Guy Teverovsky [mailto:[EMAIL PROTECTED] On Behalf Of Guy TeverovskySent: Thursday, September 09, 2004 8:26 PMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] Fun with Kerberos ok... this starts to be more interesting. If the implicitUPN is constructed from samaccountname and AD DNS name, I do not see how Kerberos principals could clash. This is what I initially had (names changed to protect the innocent): Regular account: dn:[EMAIL PROTECTED],OU=Accounts,DC=child,DC=myad,DC=comsAMAccountName: guyuserPrincipalName: [EMAIL PROTECTED] Supplemental account: dn:CN=Teverovsky\, Guy (Supplemental),OU=Accounts,DC=child,DC=myad,DC=comsAMAccountName: guysuuserPrincipalName: [EMAIL PROTECTED] The regular account was programmatically created as disabled and was renamed+enabled when user migrated from NT domain. Supplemental account was created beforehand for administrative purposes (the user ismember of IT staff) Renaming the UPN ofsupplemental accountto [EMAIL PROTECTED] was the fix. Now I am totally confused and can't understand why the lockouts happened. It is almost as if [EMAIL PROTECTED] and [EMAIL PROTECTED] UPNs were somehow resolved to the same account. P.S.: it's worth to mention that the machine the user was logged to was in another forest which has Kerberos trust with myad.com forest. Guy From: [EMAIL PROTECTED] on behalf of Grillenmeier, GuidoSent: Thu 9/9/2004 11:52 AMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] Fun with Kerberos that's correct - even if you configure an additional UPN suffix for theforest (or for an OU) and assign this to an account when you create theaccount (e.g. via ADUC), every account will still have an implicit UPNsuffix that is made up of his samAccountName + the domain-suffix of hisAD 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 thespecial char in your ADM accounts (as it only used the first part of thename to create) - or did you configure your 2nd account like this onpurpose? I assume that the accounts were created programmatically, asthe ADUC UI will check for duplicate UPNs by querying a GC - so usuallythis is only a problem if accounts are created at roughly the same timeon differnt DCs (even in different domains). But I'm not sure if ADUConly queries for the explicit UPN that you've assigned at creation andignores the implicit UPN (seems to be the case). But I'm quite sure thatthis check is not performed when you programmatically add accounts toAD.As a result the duplicate UPNs caused a Kerberos conflict as you wellnoticed - interesting to read how your users noticed this on their XPclients. Can you elaborate on the "Once in a while..." - i.e. howoften? and did this only occurr if they were also logged on as theguy$adm at the same time?And when did the 2nd account get locked out - at the time the kerberosticket 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 registeran SPN (service principal name) that must also be unique: if they'reable to register the same name as another machine (e.g. when DDNS is notsecured sufficiently well), they can hinder both machines from receivingkerberos tickets and (if the "attacked" server was set to allow kerberosdelegation e.g. for some web-application) could thus cause a DOS forapplications running on the other server./Guido-Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]] On Behalf Of Guy TeverovskySent: Thursday, September 09, 2004 6:22 AMTo: [EMAIL PROTECTED]Subject: [ActiveDir] Fun with KerberosStumbled upon an issue couple of days ago and wanted to hear what youguys think about it.Suppose that your AD is called myad.com and you also configureadditional UPN suffix "company.com".Now I create 2 users in child.myad.com child domain:1) sAMAccountName: guyuserPrincipalName: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]2) sAMAccountName: guy$admuserPrincipalName: [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 happyto create both.But if you look at the users explicit Kerberos principals, both look thesame:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] (checked with klisttgt).In our
RE: [ActiveDir] Fun with Kerberos
Title: RE: [ActiveDir] Fun with Kerberos I thought this was a great article on the topic: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory/activedirectory/fedffin2.mspx From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, AlSent: Friday, September 10, 2004 10:38 AMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] Fun with Kerberos No, that sounds about right. Across two forests? Be tough for any administrative program to enforce uniqueness unless it was authoritative for both forests. That said, that's something you want your admin processes to compensate for and ensure that all accounts are unique across forests that can talk to each other. Al From: Guy Teverovsky [mailto:[EMAIL PROTECTED] On Behalf Of Guy TeverovskySent: Thursday, September 09, 2004 8:26 PMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] Fun with Kerberos ok... this starts to be more interesting. If the implicitUPN is constructed from samaccountname and AD DNS name, I do not see how Kerberos principals could clash. This is what I initially had (names changed to protect the innocent): Regular account: dn:[EMAIL PROTECTED],OU=Accounts,DC=child,DC=myad,DC=comsAMAccountName: guyuserPrincipalName: [EMAIL PROTECTED] Supplemental account: dn:CN=Teverovsky\, Guy (Supplemental),OU=Accounts,DC=child,DC=myad,DC=comsAMAccountName: guysuuserPrincipalName: [EMAIL PROTECTED] The regular account was programmatically created as disabled and was renamed+enabled when user migrated from NT domain. Supplemental account was created beforehand for administrative purposes (the user ismember of IT staff) Renaming the UPN ofsupplemental accountto [EMAIL PROTECTED] was the fix. Now I am totally confused and can't understand why the lockouts happened. It is almost as if [EMAIL PROTECTED] and [EMAIL PROTECTED] UPNs were somehow resolved to the same account. P.S.: it's worth to mention that the machine the user was logged to was in another forest which has Kerberos trust with myad.com forest. Guy From: [EMAIL PROTECTED] on behalf of Grillenmeier, GuidoSent: Thu 9/9/2004 11:52 AMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] Fun with Kerberos that's correct - even if you configure an additional UPN suffix for theforest (or for an OU) and assign this to an account when you create theaccount (e.g. via ADUC), every account will still have an implicit UPNsuffix that is made up of his samAccountName + the domain-suffix of hisAD 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 thespecial char in your ADM accounts (as it only used the first part of thename to create) - or did you configure your 2nd account like this onpurpose? I assume that the accounts were created programmatically, asthe ADUC UI will check for duplicate UPNs by querying a GC - so usuallythis is only a problem if accounts are created at roughly the same timeon differnt DCs (even in different domains). But I'm not sure if ADUConly queries for the explicit UPN that you've assigned at creation andignores the implicit UPN (seems to be the case). But I'm quite sure thatthis check is not performed when you programmatically add accounts toAD.As a result the duplicate UPNs caused a Kerberos conflict as you wellnoticed - interesting to read how your users noticed this on their XPclients. Can you elaborate on the "Once in a while..." - i.e. howoften? and did this only occurr if they were also logged on as theguy$adm at the same time?And when did the 2nd account get locked out - at the time the kerberosticket 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 registeran SPN (service principal name) that must also be unique: if they'reable to register the same name as another machine (e.g. when DDNS is notsecured sufficiently well), they can hinder both machines from receivingkerberos tickets and (if the "attacked" server was set to allow kerberosdelegation e.g. for some web-application) could thus cause a DOS forapplications running on the other server./Guido-Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]] On Behalf Of Guy TeverovskySent: Thursday, September 09, 2004 6:22 AMTo: [EMAIL PROTECTED]Subject: [ActiveDir] Fun with KerberosStumbled upon an issue couple of days ago and wanted to hear what youguys think about it.Suppose that your AD is called myad.com and you also configureadditional UPN suffix "company.com".Now I create 2 users in child.myad.com child domain:1) sAMAccountName: guyuserPrincipalName: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]2) sAMAccountName: guy$admuserPrincipalName: [EMAIL PROTECTED] mailto:[EMAIL P
RE: [ActiveDir] Fun with Kerberos
Title: RE: [ActiveDir] Fun with Kerberos Al, realize that the user accounts Guy is talking about are all in one forest - so the issue is not related to UPNs being unique accross more than one forest. They're just logging in from a machine in a different forest. I've already discussed offline with Guy that the clash is between the implicit UPN of the regular account (which would be [EMAIL PROTECTED]) and the explicit UPN of the supplemental account (which had previously been set to[EMAIL PROTECTED])= fixing the explicit UPN of the supplemental account fixed the clash and the related problems... BTW, we're thinking that the account lockouts and theXPrequestfor credentialsis likely related to Kerberos preauthentication. During preauth, AD looks up accounts using the UPN - so if it hits the wrong account, and uses the wrong password hash for validation of the Kerberos preauth data this may have the same effect as logging on with the wrong password. Here's a nice articlethat explains Kerberos preauthentication in more detailhttp://www.windowsitlibrary.com/Content/617/06/6.html /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, AlSent: Friday, September 10, 2004 4:38 PMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] Fun with Kerberos No, that sounds about right. Across two forests? Be tough for any administrative program to enforce uniqueness unless it was authoritative for both forests. That said, that's something you want your admin processes to compensate for and ensure that all accounts are unique across forests that can talk to each other. Al From: Guy Teverovsky [mailto:[EMAIL PROTECTED] On Behalf Of Guy TeverovskySent: Thursday, September 09, 2004 8:26 PMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] Fun with Kerberos ok... this starts to be more interesting. If the implicitUPN is constructed from samaccountname and AD DNS name, I do not see how Kerberos principals could clash. This is what I initially had (names changed to protect the innocent): Regular account: dn:[EMAIL PROTECTED],OU=Accounts,DC=child,DC=myad,DC=comsAMAccountName: guyuserPrincipalName: [EMAIL PROTECTED] Supplemental account: dn:CN=Teverovsky\, Guy (Supplemental),OU=Accounts,DC=child,DC=myad,DC=comsAMAccountName: guysuuserPrincipalName: [EMAIL PROTECTED] The regular account was programmatically created as disabled and was renamed+enabled when user migrated from NT domain. Supplemental account was created beforehand for administrative purposes (the user ismember of IT staff) Renaming the UPN ofsupplemental accountto [EMAIL PROTECTED] was the fix. Now I am totally confused and can't understand why the lockouts happened. It is almost as if [EMAIL PROTECTED] and [EMAIL PROTECTED] UPNs were somehow resolved to the same account. P.S.: it's worth to mention that the machine the user was logged to was in another forest which has Kerberos trust with myad.com forest. Guy From: [EMAIL PROTECTED] on behalf of Grillenmeier, GuidoSent: Thu 9/9/2004 11:52 AMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] Fun with Kerberos that's correct - even if you configure an additional UPN suffix for theforest (or for an OU) and assign this to an account when you create theaccount (e.g. via ADUC), every account will still have an implicit UPNsuffix that is made up of his samAccountName + the domain-suffix of hisAD 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 thespecial char in your ADM accounts (as it only used the first part of thename to create) - or did you configure your 2nd account like this onpurpose? I assume that the accounts were created programmatically, asthe ADUC UI will check for duplicate UPNs by querying a GC - so usuallythis is only a problem if accounts are created at roughly the same timeon differnt DCs (even in different domains). But I'm not sure if ADUConly queries for the explicit UPN that you've assigned at creation andignores the implicit UPN (seems to be the case). But I'm quite sure thatthis check is not performed when you programmatically add accounts toAD.As a result the duplicate UPNs caused a Kerberos conflict as you wellnoticed - interesting to read how your users noticed this on their XPclients. Can you elaborate on the "Once in a while..." - i.e. howoften? and did this only occurr if they were also logged on as theguy$adm at the same time?And when did the 2nd account get locked out - at the time the kerberosticket 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 registeran SPN (service principal name) that must also be unique: if they'reable to register the same name as another machine (e.g.
RE: [ActiveDir] Fun with Kerberos
Title: RE: [ActiveDir] Fun with Kerberos Thanks Guido. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, GuidoSent: Friday, September 10, 2004 11:10 AMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] Fun with Kerberos Al, realize that the user accounts Guy is talking about are all in one forest - so the issue is not related to UPNs being unique accross more than one forest. They're just logging in from a machine in a different forest. I've already discussed offline with Guy that the clash is between the implicit UPN of the regular account (which would be [EMAIL PROTECTED]) and the explicit UPN of the supplemental account (which had previously been set to[EMAIL PROTECTED])= fixing the explicit UPN of the supplemental account fixed the clash and the related problems... BTW, we're thinking that the account lockouts and theXPrequestfor credentialsis likely related to Kerberos preauthentication. During preauth, AD looks up accounts using the UPN - so if it hits the wrong account, and uses the wrong password hash for validation of the Kerberos preauth data this may have the same effect as logging on with the wrong password. Here's a nice articlethat explains Kerberos preauthentication in more detailhttp://www.windowsitlibrary.com/Content/617/06/6.html /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, AlSent: Friday, September 10, 2004 4:38 PMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] Fun with Kerberos No, that sounds about right. Across two forests? Be tough for any administrative program to enforce uniqueness unless it was authoritative for both forests. That said, that's something you want your admin processes to compensate for and ensure that all accounts are unique across forests that can talk to each other. Al From: Guy Teverovsky [mailto:[EMAIL PROTECTED] On Behalf Of Guy TeverovskySent: Thursday, September 09, 2004 8:26 PMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] Fun with Kerberos ok... this starts to be more interesting. If the implicitUPN is constructed from samaccountname and AD DNS name, I do not see how Kerberos principals could clash. This is what I initially had (names changed to protect the innocent): Regular account: dn:[EMAIL PROTECTED],OU=Accounts,DC=child,DC=myad,DC=comsAMAccountName: guyuserPrincipalName: [EMAIL PROTECTED] Supplemental account: dn:CN=Teverovsky\, Guy (Supplemental),OU=Accounts,DC=child,DC=myad,DC=comsAMAccountName: guysuuserPrincipalName: [EMAIL PROTECTED] The regular account was programmatically created as disabled and was renamed+enabled when user migrated from NT domain. Supplemental account was created beforehand for administrative purposes (the user ismember of IT staff) Renaming the UPN ofsupplemental accountto [EMAIL PROTECTED] was the fix. Now I am totally confused and can't understand why the lockouts happened. It is almost as if [EMAIL PROTECTED] and [EMAIL PROTECTED] UPNs were somehow resolved to the same account. P.S.: it's worth to mention that the machine the user was logged to was in another forest which has Kerberos trust with myad.com forest. Guy From: [EMAIL PROTECTED] on behalf of Grillenmeier, GuidoSent: Thu 9/9/2004 11:52 AMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] Fun with Kerberos that's correct - even if you configure an additional UPN suffix for theforest (or for an OU) and assign this to an account when you create theaccount (e.g. via ADUC), every account will still have an implicit UPNsuffix that is made up of his samAccountName + the domain-suffix of hisAD 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 thespecial char in your ADM accounts (as it only used the first part of thename to create) - or did you configure your 2nd account like this onpurpose? I assume that the accounts were created programmatically, asthe ADUC UI will check for duplicate UPNs by querying a GC - so usuallythis is only a problem if accounts are created at roughly the same timeon differnt DCs (even in different domains). But I'm not sure if ADUConly queries for the explicit UPN that you've assigned at creation andignores the implicit UPN (seems to be the case). But I'm quite sure thatthis check is not performed when you programmatically add accounts toAD.As a result the duplicate UPNs caused a Kerberos conflict as you wellnoticed - interesting to read how your users noticed this on their XPclients. Can you elaborate on the "Once in a while..." - i.e. howoften? and did this only occurr if they were also logged on as theguy$adm at the same time?And when did the 2nd account get locked out - at the time the kerberosticket 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 cl
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/
RE: [ActiveDir] Fun with Kerberos
ok... this starts to be more interesting. If the implicit UPN is constructed from samaccountname and AD DNS name, I do not see how Kerberos principals could clash. This is what I initially had (names changed to protect the innocent): Regular account: dn:[EMAIL PROTECTED],OU=Accounts,DC=child,DC=myad,DC=com sAMAccountName: guy userPrincipalName: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Supplemental account: dn:CN=Teverovsky\, Guy (Supplemental),OU=Accounts,DC=child,DC=myad,DC=com sAMAccountName: guysu userPrincipalName: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] The regular account was programmatically created as disabled and was renamed+enabled when user migrated from NT domain. Supplemental account was created beforehand for administrative purposes (the user is member of IT staff) Renaming the UPN of supplemental account to [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] was the fix. Now I am totally confused and can't understand why the lockouts happened. It is almost as if [EMAIL PROTECTED] and [EMAIL PROTECTED] UPNs were somehow resolved to the same account. P.S.: it's worth to mention that the machine the user was logged to was in another forest which has Kerberos trust with myad.com forest. Guy From: [EMAIL PROTECTED] on behalf of Grillenmeier, Guido 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
