[Samba] Kerberos Keytab Code Update in 3.0.23
roamdad at sonic.net
Thu Jul 13 07:56:28 GMT 2006
Scott Armstrong wrote:
> First thing - I'd like to say a big "THANK YOU" to the developers.
> I just upgraded to samba-3.0.23 and I've noticed an alarming issue with
> respect to my configuration.
> I've been using the built-in keytab management and it looks like the updated
> code no longer creates the userPrincipal in Active Directory.
> Whether this is an issue for others or not, it would be nice to have seen a
> reference to it in the release notes. Since having the user principal in the
> keytab and a cron job to renew the ticket are critical for me to use
> pam_krb5, I'm going to attempt to figure out what code needs to be added
> back from 3.0.22. In the defense of the authors, examining a Win2k3 server
> does not show the userPrincipal value being set, although I sort of
> considered this functionality to be the primary aim in using Samba for the
> keytab management.
File a bug report if you believe this to be true. I'm not at 3.0.23 right now
and don't have the time to try it here. I wouldn't want to lose this.
I did see a mention they dropped support of joins from machines where
the domain differs from the realm, but haven't had time to check this.
There has been a rewrite of the ads join code since 3.0.22.
> While I'm on my soap box, would it be possible to hear some clarification on
> the value of some of the principals created in the keytab (MIT Kerberos)?
> When I look at Active Directory using ADSI Edit, I see 4 servicePrincipal
> values created as a result of "net ads join" -
> host/host, host/fqdn, cifs/host, cifs/fqdn.
> When I use ktutil to view the keys in the table, I'm confronted with output
> that doesn't make any sense to me.
> Note that I've substituted generic host/domain/realm info and I've forcibly
> constrained the encryption types to rc4-hmac and des-cbc-md5
> slot KVNO Principal
> ---- ----
> 1 2 host/foo.bar.com at BAR.COM
> 2 2 host/foo.bar.com at BAR.COM
> 3 2 cifs/foo.bar.com at BAR.COM
> 4 2 cifs/foo.bar.com at BAR.COM
> 5 2 foo$@BAR.COM
> 6 2 foo$@BAR.COM
> 7 2 FOO$@BAR.COM
> 8 2 FOO$@BAR.COM
> 9 2 host/foo at BAR.COM
> 10 2 host/foo at BAR.COM
> 11 2 host/FOO at BAR.COM
> 12 2 host/FOO at BAR.COM
> 13 2 host/FOO.bar.com at BAR.COM
> 14 2 host/FOO.bar.com at BAR.COM
> 15 2 HOST/foo at BAR.COM
> 16 2 HOST/foo at BAR.COM
> 17 2 HOST/FOO at BAR.COM
> 18 2 HOST/FOO at BAR.COM
> 19 2 HOST/foo.bar.com at BAR.COM
> 20 2 HOST/foo.bar.com at BAR.COM
> 21 2 HOST/FOO.bar.com at BAR.COM
> 22 2 HOST/FOO.bar.com at BAR.COM
> 23 2 cifs/foo at BAR.COM
> 24 2 cifs/foo at BAR.COM
> 25 2 cifs/FOO at BAR.COM
> 26 2 cifs/FOO at BAR.COM
> 27 2 cifs/FOO.bar.com at BAR.COM
> 28 2 cifs/FOO.bar.com at BAR.COM
> 29 2 CIFS/foo at BAR.COM
> 30 2 CIFS/foo at BAR.COM
> 31 2 CIFS/FOO at BAR.COM
> 32 2 CIFS/FOO at BAR.COM
> 33 2 CIFS/foo.bar.com at BAR.COM
> 34 2 CIFS/foo.bar.com at BAR.COM
> 35 2 CIFS/FOO.bar.com at BAR.COM
> 36 2 CIFS/FOO.bar.com at BAR.COM
> 37 2 cifs/foo.BAR.COM at BAR.COM
> 38 2 cifs/foo.BAR.COM at BAR.COM
> 39 2 CIFS/foo.BAR.COM at BAR.COM
> 40 2 CIFS/foo.BAR.COM at BAR.COM
> 41 2 host/foo.BAR.COM at BAR.COM
> 42 2 host/foo.BAR.COM at BAR.COM
> 43 2 HOST/foo.BAR.COM at BAR.COM
> 44 2 HOST/foo.BAR.COM at BAR.COM
> No offense intended, but what is the purpose of adding the variations of
> case especially with respect to the FQDN?
> When I look at the tickets that are the result of making connections from
> one Win2K3 server to another, the principals simply reflect the form of the
> requests - ie \\FOO yields principal cifs/FOO at BAR.COM, \\foo.bar.com yields
> principal cifs/foo.bar.com at BAR.COM
> What am I missing?
Just that windows doesn't guarantee case in names.
For example, on my login, the current tickets show up as
HOST/foo at BAR.COM
host/foo.bar.com at BAR.COM
HOST/FOO1 at BAR.COM
HOST/FOO1.bar.com at BAR.COM
I rarely see any cifs tickets. Notice the uppercase machine name and
lower case domain name combo. One ticket has the lowercase host and the
rest are uppercase HOST.
I'm also seeing Foo (first letter uppercase) generated by a 2003 enterprise
server for a samba A/D member. I have a personally patched version of samba
to help accomodate this machine.
Consider yourself lucky to only have the two variations.
When samba manages the keytab, it has to generate enough combinations
to cover the majority of know variations for a worldwide installed base
of windows machines.
More information about the samba