[cifs-protocol] 114121712176508 MS-KILE Behaviour for client principal name in service tickets
Sreekanth Nadendla
srenaden at microsoft.com
Fri Mar 13 14:09:22 MDT 2015
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 at 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 at samba.org]
Sent: Wednesday, February 18, 2015 4:03 PM
To: Sreekanth Nadendla
Cc: MSSolve Case Email; cifs-protocol at 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 at 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 at 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 at 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
More information about the cifs-protocol
mailing list