[cifs-protocol] 114121712176508 MS-KILE Behaviour for client principal name in service tickets
Andrew Bartlett
abartlet at samba.org
Wed Feb 18 14:03:21 MST 2015
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: no-canon.no-enterprise.uc-realm.uc-user.netbios-realm.no-win2k.no-upn.pcapng
Type: application/x-pcapng
Size: 7932 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20150219/c59b0856/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: no-canon.enterprise.lc-realm.lc-user.krb5-realm.no-win2k.no-upn.pcapng
Type: application/x-pcapng
Size: 22324 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20150219/c59b0856/attachment-0003.bin>
More information about the cifs-protocol
mailing list