samba keytab support for AD and kinit -k

Sun Nov 28 20:43:27 EST 2004

Just limiting below to the main issue [note that I had not encountered 
this before when we went
through various stages of testing the keytab management changes].

Sam Hartman wrote:

>    Rakesh> The issue is that in the Windows KDC, an SPN can not be
>    Rakesh> used as a "user" for authentication and computers normally
>    Rakesh> do not contain a UPN entry.  
>
>That is not my understanding of the Microsoft KDC architecture.  This
>claim also goes against interoperability tests I have conducted with
>Microsoft.
>
>  
>

I have a machine "rockylinux" (FC3 - samba-3.0.8-0.pre1.3 package) 
joined to an AD/2003 domain
running Windows2003 as the DC.

Based upon the original email report for this thread, I ran into the 
same issue, so I decided to start
from scratch by renaming my host to use an FQDN in case it made any 
difference and ensured everything
was matching the AD Domain DNS.   Samba joined the machine to the domain 
with SHORT name for
the UPN of the entry:

# rockylinux, Computers, rockycorp.local
dn: CN=rockylinux,CN=Computers,DC=rockycorp,DC=local
userPrincipalName: HOST/rockylinux at ROCKYCORP.LOCAL

[root at rockylinux rapatel]# uname -n
rockylinux.rockycorp.local

[root at rockylinux rapatel]# klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- 
--------------------------------------------------------------------------
   2 host/rockylinux.rockycorp.local at ROCKYCORP.LOCAL
   2 host/rockylinux.rockycorp.local at ROCKYCORP.LOCAL
   2 host/rockylinux.rockycorp.local at ROCKYCORP.LOCAL
   2 host/rockylinux.rockycorp.local at ROCKYCORP.LOCAL
   2 host/rockylinux.rockycorp.local at ROCKYCORP.LOCAL
   2 host/rockylinux.rockycorp.local at ROCKYCORP.LOCAL
   2 host/rockylinux.rockycorp.local at ROCKYCORP.LOCAL
   2 cifs/rockylinux.rockycorp.local at ROCKYCORP.LOCAL
   2 cifs/rockylinux.rockycorp.local at ROCKYCORP.LOCAL
   2 cifs/rockylinux.rockycorp.local at ROCKYCORP.LOCAL
   2 cifs/rockylinux.rockycorp.local at ROCKYCORP.LOCAL
   2 cifs/rockylinux.rockycorp.local at ROCKYCORP.LOCAL
   2 cifs/rockylinux.rockycorp.local at ROCKYCORP.LOCAL
   2 cifs/rockylinux.rockycorp.local at ROCKYCORP.LOCAL
[root at rockylinux rapatel]#

Obviously all the encodings are included for both host/FQDN at REALM and 
cifs/FQDN at REALM.

As normal user, I am able to authenticate:

[rapatel at rockylinux ~]$ kinit rapatel
Password for rapatel at ROCKYCORP.LOCAL:
[rapatel at rockylinux ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: rapatel at ROCKYCORP.LOCAL

Valid starting     Expires            Service principal
11/28/04 20:09:05  11/29/04 06:09:07  krbtgt/ROCKYCORP.LOCAL at ROCKYCORP.LOCAL
        renew until 11/29/04 20:09:05

Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached
[rapatel at rockylinux ~]$

Then ssh back to the machine using my kerberos credentials:

[rapatel at rockylinux ~]$ ssh rockylinux
Last login: Sun Nov 28 17:49:51 2004 from rockylinux.rockycorp.local
[rapatel at rockylinux ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: rapatel at ROCKYCORP.LOCAL

Valid starting     Expires            Service principal
11/28/04 20:09:05  11/29/04 06:09:07  krbtgt/ROCKYCORP.LOCAL at ROCKYCORP.LOCAL
        renew until 11/29/04 20:09:05
11/28/04 20:09:46  11/29/04 06:09:07  
host/rockylinux.rockycorp.local at ROCKYCORP.LOCAL
        renew until 11/29/04 20:09:05

Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached
[rapatel at rockylinux ~]$

Note the SPN is listed appropriately with FQDN and ssh was able to 
validate the credentials successfully
using the host key.

As root, attempt to use the host key to initialize a cache:

[root at rockylinux rapatel]# kdestroy
[root at rockylinux rapatel]# kinit -k
kinit(v5): Client not found in Kerberos database while getting initial 
credentials
[root at rockylinux rapatel]# kinit -k 
host/rockylinux.rockycorp.local at ROCKYCORP.LOCAL
kinit(v5): Client not found in Kerberos database while getting initial 
credentials
[root at rockylinux rapatel]# kinit -k host/rockylinux at ROCKYCORP.LOCAL 
kinit(v5): Key table entry not found while getting initial credentials
[root at rockylinux rapatel]#

Notice the errors -  defaults to using the FQDN and the KDC indicates 
the Client is not found, while
using the short host name, kinit can not locate it within the keytab.

Modify the UPN:
# rockylinux, Computers, rockycorp.local
dn: CN=rockylinux,CN=Computers,DC=rockycorp,DC=local
userPrincipalName: HOST/rockylinux.rockycorp.local at ROCKYCORP.LOCAL

Test kinit -k:

[root at rockylinux rapatel]# kdestroy
[root at rockylinux rapatel]# kinit -k
[root at rockylinux rapatel]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: host/rockylinux.rockycorp.local at ROCKYCORP.LOCAL

Valid starting     Expires            Service principal
11/28/04 20:26:44  11/29/04 06:26:43  krbtgt/ROCKYCORP.LOCAL at ROCKYCORP.LOCAL
        renew until 11/29/04 20:26:44

Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached
[root at rockylinux rapatel]#

Retest normal user access:

[rapatel at rockylinux ~]$ kdestroy
[rapatel at rockylinux ~]$ kinit
Password for rapatel at ROCKYCORP.LOCAL:
[rapatel at rockylinux ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: rapatel at ROCKYCORP.LOCAL

Valid starting     Expires            Service principal
11/28/04 20:27:33  11/29/04 06:27:34  krbtgt/ROCKYCORP.LOCAL at ROCKYCORP.LOCAL
        renew until 11/29/04 20:27:33

Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached
[rapatel at rockylinux ~]$ ssh rockylinux
Last login: Sun Nov 28 20:09:47 2004 from rockylinux.rockycorp.local
[rapatel at rockylinux ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: rapatel at ROCKYCORP.LOCAL

Valid starting     Expires            Service principal
11/28/04 20:27:33  11/29/04 06:27:34  krbtgt/ROCKYCORP.LOCAL at ROCKYCORP.LOCAL
        renew until 11/29/04 20:27:33
11/28/04 20:27:43  11/29/04 06:27:34  
host/rockylinux.rockycorp.local at ROCKYCORP.LOCAL
        renew until 11/29/04 20:27:33

Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached
[

As you can see there is a direct correllation to the UPN in the context 
of using service principals
for primary authentication unlike a typical UNIX environment using MIT 
or Heimdal where
service keys can be used a normal principal. 

I was surprised at the initial message on this thread myself - we never 
encountered it months ago in
extensive testing before the keytab code was approved for integration 
for release. There may
be specific controls within the Microsoft policies that may address this 
issue, but I have a very
"default" installation and have only loosened specific controls such as 
password requirements
and digital signing controls limiting interoperability.   I believe the 
reason it never came up is that
we originally did use the FQDN in the UPN, as I was testing PADL 
nss_ldap with cached kerberos
 credentials [even added kinit -k before nscd was started to initialize 
the cache].  I'm pretty certain
the move to short name was after I had moved on to other projects and I 
never had a chance to test
the later revisions of code.

Rakesh Patel.