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@ROCKYCORP.LOCAL

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

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


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

As normal user, I am able to authenticate:

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

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


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


Then ssh back to the machine using my kerberos credentials:

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

Valid starting Expires Service principal
11/28/04 20:09:05 11/29/04 06:09:07 krbtgt/ROCKYCORP.LOCAL@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@ROCKYCORP.LOCAL
renew until 11/29/04 20:09:05


Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached
[rapatel@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@rockylinux rapatel]# kdestroy
[root@rockylinux rapatel]# kinit -k
kinit(v5): Client not found in Kerberos database while getting initial
credentials
[root@rockylinux rapatel]# kinit -k
host/rockylinux.rockycorp.local@ROCKYCORP.LOCAL
kinit(v5): Client not found in Kerberos database while getting initial
credentials
[root@rockylinux rapatel]# kinit -k host/rockylinux@ROCKYCORP.LOCAL
kinit(v5): Key table entry not found while getting initial credentials
[root@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@ROCKYCORP.LOCAL


Test kinit -k:

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

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


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


Retest normal user access:

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

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


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

Valid starting Expires Service principal
11/28/04 20:27:33 11/29/04 06:27:34 krbtgt/ROCKYCORP.LOCAL@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@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.