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:[email protected]]
Sent: Wednesday, February 18, 2015 4:03 PM
To: Sreekanth Nadendla
Cc: MSSolve Case Email; [email protected]
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:[email protected]
--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: [email protected]
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
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol
