[prev in list] [next in list] [prev in thread] [next in thread]
List: cifs-protocol
Subject: Re: [cifs-protocol] 114121712176508 MS-KILE Behaviour for client principal name in service tickets
From: Sreekanth Nadendla <srenaden () microsoft ! com>
Date: 2015-03-13 20:09:22
Message-ID: BY2PR03MB379C26CB19FEA08C474B259C5070 () BY2PR03MB379 ! namprd03 ! prod ! outlook ! com
[Download RAW message or body]
Hello Andrew,
Our product team will be working with the documentation team \
to address the remaining questions from both the this thread and the one opened for \
115012912337526. As this effort would take considerable amount of time and you are \
not blocked at the moment, we plan on providing the details in the future update of \
MS-KILE and other AD related documents. I have outlined below the pending items for \
your reference. Please suggest if you have any updates or modifications.
1) The available description for Service Principal Name doesn't seem to be \
comprehensive. For example, you can ask for a service ticket to a UPN, if the server \
has one and you encode the request as an enterprise principal. But you can't do it \
with an AP-REQ, only a TGS-REQ (you can ask for a service ticket with an AP-REQ to \
normal SPNS). The spec does not explain this.
2) It would be helpful to see the mapping between the principal names in kerberos \
ticket response and the LDAP fields as shown below
Packet Field Matches against
AS-REQ Client principal samAccountName if @REALM or @NETBIOS, userPrincipalName \
if @REALM, userPrincipalName otherwise if NT-ENTERPRISE-PRINCIPAL
AS-REQ Server principal samAccountName if @REALM or @NETBIOS, \
servicePrincipalName or krbtgt (magic)
TGS-REQ Server principal samAccountName if @REALM or @NETBIOS, \
servicePrincipalName or krbtgt (magic), userPrincipalName if NT-ENTERPRISE-PRINCIPAL
The realm field (shared for client and server in krb5 packets) is always \
canonicalised to the real realm, but only the main one in the packet, not the one in \
any enterprise principal. Aside from that, principals are only canonicalised for \
AS-REQ if canonicalise is set in the packet.
Things like being able to get a ticket to an NT-ENTERPRISE principal in the TGS-REQ, \
but not AS-REQ are not explained. It would be great to have a very clear explanation \
of what principal types and matching fields are valid for those requests.
3) Why can I get a ticket to machine$@REALM in both of the following scenarios but \
not for administrator@REALM?
- as the service principal in the AS-REQ. Typically this is krbtgt/ so you can get a \
ticket granting ticket, but you can actually ask for a ticket to any \
valid service.
- as the service principal in the TGS-REQ.
4) uPNSuffixes is partly mentioned, msDS-SPNSuffixes is not mentioned at all. The \
behaviour and description of uPNSuffixes and msDS-SPNSuffixes should \
be improved.
Does msDS-SPNSuffixes apply to every servicePrincipalName in the forest?
Regards,
Sreekanth Nadendla
Microsoft Windows Open Specifications
-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@samba.org]
Sent: Wednesday, February 18, 2015 4:03 PM
To: Sreekanth Nadendla
Cc: MSSolve Case Email; cifs-protocol@samba.org
Subject: Re: [cifs-protocol] 114121712176508 MS-KILE Behaviour for client principal \
name in service tickets
On Wed, 2015-02-18 at 20:05 +0000, Sreekanth Nadendla wrote:
> Hello Andrew,
> In your response below, you said "No, it
> isn't". I take it that you are saying kinit.exe user@SHORTDOMAIN
> could result in a principal that has a different REALM than what was
> specified in the request and this leads to name mismatch. If I am
> correct in my understanding of the problem description here, all I am
> saying is the request over the wire never sent SHORTDOMAIN as Crealm
> which you can see from the trace.
See attached
krb5.kdc.canon.no-canon.no-enterprise.uc-realm.uc-user.netbios-realm.no-win2k.no-upn.pcapng \
Packet 8 and Packet 11.
> It is just that the kinit.exe output is misleading you into thinking
> that the short-form domain got changed by Windows AD to a different
> DNS-based realm. Let me know your thoughts on this. Note that the
> explanation offered is based on the trace you gave us and we don't
> have a local repro identical to yours. Also want to add that we can
> setup test cases for all scenarios except the custom one which uses
> Enterprise names without Canonicalization.
This was reproduced using Samba git master:
bin/smbtorture -UAdministrator
--realm=WIN2012R2.ABARTLET.WGTN.CAT-IT.CO.NZ //192.168.252.236/bar \
krb5.kdc.canon.no-canon.no-enterprise.uc-realm.uc-user.netbios-realm.no-win2k.no-upn \
-W WIN2012R2
To get the case you describe above, use
bin/smbtorture -UAdministrator
--realm=WIN2012R2.ABARTLET.WGTN.CAT-IT.CO.NZ //192.168.252.236/bar \
krb5.kdc.canon.no-canon.enterprise.lc-realm.lc-user.krb5-realm.no-win2k.no-upn -W \
WIN2012R2
That is in
no-canon.enterprise.lc-realm.lc-user.krb5-realm.no-win2k.no-upn.pcapng
> At this time it is my understanding that you are NOT blocked with your
> implementation but only trying to bring more clarity to the specs. Let
> me know otherwise.
Ideally, what I would like is a table:
Packet Field Matches against
AS-REQ Client principal samAccountName if @REALM or @NETBIOS, userPrincipalName \
if @REALM, userPrincipalName otherwise if NT-ENTERPRISE-PRINCIPAL AS-REQ Server \
principal samAccountName if @REALM or @NETBIOS, servicePrincipalName or krbtgt \
(magic) TGS-REQ Server principal samAccountName if @REALM or @NETBIOS, \
servicePrincipalName or krbtgt (magic), userPrincipalName if NT-ENTERPRISE-PRINCIPAL
The realm field (shared for client and server in krb5 packets) is always \
canonicalised to the real realm, but only the main one in the packet, not the one in \
any enterprise principal.
Aside from that, principals are only canonicalised for AS-REQ if canonicalise is set \
in the packet.
The reason I'm still asking about this is that while I don't beleive I'm blocked, \
things like being able to get a ticket to an NT-ENTERPRISE principal in the TGS-REQ, \
but not AS-REQ, make me wonder if I really do understand the whole picture. I've had \
bugs raised about our S4U2Self and S4U2Proxy behaviour, and it would be great to have \
a very clear explanation of what principal types and matching fields are valid for \
those requests.
To see the full set of tests, have a krb5.conf like:
[libdefaults]
default_realm = WIN2012R2.ABARTLET.WGTN.CAT-IT.CO.NZ
# The following krb5.conf variables are only for MIT Kerberos.
krb4_config = /etc/krb.conf
krb4_realms = /etc/krb.realms
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
dns_lookup_kdc = true
rdns = false
[realms]
WIN2012R2 = {
kdc = 192.168.252.238
}
win2012r2 = {
kdc = 192.168.252.238
}
This allows the krb5 libs to find the short-form KDC, and not fail before they start. \
We then override that with the IP in the smbtorture command here:
bin/smbtorture -Utestallowed
--realm=WIN2012R2.ABARTLET.WGTN.CAT-IT.CO.NZ //192.168.252.236/bar krb5.kdc.canon -W \
WIN2012R2 --option=torture:krb5-upn=testallowed_upn@w2k12.abartlet.wgtn.cat-it.co.nz \
--option=torture:krb5-service=http --option=torture:krb5-hostname=testallowed \
--option=torture:expect_machine_account=true
This is the ldif for that user
dn: CN=testallowed,CN=Users,DC=win2012r2,DC=abartlet,DC=wgtn,DC=cat-it,DC=co,DC=nz
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: testallowed
distinguishedName: CN=testallowed,CN=Users,DC=win2012r2,DC=abartlet,DC=wgtn,DC
=cat-it,DC=co,DC=nz
instanceType: 4
whenCreated: 20150123001345.0Z
whenChanged: 20150218204819.0Z
displayName: testallowed
uSNCreated: 302335
memberOf: CN=Allowed RODC Password Replication Group,CN=Users,DC=win2012r2,DC= \
abartlet,DC=wgtn,DC=cat-it,DC=co,DC=nz
uSNChanged: 346050
streetAddress: 1 Hill ST
name: testallowed
objectGUID: 927bf6c5-bed2-48e9-be7a-37372cd3f53c
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 130675862968138740
lastLogoff: 0
lastLogon: 130687664517937982
pwdLastSet: 130669755206249216
primaryGroupID: 513
objectSid: S-1-5-21-1613137666-3543045619-4048888970-26085
accountExpires: 9223372036854775807
logonCount: 32825
sAMAccountName: testallowed
sAMAccountType: 805306368
userPrincipalName: testallowed_upn@w2k12.abartlet.wgtn.cat-it.co.nz
lockoutTime: 0
servicePrincipalName: http/testallowed
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=win2012r2,DC=abartlet,
DC=wgtn,DC=cat-it,DC=co,DC=nz
dSCorePropagationData: 16010101000000.0Z
lastLogonTimestamp: 130687660990750910
msDS-RevealedDSAs: CN=WIN2012R2-5,OU=Domain Controllers,DC=win2012r2,DC=abartl
et,DC=wgtn,DC=cat-it,DC=co,DC=nz
msDS-RevealedDSAs: CN=WIN2012R2-5,OU=Domain Controllers,DC=win2012r2,DC=abartl
et,DC=wgtn,DC=cat-it,DC=co,DC=nz
msDS-RevealedDSAs: CN=WIN2012R2-5,OU=Domain Controllers,DC=win2012r2,DC=abartl
et,DC=wgtn,DC=cat-it,DC=co,DC=nz
msDS-RevealedDSAs: CN=WIN2012R2-5,OU=Domain Controllers,DC=win2012r2,DC=abartl
et,DC=wgtn,DC=cat-it,DC=co,DC=nz
msDS-RevealedDSAs: CN=WIN2012R2-5,OU=Domain Controllers,DC=win2012r2,DC=abartl
et,DC=wgtn,DC=cat-it,DC=co,DC=nz
You can explore even more behaviours by removing the upn or spn, and the matching \
torture options.
I hope this helps clarify what I'm seeing. As you will see when you read the test, \
we parse the ASN.1 and specifically verify the outgoing and incoming packets, to \
ensure we are not being blinded by the client tools.
Finally, as you will see, yes, this blurs with the other threads I've raised here, \
such as 115012912337526. I'm looking for a holistic answer.
Thanks,
Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
_______________________________________________
cifs-protocol mailing list
cifs-protocol@lists.samba.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic